Safeguard
Vulnerability Analysis•

CVE-2025-8240: High SQL Injection in Exam Form dashboard.php

CVE-2025-8240 is a high SQL injection in Exam Form 1.0 via dashboard.php. No fix is listed. Restrict access, use prepared statements, or retire it.

Safeguard Security Team
4 min read

CVE-2025-8240 is a high severity (CVSS 7.3) SQL injection in code-projects Exam Form Submission 1.0. The flaw is in /user/dashboard.php, where the phone parameter reaches a database query unsafely. Exploit details are public and no fixed version is listed, so restrict access and fix the query or retire the app.

What's affected

code-projects Exam Form Submission version 1.0 is the version named in the record. The vulnerable file is /user/dashboard.php and the argument is phone. The reporter says the phone value arrives in a POST request.

The reporter states that no login or authorization is needed to reach it, so treat that as the working assumption until you test your own copy.

The record gives a CVSS 3.1 score of 7.3 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. The record's own wording calls the issue critical, which is the language VulDB uses for the report, while the numeric score places it in the high band. Both are shown here so you can decide which to weigh.

No fixed version is listed. code-projects Exam Form Submission is a small PHP project of the kind distributed as sample or learning code, and the sources I read show no vendor patch. Check the project page or your own source drop for any newer release before assuming none exists.

How to check if you're exposed

First find out whether you run it. Search your web roots for the vulnerable file name. Adjust the path to your server layout.

find /var/www -name "dashboard.php" 2>/dev/null

If the file exists, open it and look at how the phone value is used. A query built by joining text and the variable, rather than a prepared statement, matches the reported pattern.

Next, see who has been calling it. Your web server access log shows requests to the path.

grep "dashboard.php" /var/log/apache2/access.log | tail -n 50

Look for unusual values in the phone field, long strings, quote characters or SQL keywords, and for requests from addresses you do not recognize. Only test copies you own.

You can also run the free in-browser dependency scan at gold.safeguard.sh/scan on the project's manifests. It covers third-party packages, so it will not find a flaw in the application's own code, but it will show what else in the project is out of date.

What to do now

  1. Find every copy of code-projects Exam Form Submission in your environment, including test and demo installs.
  2. Take public-facing copies offline, or put them behind a VPN or an allowlist of trusted addresses.
  3. Rewrite the query in dashboard.php to use prepared statements with bound parameters, and validate the type of phone.
  4. Run the database account with the least privilege the page needs. A page that only reads should not hold write or admin rights.
  5. Review access logs and the database for unexpected changes, and rotate any credentials stored in the database if you see signs of misuse.
  6. If the app is a sample or training project, remove it from any server that holds real data.

Why it matters

The weakness is CWE-89 (SQL Injection), a child of CWE-74 (Injection). The application builds a SQL statement by joining text with a value taken from the request. The database cannot tell which part is the developer's command and which part is user data, so a crafted value can change what the statement does.

The record does not flag this CVE as CISA KEV, and it makes no claim about attacks seen in the wild. It does say a public exploit has been disclosed, which lowers the effort for anyone who finds the app exposed. Software like this tends to show up on small business servers and in student projects that were never meant for production, which is exactly why an inventory matters.

Quick check

Is there a patch for CVE-2025-8240?

The record lists no fixed version for code-projects Exam Form Submission 1.0. Neither the NVD record nor the reporter page names a patch, so the practical fix is to change the code to use prepared statements, or to stop running the application.

Does a WAF solve this?

A web application firewall can block some injection attempts, but it is a stopgap. The query itself stays unsafe, and filters are routinely bypassed. Parameterized queries remove the problem at the source.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.