CVE-2022-21145

What it actually does

This vulnerability is a stored cross-site scripting flaw in Lansweeper's WebUserActions.aspx functionality. An authenticated attacker with high privileges can submit a crafted HTTP request containing JavaScript that is stored by the application and later rendered in another user's browser. When a victim views the affected page, the injected script executes in the security context of the Lansweeper web application, allowing limited confidentiality and integrity impact such as reading page content available to the victim, performing actions as the victim through the browser, modifying displayed data, or exfiltrating accessible tokens or data not protected by browser controls. The CVSS scope change reflects that execution occurs in the victim browser rather than only on the server.

Why it matters to the business

Successful exploitation can undermine trust in the Lansweeper administrative interface by allowing malicious script execution against users who view affected content. Because Lansweeper is commonly used for asset discovery and IT inventory, compromise of privileged web sessions may expose sensitive operational information about systems, software, users, and network assets. Although this issue is not listed in CISA KEV and has moderate CVSS severity, the high EPSS score and public exploit availability indicate a meaningful likelihood of attempted exploitation, especially against internet-accessible or broadly reachable Lansweeper consoles.

How an attack unfolds

An attacker first obtains an account with sufficient privileges to access and submit data through the vulnerable WebUserActions.aspx functionality. The attacker then sends a specially crafted HTTP request containing JavaScript in a field that the application stores without properly neutralizing. The payload remains in Lansweeper until a user later opens the affected page or workflow. When that user views the stored content, the browser interprets the attacker-controlled value as executable JavaScript. The script can then interact with the Lansweeper web application as the victim, read data visible in the page, issue same-origin requests, alter displayed content, or send accessible information to an attacker-controlled endpoint. The attack generally requires victim interaction because the malicious script runs when another user views the affected interface.

How to fix it

Upgrade Lansweeper to a vendor-supported version that includes the fix for this stored XSS vulnerability. Because no exact fixed version was provided in the input, treat Lansweeper 9.1.20.2 and earlier vulnerable builds as requiring upgrade or vendor confirmation. If immediate upgrade is not possible, restrict access to the Lansweeper web interface to trusted administrative networks or VPNs, remove unnecessary user privileges, review and reduce accounts with elevated roles, enable strong authentication, and consider web application firewall rules that block obvious script injection payloads targeting WebUserActions.aspx. Mitigations should not be considered a substitute for patching because stored payloads may persist in application data until removed.

How to confirm the fix worked

Confirm the deployed Lansweeper version is newer than the affected 9.1.20.2 build and is identified by the vendor as fixed. Review vendor release notes or support guidance for the specific corrected release. After patching, test that inputs handled by WebUserActions.aspx are encoded or rejected by submitting harmless XSS test strings in a controlled environment and verifying they render as text rather than execute. Inspect existing stored values rendered by WebUserActions.aspx for embedded script tags, JavaScript URLs, encoded HTML, or event handlers, and remove suspicious content. Validate that access to the Lansweeper web interface is limited to expected users and networks.

Typical attack path

1. Identify a reachable Lansweeper web interface running an affected version such as 9.1.20.2.
2. Authenticate with an account that has sufficient privileges to access the vulnerable WebUserActions.aspx functionality.
3. Submit a crafted HTTP request containing JavaScript or HTML event-handler payloads to the vulnerable field or action.
4. Wait for the malicious content to be rendered when another user accesses the affected page.
5. Execute JavaScript in the victim user's browser session under the Lansweeper application origin.
6. Use the victim's browser context to read accessible page data, perform unauthorized in-application actions, or exfiltrate accessible information.

How to detect it

To determine whether exploitation already occurred, review IIS or reverse proxy access logs for GET or POST requests to /WebUserActions.aspx containing suspicious HTML or JavaScript payloads, including URL-encoded variants. Correlate those requests with Lansweeper application audit logs, authentication logs, and administrative activity to identify the submitting account and any subsequent actions performed by users who later viewed affected pages. Inspect stored content rendered by the WebUserActions.aspx workflow for script tags, JavaScript URLs, inline event handlers, encoded HTML entities, external callback URLs, or references to credential/session exfiltration. Review browser security telemetry, proxy logs, DNS logs, and EDR network events for Lansweeper users making unexpected outbound requests immediately after browsing the Lansweeper interface. Look for evidence of unauthorized changes, unusual asset inventory access, unexpected administrative actions, or repeated visits to the affected page following the suspicious submission. Because stored XSS executes client-side, server logs may show only the original malicious submission and subsequent page views rather than a conventional server compromise.

• /WebUserActions.aspx
• POST /WebUserActions.aspx
• GET /WebUserActions.aspx
• %3Cscript
• <script
• </script>
• javascript:
• %6a%61%76%61%73%63%72%69%70%74%3a
• onerror=
• onload=
• onclick=
• onmouseover=
• document.cookie
• document.domain
• localStorage
• sessionStorage
• XMLHttpRequest
• fetch(
• new Image(
• eval(
• atob(
• String.fromCharCode
• <img src=x onerror=
• <svg onload=
• %3Cimg%20src%3Dx%20onerror%3D
• %3Csvg%20onload%3D

What your security team should do

• Prioritize upgrade or vendor-validated remediation because public exploit code is available and EPSS is high despite the moderate CVSS score.
• Inventory all Lansweeper web consoles and identify instances running version 9.1.20.2 or older affected builds.
• Restrict Lansweeper web access to trusted administrative networks, VPN, or identity-aware access controls, especially for externally reachable deployments.
• Review privileged Lansweeper accounts and remove unnecessary administrative access, since exploitation requires high privileges.
• Search web and application logs for suspicious requests to WebUserActions.aspx containing script tags, encoded HTML, JavaScript URLs, or browser event-handler attributes.
• Inspect stored application content associated with web user actions for persistent malicious payloads and remove any discovered script content.
• Monitor for unusual Lansweeper administrative actions following suspicious WebUserActions.aspx activity, including unexpected configuration changes or asset data access.
• Consider deploying CSP and additional response security headers where supported to reduce the impact of future XSS conditions.