CVE-2021-30119

What it actually does

CVE-2021-30119 is an authenticated reflected cross-site scripting flaw in Kaseya VSA. User-controlled values supplied to the `result` parameter of `/HelpDeskTab/rcResults.asp` and the `FileName` parameter of `/done.asp` are reflected into the generated HTML response without sufficient output encoding or sanitization. An attacker with valid access can craft a URL containing JavaScript that executes in the browser of another authenticated VSA user who opens the link. Because the CVSS scope is changed, successful exploitation can affect the victim’s browser session rather than only the vulnerable page, potentially allowing theft of session-related data accessible to JavaScript, unauthorized UI actions in the victim’s context, phishing overlays, or redirection to attacker-controlled content.

Why it matters to the business

Successful exploitation can let an attacker abuse a trusted Kaseya VSA interface to target administrators or helpdesk users, which is operationally significant because VSA is commonly used for endpoint and remote management. The most likely consequences are account/session abuse, unauthorized changes performed through a victim’s browser, credential harvesting, or follow-on compromise of managed infrastructure if a privileged user is targeted. The vulnerability has public exploit examples and a high EPSS score of 0.52687, indicating meaningful likelihood of exploitation despite not being listed in CISA KEV. Organizations using Kaseya VSA should treat exposure as a priority, especially where the web interface is reachable by broad internal user populations or the internet.

How an attack unfolds

An attacker first obtains authenticated access to the Kaseya VSA application or compromises a low-privileged account. They then craft a URL to one of the affected ASP endpoints with a malicious JavaScript payload embedded in the vulnerable query parameter, such as `result` on `/HelpDeskTab/rcResults.asp` or `FileName` on `/done.asp`. The attacker delivers the link to a target user, typically an administrator or helpdesk operator, through email, chat, ticket content, or another trusted workflow. When the victim opens the link while authenticated to VSA, the application reflects the supplied value into the response and the browser executes the injected script in the context of the VSA web application. The script may attempt to read accessible session data, perform actions using the victim’s authenticated browser session, alter page content, prompt for credentials, or redirect the victim to attacker-controlled infrastructure. Follow-on activity depends on the victim’s role and permissions in VSA.

How to fix it

Upgrade Kaseya VSA to a vendor-supported release that includes the fix for this issue. No exact fixed version was provided in the input, so administrators should consult Kaseya’s security advisories and release notes for the applicable patched version for their deployment model. If immediate upgrade is not possible, restrict access to the VSA web interface to trusted networks or VPN users, enforce strong authentication and least privilege, disable or limit unnecessary externally exposed access, and deploy web application firewall rules that block script-like content in the affected parameters. Long-term remediation should include context-aware output encoding for all reflected user input, strict input validation, an appropriate Content Security Policy, and regression testing for reflected XSS in legacy ASP endpoints.

How to confirm the fix worked

Confirm the installed Kaseya VSA version is at or above the vendor-fixed release and that no vulnerable legacy build remains exposed. Test the affected endpoints in a controlled manner by submitting harmless encoded XSS test strings to `result` on `/HelpDeskTab/rcResults.asp` and `FileName` on `/done.asp`; the values should be safely encoded or rejected, not executed by the browser. Review HTTP responses to verify characters such as `<`, `>`, quotes, and script tags are escaped in HTML context. Validate that external exposure is restricted as intended and that WAF or reverse-proxy controls generate alerts or blocks for script-like payloads in these parameters. Re-run authenticated web application scanning against the VSA interface after patching or configuration changes.

Typical attack path

1. Attacker gains or already has authenticated access to the Kaseya VSA application.
2. Attacker identifies a reachable vulnerable endpoint such as `/HelpDeskTab/rcResults.asp` or `/done.asp`.
3. Attacker crafts a URL containing JavaScript in the `result` or `FileName` query parameter.
4. Attacker sends the crafted URL to a target authenticated VSA user, often one with elevated privileges.
5. Victim opens the link, causing the application to reflect the payload into the HTML response.
6. Victim’s browser executes the attacker-supplied JavaScript in the VSA application context.
7. Attacker uses the executed script to steal accessible data, manipulate the page, perform actions as the victim, or stage follow-on compromise.

How to detect it

To determine whether this was already exploited, review web server, reverse proxy, WAF, and application access logs for requests to `/HelpDeskTab/rcResults.asp` with a suspicious `result` parameter and `/done.asp` with a suspicious `FileName` parameter. Look for raw or URL-encoded JavaScript markers such as `<script>`, `</script>`, `alert(`, `document.cookie`, `onerror=`, `onload=`, `javascript:`, encoded angle brackets such as `%3c` and `%3e`, and suspicious external URLs embedded in query strings. Correlate matching requests with authentication logs, user agents, source IPs, referrers, and subsequent privileged actions in VSA. Pay particular attention to cases where a low-privileged or unusual account generated the crafted URL and a privileged account later accessed it. Review browser telemetry, EDR network events, DNS logs, and proxy logs for outbound connections from administrator workstations to unfamiliar domains immediately after VSA page loads. Because reflected XSS often leaves limited server-side artifacts beyond the request itself, prioritize log correlation around the time of suspicious requests and examine whether any administrative actions, configuration changes, file uploads, agent deployments, or credential changes occurred shortly afterward.

• /HelpDeskTab/rcResults.asp?result=<script>
• /HelpDeskTab/rcResults.asp?result=%3cscript%3e
• /HelpDeskTab/rcResults.asp?result=%3Cscript%3E
• /HelpDeskTab/rcResults.asp?result=<script>alert(document.cookie)</script>
• /HelpDeskTab/rcResults.asp?result=%3cscript%3ealert(document.cookie)%3c/script%3e
• /done.asp?FileName=<script>
• /done.asp?FileName=%3cscript%3e
• /done.asp?FileName=%3Cscript%3E
• /done.asp?FileName=";</script><script>
• /done.asp?FileName=%22%3b%3c%2fscript%3e%3cscript%3e
• document.cookie
• alert(document.cookie)
• <script>alert(1)</script>
• %3cscript%3ealert(1)%3c%2fscript%3e
• javascript:
• onerror=
• onload=
• PathData=&originalName=shell.aspx
• originalName=shell.aspx
• FileSize=4388
• TimeElapsed=00:00:00.078

What your security team should do

• Prioritize patching or upgrading Kaseya VSA because public exploit examples exist and EPSS indicates elevated exploitation likelihood.
• Restrict access to the VSA web interface to trusted administrative networks, VPN, or zero-trust access controls; avoid broad internet exposure.
• Review VSA user roles and reduce privileges for accounts that do not require administrative capability.
• Search historical web access logs for XSS payloads targeting `/HelpDeskTab/rcResults.asp` and `/done.asp`, especially requests containing `script`, encoded angle brackets, event handlers, or suspicious redirects.
• Add SIEM detections for script-like values in the `result` and `FileName` query parameters.
• Investigate users who clicked suspicious VSA links or generated requests with injected script content, especially privileged users.
• Review authentication, session, and administrative action logs around suspected XSS requests for unexpected changes made through a victim’s session.
• Harden the application front end with a Content Security Policy and WAF rules where supported, but do not treat these as substitutes for patching.