Exam Form Submission CVE-2025-8269

The target application must be running code-projects Exam Form Submission version 1.0, specifically with the /admin/delete_s1.php file accessible over the network. The CVSS 4.0 vector (PR:N) indicates no authentication is required per the submitted assessment, but this conflicts with the /admin/ path convention - organizations must verify whether their deployment enforces authentication on admin endpoints. If the admin interface is exposed without authentication, exploitation is trivially achievable by any remote attacker with network access to the web server. The primary limiting factor is product obscurity: this is a niche PHP educational project with very limited production deployment. No special network position, non-default protocol, or specific OS configuration is required beyond HTTP connectivity to the web application.

The CVSS 4.0 score of 5.5 (Medium) reflects limited impact scope - VC:L, VI:L, VA:L with no subsequent-system impact. The PR:N metric in the submitted vector is notable and potentially conflicts with the /admin/ path context: if the admin interface truly requires no authentication, the risk is materially higher than if auth is enforced. This conflict is not resolved by available data and should be verified against the application's actual authentication flow. EPSS at 0.09% (25th percentile) signals very low observed exploitation probability in the wild despite the public POC, consistent with a niche, low-footprint educational project. The absence from CISA KEV further supports that mass exploitation is not occurring. The primary real-world risk is to organizations that have deployed this specific application in a production or internet-accessible environment, which is expected to be very limited. The public POC lowers the barrier to exploitation, but the product's obscurity is a significant natural limiting factor.

An attacker identifies a publicly accessible instance of Exam Form Submission 1.0 by scanning for the /admin/delete_s1.php path. Using the publicly available proof-of-concept as a reference, the attacker sends a crafted HTTP GET or POST request with a malicious SQL payload in the ID parameter - for example, appending a UNION SELECT clause - causing the backend database to return sensitive data such as credentials or student records. If write access is achievable via the injection point, the attacker could also delete or corrupt exam records.