CVE-2015-20121 is a high severity SQL injection (CVSS 8.2) in Next Click Ventures RealtyScript, version 4.0.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: Next Click Ventures RealtyScript.
- Version: 4.0.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 names two entry points: the GET parameter u_id in /admin/users.php and the POST parameter agent[] in /admin/mailer.php. Both reach the database without neutralizing input, and the record describes time-based blind techniques that can extract data or cause a denial of service.
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 "users.php" --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 RealtyScript 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
This is textbook CWE-89. A request value is concatenated into a query instead of being passed as a bound parameter. The affected input here is u_id and agent[]. The vector shows a network attack with low complexity and no privileges required.
The practical impact is reading of database contents by a remote visitor, and in some entries changing data or denial of service. 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
Is a web application firewall enough?
It can reduce risk while you work, but it does not remove the flaw. The query still needs to use bound parameters.
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.
