CVE-2025-13285: High SQL Injection in itsourcecode Online Voting System

CVE-2025-13285 is a high severity SQL injection flaw in itsourcecode Online Voting System 1.0, scored 7.3 by CVSS 3.1. It sits in /login.php and is reached through the Username argument. The record lists no fixed release, so the practical fix is to correct the query code or take the application offline.

What's affected

The record names one product and version: itsourcecode Online Voting System 1.0. The weakness is in the file /login.php, and the input at fault is the Username argument. Exploitation is described as remote, over the network, with low complexity and no user interaction.

The CVSS vector shows that no login is needed to reach the flaw.

The record says an exploit has been made public. It does not say the flaw is exploited in the wild, and it is not on the CISA Known Exploited Vulnerabilities list.

No patched version is named in the record or in its references. Treat every deployment of this version as affected until you have checked the code yourself or heard otherwise from the maintainer.

How to check if you're exposed

Start by finding out whether you run this software at all. Check your web roots, container images and hosting accounts for the product name and for the file named above. On a Linux host the following works as a first pass:

find / -name "login.php" -not -path "/proc/*" 2>/dev/null

If you find it, open the file and look at how the value of the Username argument reaches the database. A query built by joining strings is the problem. A prepared statement with bound parameters is not.

Then look at your web server access logs for requests to that path. Unexpected quote characters, SQL keywords or very long values in the parameter deserve a closer look. A scanner is faster than reading logs by hand. The free in-browser dependency scan at gold.safeguard.sh/scan covers packages, and a static analysis pass will catch string built queries in your own PHP.

What to do now

1. Inventory where this application runs, including test and demo copies that nobody remembers.
2. If it faces the internet and holds real data, take it offline or put it behind a login or an IP allowlist until it is fixed.
3. Replace string built SQL in /login.php with prepared statements. In PHP that means PDO or mysqli with bound parameters.
4. Run the database account with only the rights the app needs. It should not be able to drop tables or read other schemas.
5. Add a web application firewall rule as a stopgap only. It buys time and does not fix the code.
6. Check the maintainer's site or repository for a newer release, and read the advisory before you trust any claim of a fix.
7. Rotate any credentials stored in that database if you cannot rule out access.

A safe query looks like this:

$stmt = $pdo->prepare("SELECT * FROM items WHERE id = ?");
$stmt->execute([$id]);

Why it matters

The root cause is CWE-89 (SQL injection), filed under the broader CWE-74 (injection) class. The application takes input from a request and places it into a SQL statement without separating data from code. The database then reads the attacker's text as part of the command.

Here the CVSS vector rates confidentiality, integrity and availability impact as low each. That reflects what the scoring authority judged likely, and the real impact depends on what the database holds and what rights the app account has. SQL injection in a login or search form is often enough to read or change records that the page was never meant to expose.

Projects like this are usually small codebases copied into many sites. A public exploit and no stated fix mean you cannot wait for a patch to arrive. If a dependency scan or reachability analysis tells you where this code is called from, you can decide quickly whether it is worth keeping. You can look up the entry in the Gold directory.

Quick check

Sources

• NVD record for CVE-2025-13285
• VulDB entry listed in the record

Last reviewed: 19 October 2026.