CVE ID: CVE-2025-34179
Product: NetSupport Manager
Affected Versions: Versions below 14.12.0001
Vulnerability Type: Unauthenticated SQL Injection
Severity: High
CVSS Score: 8.7
Exploitability: Yes – Remotely exploitable without authentication
What NetSupport Manager SQL InjectionNetSupport Manager SQL Injection Actually Means
This newly published vulnerability affects the NetSupport Manager Connectivity Server / Gateway, which is often exposed over HTTPS so remote systems can connect back. The issue is caused by improper handling of user-supplied input in certain HTTPS requests.
Put simply, the gateway takes data from incoming requests and uses it directly in SQLite database queries without properly cleaning it up first. Because of that, an attacker can inject their own SQL statements into the query.
The most concerning part is that this can be done without authentication. If the gateway is reachable, the database can potentially be interacted with by anyone who knows how to talk to it.
Why this is a big deal (beyond the CVSS score)
On paper, this is “just” SQL injection. In reality, it’s more serious because:
- The vulnerable service is commonly internet-facing
- No login or credentials are required
- It sits in remote management software
- It directly talks to a local database
This combination makes it attractive for both targeted attacks and mass scanning. Attackers don’t need to guess passwords or trick users — they just send requests and see what sticks.
Where the vulnerability sits
The issue exists in the Connectivity Server / Gateway HTTPS request handling, specifically where parameters are used to query the FileLinks table inside the local SQLite database.
At a high level:
- Incoming HTTPS request
- Parameter extracted
- SQL query constructed dynamically
- Query executed against SQLite
- No proper input sanitization
That’s the classic setup for SQL injection.
How an attack would realistically unfold
This isn’t a complicated exploit chain. A typical flow would look like this:
- Scanning
- Attacker scans for NetSupport Gateway endpoints
- Identifies them based on response headers or URL patterns
- Probing
- Sends malformed HTTPS requests
- Looks for SQL error messages or response changes
- Injection
- Injects SQL logic into a vulnerable parameter
- Database executes the injected query
- Abuse
- Reads database content
- Modifies FileLinks entries
- Potentially deletes or corrupts records
Because this is SQLite, the attacker is interacting with a local file-based database, not a remote DB server — which often means fewer protections.
Example payload patterns (for detection only)
These are not exploit instructions, but patterns defenders can look for in logs. Delimiters are used intentionally.
' OR '1'='1'[.]--"[.] OR 1=1--' UNION SELECT * FROM FileLinks[.]--' UNION SELECT name FROM sqlite_master[.]--' AND sqlite_version()[.]--
Seeing any of these (or variations) in HTTPS requests hitting the gateway is a strong indicator someone is testing or exploiting the flaw.
What you might see if someone is poking at this
On the network / application side
- Repeated HTTPS requests to the gateway from unfamiliar IPs
- Requests with unusually long or malformed parameters
- SQL-related keywords in request bodies or URLs
- Different response sizes or status codes for similar requests
On the host / database side
- SQLite error messages appearing unexpectedly
- Sudden access to the FileLinks table
- FileLinks entries being created, modified, or deleted without admin action
- Gateway service logs showing unusual query failures
Detection ideas that actually help
Basic log-based detection
service = "NetSupport Gateway"
AND request_body CONTAINS ("UNION", "SELECT", "sqlite", "--")
Web or proxy filtering concept
http.request.uri OR http.request.body
MATCHES "(?i)(union\s+select|sqlite_master|--|or\s+1=1)"
Exposure-based alert
service = "NetSupport Gateway"
AND source_ip NOT IN trusted_ranges
AND request_rate > baseline
This catches scanning behavior even if the payloads change.
How to fix it properly
The right fix (recommended)
- Upgrade NetSupport Manager to version 14.12.0001 or newer
- This version addresses the unsafe query handling
If the gateway is exposed, this should be treated as urgent.
If you can’t patch immediately
Temporary mitigation is better than nothing:
- Restrict gateway access to known IP ranges
- Remove public internet exposure if possible
- Put the gateway behind a WAF or reverse proxy
- Block obvious SQL keyword patterns
- Increase logging until patched
These won’t make you invulnerable, but they reduce risk.
What to do after patching
Even after upgrading:
- Review historical gateway logs
- Look for SQL injection indicators
- Check FileLinks table integrity
- Assume exposure if the service was public and unpatched
- Rotate credentials if the gateway interacts with other systems
SQL injection often leaves little evidence unless someone looks for it.
Who should be especially concerned
This matters most if:
- NetSupport Gateway is internet-facing
- The software is used for remote support or admin
- Patch cycles are slow
- Application logging isn’t routinely reviewed
Those environments are exactly what attackers look for.
Bottom line
CVE-2025-34179 is a straightforward but dangerous vulnerability: unauthenticated SQL injection in a remote management gateway. These are the kinds of flaws attackers exploit quickly because they’re reliable and low effort.
If NetSupport Manager is in your environment, assume it’s being scanned already. Patch it, limit exposure, and check your logs — that’s the practical response.
