CVE-2022-21210

What it actually does

CVE-2022-21210 is an authenticated SQL injection vulnerability in the AssetActions.aspx functionality of Lansweeper 9.1.20.2. A low-privileged authenticated user can send crafted HTTP requests that cause attacker-controlled input to be interpreted as SQL by the backend database. Successful exploitation can allow unauthorized reading, modification, or deletion of Lansweeper database records and, depending on database permissions and configuration, may enable broader compromise of the application data store or underlying database server. The CVSS 8.8 rating reflects network exploitability, low attack complexity, no user interaction, and high confidentiality, integrity, and availability impact. Public exploit availability and a high EPSS score indicate materially elevated exploitation likelihood even though the issue is not currently listed in CISA KEV.

Why it matters to the business

Lansweeper commonly contains detailed asset inventory, software, hardware, vulnerability, and network discovery data, so compromise can expose sensitive infrastructure information useful for follow-on attacks. An attacker may alter inventory records, disrupt asset management workflows, delete data, or use the platform’s visibility to identify high-value systems. Because exploitation requires only an authenticated account and public exploit material exists, organizations using affected Lansweeper versions should treat this as a high-priority remediation item despite the absence of KEV status.

How an attack unfolds

An attacker first obtains valid Lansweeper application credentials through phishing, credential reuse, insider access, or compromise of a low-privileged account. The attacker then accesses the Lansweeper web interface and sends a specially crafted request to the AssetActions.aspx endpoint containing SQL syntax in a vulnerable parameter. If the application fails to properly parameterize the database query, the backend SQL engine executes attacker-influenced statements. The attacker may confirm exploitation through SQL error messages, timing behavior, or returned data, then enumerate database structure, extract asset and credential-adjacent information, modify records, or attempt destructive queries. In more permissive database configurations, the attacker may try to escalate from database access to operating system command execution or lateral movement using information stored in Lansweeper.

How to fix it

Upgrade Lansweeper to a vendor-supported version that contains the fix for this vulnerability. Because no exact fixed version was provided in the input, consult Lansweeper security advisories and release notes and move off version 9.1.20.2 or any other affected build. If immediate upgrade is not possible, restrict access to the Lansweeper web interface to trusted administrative networks or VPN users, enforce MFA for Lansweeper authentication where supported, remove unnecessary user accounts, reduce privileges for non-administrative users, and monitor or block suspicious requests to AssetActions.aspx at the reverse proxy or WAF. Ensure the Lansweeper database account follows least privilege and does not have unnecessary administrative permissions such as broad DDL rights, sysadmin-level privileges, or dangerous extended procedure access. Maintain reliable backups of the Lansweeper database before patching or making containment changes.

How to confirm the fix worked

Confirm the installed Lansweeper version is no longer 9.1.20.2 or any vendor-identified affected release. Review vendor release notes or support confirmation to verify the deployed version includes the SQL injection fix. From an authenticated test account in a non-production or approved testing window, verify that malformed SQL metacharacters sent to AssetActions.aspx do not produce SQL errors, timing anomalies, stack traces, or unexpected response differences. Check that the Lansweeper web interface is not broadly exposed to the internet unless explicitly required and protected. Validate that the backend database account used by Lansweeper has least-privilege permissions. Review WAF, reverse proxy, IIS, application, and SQL Server logs for historical requests or database errors associated with AssetActions.aspx before declaring the environment clean.

Typical attack path

1. Acquire valid credentials for the Lansweeper web application.
2. Authenticate to the Lansweeper interface over the network.
3. Send crafted HTTP requests to AssetActions.aspx targeting the vulnerable SQL query path.
4. Validate injection using error-based, boolean-based, or time-based SQL injection behavior.
5. Enumerate database schema and extract asset inventory, user, configuration, and discovery data.
6. Modify or delete Lansweeper records, or use the exposed asset intelligence to plan follow-on attacks against other systems.
7. Attempt further escalation against the database server if database permissions and SQL Server configuration allow it.

How to detect it

To determine whether exploitation already occurred, correlate authenticated HTTP requests to AssetActions.aspx with application errors, SQL Server errors, unusual response sizes, or timing anomalies. Review IIS logs, reverse proxy logs, WAF events, Lansweeper application logs, Windows Event Logs on the Lansweeper server, and SQL Server logs around suspicious request times. Look for SQL injection probes such as quotes, comment markers, UNION-based queries, WAITFOR DELAY timing tests, stacked query separators, SQL Server metadata enumeration, and sqlmap user-agent strings. Pay attention to successful authenticated sessions from unusual source IPs, impossible travel, new or rarely used accounts accessing AssetActions.aspx, and bursts of repetitive parameterized requests. In SQL Server telemetry, investigate errors like syntax errors near attacker-supplied tokens, unclosed quotation marks, conversion failures, access to system catalog views, attempts to invoke xp_cmdshell, or unusually large SELECT results. If compromise is suspected, check for unauthorized changes or deletions in Lansweeper asset records, newly created application users, altered discovery credentials, unexpected database logins, and anomalous database backup or export activity.

• /AssetActions.aspx
• AssetActions.aspx
• sqlmap
• UNION SELECT
• UNION ALL SELECT
• WAITFOR DELAY
• SLEEP(
• BENCHMARK(
• xp_cmdshell
• INFORMATION_SCHEMA
• sys.objects
• sys.tables
• sys.columns
• @@version
• Unclosed quotation mark after the character string
• Incorrect syntax near
• Conversion failed when converting
• Microsoft OLE DB Provider for SQL Server
• System.Data.SqlClient.SqlException
• ';--
• ";--
• ' OR '1'='1
• " OR "1"="1
• OR 1=1
• AND 1=1
• CHAR(
• CAST(
• CONVERT(

What your security team should do

• Immediately inventory Lansweeper deployments and identify any instance running version 9.1.20.2 or other vendor-confirmed affected versions.
• Prioritize upgrade to a fixed, vendor-supported Lansweeper release because public exploit code is available and EPSS indicates high exploitation probability.
• Restrict Lansweeper web access to trusted networks and require strong authentication for all users, especially administrators.
• Review all Lansweeper accounts for unnecessary access, stale accounts, weak authentication, and excessive privileges.
• Search historical web, proxy, WAF, Lansweeper, and SQL Server logs for suspicious AssetActions.aspx activity and SQL injection patterns.
• If suspicious activity is found, preserve logs, snapshot relevant systems, rotate credentials associated with Lansweeper integrations, and assess whether asset inventory or discovery data was accessed or modified.
• Harden the Lansweeper database account using least privilege and remove unnecessary high-risk SQL Server capabilities.
• Create SIEM detections for SQL injection strings targeting AssetActions.aspx and for SQL Server errors correlated with Lansweeper web requests.