CVE-2019-25506 is a high severity SQL injection (CVSS 8.2) in FreeSMS, version 2.1.2. The record names no fixed version or patch. Check the vendor or project, block or restrict the affected page, and replace the string-built query with a prepared statement.
What's affected
- Product: FreeSMS.
- Version: 2.1.2. The record lists no other versions, so treat any release of this script you cannot date as suspect.
- Fixed version: none confirmed in the record or the advisory pages I read. Check the vendor or project page for a patched release.
- Weakness: CWE-89, SQL injection.
- CVSS 8.2 (high), vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N.
The record describes a boolean-based blind injection in the password parameter of /pages/crc_handler.php?method=login. An attacker can sign in as any known user and then change that user's password through the profile update function.
How to check if you're exposed
Start by finding out whether you run this software at all. Look for the application directory on your web servers, or search your code and hosting inventory for the product name.
grep -rln "crc_handler" --include=*.php /var/www 2>/dev/null
If the file shows up, read how the value is used. Any query built by string concatenation or interpolation from request data is the flaw. Then check your web logs for requests to that endpoint with unusually long or odd parameter values, or with repeated requests that differ only slightly. A scanner can do the same check from outside: run a DAST scan against your own staging copy, or use the free dependency scan at gold.safeguard.sh/scan for any packaged components.
What to do now
- Find every install of FreeSMS and confirm the version.
- Check the vendor or project page for a fixed release. None is confirmed in the record, so do not assume one exists.
- If you cannot patch, restrict the affected endpoint at the web server or firewall to trusted addresses, or take the application offline.
- Change the code to use prepared statements for every query that touches request data.
- Give the application's database account only the rights it needs, and rotate the database and admin passwords if logs show suspicious requests.
- If the product looks unmaintained, plan a replacement.
A bound parameter looks like this in PHP with PDO:
$stmt = $pdo->prepare('SELECT * FROM items WHERE id = :id');
$stmt->execute([':id' => $_GET['id']]);
Why it matters
The weakness class is CWE-89. Anything the application builds into a query string from request data is a candidate, and here that covers the login password. The vector rates it network reachable, low complexity and unauthenticated.
The practical impact is signing in without valid credentials, plus possible reading of database contents. The record lists a public Exploit-DB entry as a reference, so the technical details are public. That is not confirmation of attacks in the wild. The record's CISA KEV flag is false.
Quick check
Does this need a login?
The record describes it as unauthenticated. Confirm by testing your own copy.
How do I prove the fix worked?
Retest the same endpoint on a staging copy after the code change and confirm the request is treated as plain data. Keep the test in your regression suite.
Sources
Last reviewed: 19 October 2026.
