CVE-2026-111871: Unauthenticated SQL Injection in Online-Examination-System subjectsdb.php

Summary

CVE-2026-111871 describes a SQL injection weakness in Online-Examination-System, an open-source project published on GitHub by itsmeravitejak. The affected component is the file qsdb/usersdb/brandb/topicsdb/subjectsdb.php, and the injection is reached by manipulating the arguments query, qtype, sortname, or sortorder. The attack can be launched remotely, without credentials and without user interaction, and an exploit has already been made public. The project does not use versioning, so no fixed release can be identified, and the maintainer has not yet responded to the issue report filed against the repository.

Technical Analysis

The weakness is classified under CWE-74, the generic injection class, while the description specifies the concrete behavior as SQL injection. According to the advisory, the impacted element is an unknown function of the file qsdb/usersdb/brandb/topicsdb/subjectsdb.php. In other words, the vulnerable file path is known, but the advisory does not name the specific function inside it where the injection occurs — that detail is not fully disclosed.

What is disclosed is the set of attacker-reachable inputs: manipulation of the arguments query, qtype, sortname, or sortorder leads to SQL injection. The argument names indicate that the script accepts search and sorting input, a pattern typical of database-driven PHP pages. The advisory does not describe how these arguments are processed internally, so the exact sink of the injection — the code location where tainted data meets a query — is not documented.

The CVSS 3.1 base score is 7.3, with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L, and the severity is rated MEDIUM in the source data. Breaking the vector down:

AV:N (Network) — the attack can be launched remotely over a network.
AC:L (Low) — no special conditions are required for the attack to succeed.
PR:N (None) — no privileges are needed; the attacker does not need an account.
UI:N (None) — no user interaction is required.
S:U (Unchanged) — the impact stays within the security scope of the vulnerable component.
C:L/I:L/A:L (Low) — the scored impact on confidentiality, integrity, and availability is low.

Two contextual facts raise the practical risk beyond what the score alone conveys. First, the advisory states that the exploit has been made available to the public and could be used for attacks, which removes the development effort an attacker would otherwise need. Second, the project was informed of the problem early through an issue report but has not responded yet, so there is no vendor-issued fix at the time of writing. An unauthenticated injection with a public exploit and no patch is a combination that defenders should treat as actively exploitable.

Affected Software and Versions

The affected product is Online-Examination-System, a project hosted on GitHub under the account itsmeravitejak. The weakness affects the code up to commit e6208e630b14657999bbfe4c9912302d2a1e2449.

The advisory is explicit about the versioning situation: the product does not use versioning, which is why information about affected and unaffected releases is unavailable. There are no release numbers to check, no fixed version to upgrade to, and no vendor statement delineating vulnerable builds. The commit hash is the only reference point for determining whether a given copy of the code falls in the affected range.

For operators, this has a concrete consequence: a standard version check against an inventory entry is impossible. Determining exposure instead means inspecting the deployed source — specifically whether qsdb/usersdb/brandb/topicsdb/subjectsdb.php is present and how it handles the four named arguments — and comparing the code state against the referenced commit in the repository history.

The vulnerable file path, again, is qsdb/usersdb/brandb/topicsdb/subjectsdb.php. The nested path places the file among a group of database-related scripts in the project, but the advisory does not describe the other files, and no additional endpoints are named.

Impact

The scored impact follows directly from the CVSS vector: low impact to confidentiality, low impact to integrity, and low impact to availability, with the scope unchanged. In practical terms, the scoring anticipates that a successful injection can expose or alter data in the backend database and can degrade its availability to a limited degree, without spilling over into other security scopes.

Because the attack requires no privileges and no user interaction, any deployment an attacker can reach is exposed by default. There is no authentication barrier to slow an attack down or attribute it, and nothing about the attack requires a victim to click, open, or approve anything.

The public availability of an exploit compounds this. The advisory states plainly that the exploit has been made available to the public and could be used for attacks. When an unauthenticated, remotely exploitable injection in a specific file has a working public exploit, the population of attackers able to use it expands from skilled SQL injection specialists to anyone who can run a script.

What the advisory does not disclose is which data is reachable through the injection: the affected queries, the tables involved, and the function's role in the application are not described. If the backend database holds examination-related records, a successful injection could expose or manipulate them — but that is an inference from the product category, not from the advisory. The advisory itself does not detail the reachable data, so that part of the impact analysis remains open.

Exploitation Scenario

The following scenario is illustrative and is derived strictly from the information in the advisory. It does not reproduce the public exploit's payload, which is not included in the available data.

Consider an organization that has deployed Online-Examination-System on a server reachable from the internet. Because the vulnerable functionality requires no authentication — the CVSS vector scores privileges as none — the attacker does not need an account on the examination platform.

The attacker identifies a deployment serving qsdb/usersdb/brandb/topicsdb/subjectsdb.php.
The attacker sends a request to that file in which one of the four arguments — query, qtype, sortname, or sortorder — carries manipulated input instead of an expected value.
The manipulated argument reaches the unnamed vulnerable function, where it is incorporated into a database query without adequate neutralization, consistent with the SQL injection classification.
The database engine executes the altered query. Depending on the injection context, the attacker can observe results, trigger errors that reveal information, or modify data — the advisory scores all three impact dimensions as low but non-zero.

Because the attack is remote, unauthenticated, and low-complexity, the sequence can be carried out with a single HTTP request or a short scripted loop. The advisory does not disclose the exact injection strings used by the public exploit, so this scenario stops at the mechanism level rather than the payload level.

Detection and Mitigation

There is no vendor fix. The project was notified through an issue report and has not responded, and the project's lack of versioning means there is no patched release to upgrade to. Any mitigation therefore falls to whoever operates a deployment.

Detection guidance, based on what the advisory discloses:

Review web server and application logs for requests to qsdb/usersdb/brandb/topicsdb/subjectsdb.php, focusing on the query, qtype, sortname, and sortorder parameters.
Flag requests where those parameters contain unexpected characters or structures rather than ordinary search or sorting values. The advisory does not publish the public exploit's signatures, so detection must be behavioral rather than signature-based.
Watch for database errors surfacing in responses from that file, and for unusual query volume against the backend database originating from that endpoint.

Mitigation guidance, as generic engineering practice rather than vendor advice:

Restrict network access to the vulnerable file — for example by placing the deployment behind authentication or an allowlist — since the injection requires no privileges.
At the code level, replace any string-concatenated SQL in subjectsdb.php with parameterized queries or prepared statements, and allowlist the accepted values for sortname and sortorder against known columns and directions.
As a stopgap, web application firewall rules targeting the four named parameters on that path can reduce exposure, though WAF rules are not a substitute for fixing the query construction.
If you operate this system and cannot modify the code, treat the instance as vulnerable: isolate it from untrusted networks or take it offline until a fix appears in the repository.

To determine whether your copy is affected, compare your deployed code against commit e6208e630b14657999bbfe4c9912302d2a1e2449 in the repository history — the only affected-version reference that exists for this project.

Proof-of-Concept: curl and Burp

The requests below are built only from the file path and the four argument names disclosed in the advisory. The advisory does not include the injection payload used by the public exploit, so the parameter values shown are neutral placeholders rather than working injection strings.

For authorized testing only — test only systems you are permitted to test.

curl -k 'http://<TARGET>/qsdb/usersdb/brandb/topicsdb/subjectsdb.php?query=1&qtype=1&sortname=1&sortorder=1'

The same request as a raw Burp Suite request:

GET /qsdb/usersdb/brandb/topicsdb/subjectsdb.php?query=1&qtype=1&sortname=1&sortorder=1 HTTP/1.1
Host: <TARGET>
User-Agent: insightcve-authorized-test
Accept: */*
Connection: close

Any manipulation of these arguments beyond their expected values should be tested only against instances you own or are explicitly authorized to assess.

Bug Bounty Angle

Be upfront about the context: this is a personal open-source repository, and no bug bounty program is indicated anywhere in the available data. The finding was reported through a GitHub issue (issue #5 in the repository) and catalogued in the vulnerability database VulDB, with a GitHub security advisory (GHSA-2qc2-gvjr-chrr) also published. That is a community-disclosure path, not a paid program.

Still, the case is instructive for hunters working on targets that do pay:

Sorting and filtering parameters are high-yield injection points. Parameters like sortname and sortorder are frequently built by string concatenation because developers assume they control the values. The same pattern recurs in commercial targets, where sort and filter fields are tested far less often than login forms.
Unauthenticated functionality first. The PR:N rating in the CVSS vector is what makes this remotely exploitable by anyone. In bounty scope, endpoints reachable without credentials deserve the earliest and deepest testing.
Disclosure mechanics matter. When a project has no security policy, the realistic paths are the public issue tracker and advisory databases. Document the finding thoroughly — as this case shows, the maintainer may never respond, and the report becomes the permanent record.
Test locally. Open-source code like this can be cloned and tested on your own instance. Attacking deployments you do not own is outside both bounty scope and authorization.

For defenders and triagers on bounty platforms, the case is a reminder that a public exploit combined with an unresponsive maintainer means every internet-facing deployment should be treated as vulnerable until proven otherwise.

Frequently Asked Questions

What is CVE-2026-111871?

A SQL injection weakness in the subjectsdb.php file of itsmeravitejak's Online-Examination-System. Manipulating the query, qtype, sortname, or sortorder arguments triggers it. The attack works remotely without authentication, and a public exploit exists.

Which versions are affected?

The weakness affects the project up to commit e6208e630b14657999bbfe4c9912302d2a1e2449. The product does not use versioning, so information about affected and unaffected releases is unavailable.

Is a fix available for CVE-2026-111871?

No fix is disclosed. The project was informed early through an issue report but has not responded yet, so no patched release or vendor guidance exists at the time of writing.

How severe is CVE-2026-111871?

It is rated MEDIUM with a CVSS 3.1 base score of 7.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L): remotely exploitable at low complexity, with no privileges or user interaction required, and low impact to confidentiality, integrity, and availability.