CVE-2026-16227: SQL Injection in SourceCodester Timetabling System
TL;DR - CVE-2026-16227 is a high-severity SQL injection in
SourceCodester Class and Exam Timetabling System 1.0. - The flaw is in/edit_subject.phpvia theIDparameter and is remotely exploitable. - A public exploit is disclosed; patch status is unverified, so defenders should treat exposed 1.0 instances as urgent.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-16227 |
| CVSS score | 7.3 (High) |
| Attack vector | Remote / network-accessible |
| Auth required | Unknown from available primary-source data |
| Patch available | Unknown / not verified |
This CVE affects SourceCodester Class and Exam Timetabling System 1.0 and is described by NVD as a SQL injection issue in /edit_subject.php caused by manipulation of the ID argument. The NVD description also states the attack may be performed remotely.
Two practical points matter immediately for defenders. First, the NVD record explicitly says public exploit details have been disclosed and may be used. Second, an official fixed version was not confirmed in the available source material. In practice, that means internet-exposed deployments of version 1.0 should be treated as high priority for containment, review, and code-level remediation if no vendor patch can be found.
What Is This Vulnerability?
CVE-2026-16227 is a SQL injection vulnerability, which means attacker-controlled input reaches backend SQL query construction without being safely parameterized or validated. In this case, the vulnerable location is reported as /edit_subject.php, and the tainted input is the ID parameter. Based on the primary-source description, an attacker can manipulate that parameter to alter the intended SQL statement sent to the database.
The root cause is not fully documented in the NVD summary beyond the vulnerability class and affected parameter. Still, from a practitioner standpoint, this typically points to one of two implementation failures: string-concatenated SQL queries or insufficient server-side validation and escaping around numeric identifiers. If ID is assumed to be a trusted integer but is inserted directly into a query, an attacker may inject SQL syntax that changes query logic, extracts data, or modifies records.
In applications like a class and exam timetabling platform, SQL injection risk is operationally significant because the backend database often stores user records, schedules, courses, subjects, possibly credentials or password hashes, and administrative metadata. Even where the initial vulnerable endpoint appears narrow, SQL injection often enables broader database read or write access depending on database permissions and application design.
The NVD record does not explicitly confirm the full impact scope for this specific CVE beyond SQL injection. Defenders should therefore avoid overstating outcomes such as full remote code execution. However, it is reasonable to assume risk of unauthorized data access, tampering, and record manipulation unless code review proves the database account has very limited privileges.
Technical Notes
A vulnerable PHP pattern often looks like this:
<?php
$id = $_GET['ID'];
$sql = "SELECT * FROM subjects WHERE id = '$id'";
$result = mysqli_query($conn, $sql);
?>
A safer pattern uses strict validation and prepared statements:
<?php
$id = filter_input(INPUT_GET, 'ID', FILTER_VALIDATE_INT);
$stmt = $conn->prepare("SELECT * FROM subjects WHERE id = ?");
$stmt->bind_param("i", $id);
$stmt->execute();
?>
Who Is Affected?
The confirmed affected product and version from the available research is:
- SourceCodester Class and Exam Timetabling System 1.0
The confirmed affected component is:
/edit_subject.php
The confirmed affected input is:
IDparameter
No broader affected version range was verified from the accessible primary-source data. That is important operationally: defenders should not assume earlier or later versions are safe or vulnerable without additional vendor or code-level confirmation. What can be stated confidently is that version 1.0 is affected.
If your organization deployed this application from SourceCodester as-is, especially in a lab, school, small business, or shared hosting environment, you should assume instances running version 1.0 are vulnerable until proven otherwise. If you have local modifications, forks, or customized deployments derived from the 1.0 codebase, those may also inherit the issue if edit_subject.php still constructs SQL queries unsafely around the ID parameter.
Because the authentication requirement is not explicitly confirmed in the available source data, defenders should take the safer stance: assume the vulnerable endpoint could be reachable by an unauthenticated or low-privilege user unless testing shows otherwise. That assumption affects prioritization for externally reachable systems.
Technical Notes
To identify potentially affected deployments on Linux web servers, start by locating the application files and the vulnerable script:
find /var/www -type f \( -iname "edit_subject.php" -o -iname "*timetabling*" \) 2>/dev/null
If you maintain application inventories, search for the product name and version markers:
grep -Rni "Class and Exam Timetabling System" /var/www 2>/dev/null
grep -Rni "version 1.0" /var/www 2>/dev/null
CVSS Score Breakdown
The confirmed CVSS base score is 7.3 (High) according to the NVD data referenced in the research note. However, the full CVSS vector string was not available in the retrieved tool output. That means defenders can safely cite the score, but should not invent the exact metric values for attack complexity, confidentiality impact, integrity impact, or privileges required.
Even without the vector string, the score aligns with the reported characteristics: a remote SQL injection affecting a web-exposed component. In practice, a 7.3 score tells defenders this is not merely a theoretical coding issue. It is serious enough to warrant near-term remediation, especially because SQL injection can result in broad data-layer compromise and because the NVD text notes public exploit disclosure.
The missing vector details matter because they affect prioritization nuance. For example, if privileges required were none and user interaction were none, that would increase urgency for internet-facing systems. Since those details are not verified here, the prudent approach is to prioritize based on exposure, business criticality, and exploit availability, rather than on guessed metric values.
From an operational risk standpoint, this vulnerability should be triaged above many routine web bugs because three practical conditions are already present: the attack is remote, the weakness type is SQL injection, and public exploit information exists. Those three facts are enough for most blue teams to justify immediate review of exposure and compensating controls.
Exploitation Status
The strongest confirmed statement comes from the NVD description itself: “The exploit has been disclosed publicly and may be used.” That means defenders should treat this CVE as having a publicly disclosed exploit or proof-of-concept. The research note also identifies NVD-listed references including a GitHub issue and a VulDB entry, which supports the conclusion that exploit details are available publicly.
What is not confirmed is active exploitation in the wild. At the time of review, CVE-2026-16227 is not listed in CISA’s Known Exploited Vulnerabilities catalog. Absence from KEV does not prove the vulnerability is not being exploited; it only means there is no CISA KEV confirmation available from that source. For SMBs and understaffed IT teams, the right interpretation is: public exploit known, real-world exploitation not confirmed from authoritative data retrieved here.
That distinction matters. If you operate an internet-facing instance, a public exploit is enough to assume scanning and opportunistic attacks are plausible. Attackers do not need a nation-state playbook to exploit basic SQL injection in a web application; these flaws are routinely tested by low-skill actors and automated tools once details become public.
Technical Notes
Status summary for defenders:
- Public PoC/disclosure: Yes, per NVD description
- CISA KEV listed: No
- Confirmed in-the-wild exploitation: Not confirmed from available primary sources
- Safe working assumption: Internet-exposed version 1.0 instances are likely to be probed
How to Detect It
Detection should focus on HTTP requests to /edit_subject.php containing suspicious ID parameter values. Because the vulnerable input is explicitly identified, defenders have a good starting point for targeted monitoring. Review web server logs, WAF telemetry, reverse proxy logs, and application logs for requests where ID contains SQL metacharacters, boolean conditions, unions, comments, or time-delay functions.
You should also correlate suspicious requests with downstream database anomalies. Look for spikes in SQL errors, unexpected response sizes, repeated requests with incrementally altered payloads, or abnormal query latency that might suggest blind or time-based SQL injection testing. Even if the app does not log full queries, web-layer traces often reveal enough to confirm exploitation attempts.
If your logging is weak, start with HTTP access logs. Common patterns include apostrophes, encoded quotes, comment markers, UNION SELECT, SLEEP(, BENCHMARK(, or tautologies such as OR 1=1. Keep in mind that attackers may URL-encode payloads, so search both raw and decoded forms where possible.
Technical Notes
Example suspicious log patterns for Apache or Nginx access logs:
GET /edit_subject.php?ID=1%27%20OR%201%3D1-- HTTP/1.1
GET /edit_subject.php?ID=5%20UNION%20SELECT%20NULL,NULL-- HTTP/1.1
GET /edit_subject.php?ID=1%27%20AND%20SLEEP(5)-- HTTP/1.1
GET /edit_subject.php?ID=-1%27%20UNION%20SELECT%20database()-- HTTP/1.1
Basic grep-based triage on a Linux web server:
```bash grep -RniE ‘edit_subject.php.ID=.(%27|’