Security Advisory - Published 2026-06-08 - Education PHP apps

SourceCodester Timetabling CVE-2026-11471/11472/11482-11486: SQL Injection Self-Check

Seven public SQL injection reports now point at SourceCodester Class and Exam Timetabling System 1.0. CVE-2026-11471 and CVE-2026-11472 hit the login flow through /index2.php and /index1.php. CVE-2026-11482 through CVE-2026-11486 add /archive1.php through /archive5.php, all tied to the sy argument. Public PoC material exists for the cluster, so public demo installs and forgotten school portals should be checked before they become a database leak.

Scope: This guide is for site owners and defenders. It does not include SQL injection payloads. Use it to confirm exposure, review logs, and make a safe fix plan.

What is affected

  • Product: SourceCodester Class and Exam Timetabling System
  • Version: 1.0 in the public reports
  • CVE-2026-11471: /index2.php, Password argument
  • CVE-2026-11472: /index1.php, Password argument
  • CVE-2026-11486: /archive1.php, sy argument
  • CVE-2026-11485: /archive2.php, sy argument
  • CVE-2026-11484: /archive3.php, sy argument
  • CVE-2026-11483: /archive4.php, sy argument
  • CVE-2026-11482: /archive5.php, sy argument
  • Weakness: SQL injection, mapped to CWE-89 / CWE-74 in public metadata
  • Authentication required: reported as no login required
  • Known exploited in CISA KEV: no, as of this publication

The risk is higher on old PHP/MySQL school systems because the login page is often public, backups are thin, and a copied demo project may still use direct SQL string building. Treat this as a code and log review, not only a "change password" job.

10-minute exposure check

Step 1: Confirm the application

Look for "Class and Exam Timetabling System" in the page title, admin dashboard, source folder, or deployment notes. If the site is an old class project or demo, take it offline unless it still has a business owner.

Step 2: Find the affected files

From the web root, check whether the reported files exist:

find /var/www /home /www -maxdepth 6 \( -name "index1.php" -o -name "index2.php" -o -name "archive1.php" -o -name "archive2.php" -o -name "archive3.php" -o -name "archive4.php" -o -name "archive5.php" \) -type f 2>/dev/null

If these files sit at the public web root and the login page is reachable from the internet, assume scanners can reach it too.

Step 3: Inspect the SQL paths

Search the reported files for direct SQL construction around the reported fields:

grep -nEi "password|sy|select|mysqli_query|mysql_query|query\\(" index1.php index2.php archive1.php archive2.php archive3.php archive4.php archive5.php 2>/dev/null

Risk signs: raw request values inside SQL strings, no prepared statements, no parameter binding, and password checks done by matching a submitted password directly inside a SQL query.

Step 4: Review web logs

Search for suspicious traffic to the reported files:

grep -R "index1.php\|index2.php\|archive[1-5].php" /var/log/nginx /var/log/apache2 /usr/local/apache/logs 2>/dev/null | grep -Ei "password|sy=|union|select|sleep|information_schema|%27|'" | tail -50

A few failed login attempts are normal. Long query strings, SQL keywords, repeated requests from many IPs, or spikes around June 8, 2026 are worth preserving before you change code or delete logs.

Step 5: Check database and account damage

  • Unexpected administrator, teacher, or registrar accounts
  • Class schedules, exam records, or user records changed outside office hours
  • Database exports, backup files, or SQL dumps in the web root
  • New PHP files under upload, image, cache, or backup folders
  • Database user configured with broad privileges it does not need

Safe fix path

  1. Restrict access first. Put the app behind VPN, IP allowlist, or basic auth while you review it.
  2. Replace string-built SQL. Use prepared statements and bound parameters for the login query.
  3. Fix password storage. Use password hashes; do not compare raw passwords directly in SQL.
  4. Reduce database privileges. The app account should not have broad administrative rights.
  5. Rotate credentials if logs are suspicious. Start with app admins, database credentials, and reused school staff passwords.
  6. Remove stale demos. If nobody owns the app, archive it offline instead of patching a forgotten portal.

Temporary Nginx block

If the application is not needed right now, block the affected pages until a developer has reviewed the code: 

location ~ ^/(index1|index2|archive[1-5])\.php$ {
    deny all;
    return 403;
}

If those files are required by an active school portal, use an IP allowlist instead of a full block and test staff access after the change.

When to treat it as an incident

  • The login page was publicly reachable before June 8, 2026.
  • Logs show SQL-like traffic to index1.php, index2.php, or archive1.php through archive5.php.
  • Accounts, schedules, exam data, or student records changed unexpectedly.
  • Database credentials are reused by other apps on the same server.
  • You cannot prove whether the app was only scanned or actually accessed.

Ping7 repair path

Ping7 can run a defensive review for small PHP school portals: exposure check, login SQL review, web-log triage, credential rotation plan, and a short written remediation note. Start from CVE Repair and include the domain, hosting type, and whether index1.php, index2.php, or archive1.php through archive5.php is public.

References

Author: Ping7 security team - Published: 2026-06-08 - Updated: 2026-06-08 - CVE-2026-11471 / CVE-2026-11472 / CVE-2026-11482 / CVE-2026-11483 / CVE-2026-11484 / CVE-2026-11485 / CVE-2026-11486 - Defensive self-check only.