CVE-2015-20120 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 describes multiple time-based blind SQL injection flaws that unauthenticated attackers can use to extract database information by sending requests whose response time reveals the answer.
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 "/admin/" --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
The root cause is CWE-89 in the usual sense: user-supplied input is joined into a SQL statement, so the database cannot tell data from instructions. The flaw sits in multiple application parameters, and the record rates the attack network reachable, low complexity and needing no privileges.
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.
Try it yourself
This walkthrough shows how a scan surfaces a weakness like this one and what the finding looks like.
Click through it at your own pace, or open it full screen.
Quick check
What does the record say about a fix?
Nothing. It lists no fixed version and the advisory pages I read do not name one. Check the vendor directly before relying on any patch claim.
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.
