CVE-2022-22149

What it actually does

CVE-2022-22149 is an authenticated SQL injection vulnerability in the HelpdeskEmailActions.aspx functionality of Lansweeper 9.1.20.2. A low-privileged authenticated attacker can send a specially crafted HTTP request that causes attacker-controlled input to be interpreted as SQL by the backend database. Because the CVSS impact is high for confidentiality, integrity, and availability, successful exploitation may allow database reads, modification or deletion of data, authentication bypass depending on database contents and application logic, and potentially broader compromise if database permissions, stored procedures, or operating-system command execution features are exposed.

Why it matters to the business

Successful exploitation can expose asset inventory, user, ticket, configuration, and operational data stored in Lansweeper, and may allow attackers to alter or destroy records that organizations rely on for IT operations, auditing, and incident response. Because Lansweeper commonly contains broad visibility into endpoints, software, users, and infrastructure, compromise of this system can materially improve an attacker’s ability to map the environment and plan follow-on attacks. The vulnerability has a high CVSS score, a high EPSS probability, and public exploit availability, so organizations running affected versions should treat it as a priority even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first obtains valid credentials for the Lansweeper web application, which may be a low-privileged account. They then send crafted HTTP requests to the HelpdeskEmailActions.aspx endpoint containing SQL syntax in a vulnerable parameter. The application passes the malicious input into a SQL query without proper parameterization, causing the database to execute attacker-controlled SQL. From there, the attacker may enumerate database metadata, extract sensitive records, modify helpdesk or asset data, create or alter application users if accessible through database writes, or attempt database-level privilege escalation. If the database service account has excessive privileges, the attacker may pivot from data compromise to more disruptive actions such as dropping tables, corrupting records, or attempting command execution through database features.

How to fix it

Upgrade Lansweeper to a vendor-fixed version newer than the affected 9.1.20.2 release. Because no exact fixed version was provided in the input, consult Lansweeper’s official security advisory and release notes and deploy the latest supported release available for the installed major version, or upgrade to the current stable version. Restrict access to the Lansweeper web interface to trusted administrative networks or VPN users, enforce strong authentication and MFA where supported, and remove unnecessary user accounts. Review database permissions used by the Lansweeper application and ensure the application account has the minimum privileges required. As a temporary mitigation where immediate patching is not possible, limit access to HelpdeskEmailActions.aspx, apply web application firewall rules for SQL injection patterns, monitor the endpoint closely, and ensure reliable backups are available before remediation.

How to confirm the fix worked

Confirm the installed Lansweeper version is no longer 9.1.20.2 or any other vendor-identified vulnerable release. Validate from the application UI, server installation metadata, and vendor-supported version-check mechanisms. Review release notes to ensure the deployed build includes the fix for the HelpdeskEmailActions.aspx SQL injection issue. From a controlled security testing host and with authorization, perform non-destructive SQL injection validation against the previously vulnerable HelpdeskEmailActions.aspx parameters, verifying that SQL metacharacters and boolean or time-based probes are safely handled and do not alter query behavior. Confirm that web access controls restrict the Lansweeper interface to intended users and networks. Review application and database logs after patching to ensure no continuing SQL errors or suspicious requests are observed.

Typical attack path

1. Identify an exposed Lansweeper web interface and determine whether it is running an affected version such as 9.1.20.2.
2. Authenticate to the Lansweeper application using stolen, reused, phished, or otherwise valid credentials.
3. Access the HelpdeskEmailActions.aspx functionality and identify injectable request parameters.
4. Submit crafted HTTP requests containing SQL injection payloads to alter backend SQL query behavior.
5. Confirm exploitation using benign SQL logic tests, timing behavior, error responses, or controlled data extraction.
6. Enumerate database schema, application users, configuration data, asset inventory, and helpdesk records.
7. Exfiltrate sensitive operational data or modify records, accounts, permissions, or application configuration.
8. Use the harvested inventory and configuration data to support lateral movement, credential attacks, or further compromise of managed systems.

How to detect it

Investigate historical exploitation by correlating Lansweeper web access logs, IIS logs if applicable, application logs, database audit logs, and authentication logs. Focus on authenticated requests to HelpdeskEmailActions.aspx containing SQL metacharacters, encoded payloads, boolean conditions, UNION queries, stacked queries, database metadata access, or time-delay functions. Review HTTP 500 responses, application exceptions, and SQL syntax errors around this endpoint, as failed probing often precedes successful exploitation. In database logs, look for queries originating from the Lansweeper application account that reference system catalogs, enumerate tables or columns, use UNION SELECT unexpectedly, invoke delay functions, or access unusually large volumes of records. Also review Lansweeper account activity for unusual login sources, newly created or modified users, unexpected permission changes, bulk exports, or activity outside normal administrative hours. If exploitation is suspected, preserve web logs, database transaction logs, application logs, and a forensic copy of the Lansweeper database before making major changes.

• HelpdeskEmailActions.aspx
• UNION SELECT
• UNION%20SELECT
• ' OR '1'='1
• %27%20OR%20%271%27%3D%271
• OR 1=1
• OR%201%3D1
• WAITFOR DELAY
• WAITFOR%20DELAY
• SLEEP(
• BENCHMARK(
• information_schema
• INFORMATION_SCHEMA
• sys.objects
• sys.columns
• @@version
• xp_cmdshell
• ';--
• %27%3B--
• --
• /*
• */

What your security team should do

• Immediately inventory all Lansweeper deployments and identify any running version 9.1.20.2 or other vendor-confirmed vulnerable builds.
• Prioritize patching because public exploit code is available and EPSS is high, indicating meaningful likelihood of exploitation in the wild.
• Restrict Lansweeper web access to trusted networks, administrative jump hosts, or VPN until patching is complete.
• Audit Lansweeper user accounts, remove stale accounts, enforce least privilege, and enable MFA or SSO protections where available.
• Review web server, application, and database logs for suspicious requests to HelpdeskEmailActions.aspx, SQL errors, time-based SQL injection patterns, and unusual data access.
• Rotate credentials stored in or accessible through Lansweeper if exploitation is suspected, especially service accounts or integration credentials.
• Validate database least privilege for the Lansweeper application account and disable dangerous database features not required by the application.
• Create SIEM detections for SQL injection payloads targeting HelpdeskEmailActions.aspx and for abnormal database activity originating from the Lansweeper application server.
• Ensure recent backups of the Lansweeper database exist and test restoration procedures in case data integrity was affected.
• If signs of compromise are found, treat Lansweeper data as potentially exposed and use the asset inventory to assess likely follow-on targeting.