CVE-2021-30117

What it actually does

CVE-2021-30117 is a semi-authenticated boolean-based blind SQL injection in Kaseya VSA. The vulnerable endpoint is /InstallTab/exportFldr.asp, where the fldrId parameter is incorporated into a backend SQL query without sufficient validation or parameterization. An attacker with a valid or stolen low-privilege VSA web session can submit crafted SQL expressions and infer query results from application behavior, such as differences between HTTP 200 responses and HTTP 500 errors. Because this is blind SQL injection, data extraction may be iterative, but successful exploitation can allow unauthorized database reads, modification of application data, and potentially further compromise depending on database permissions and application architecture.

Why it matters to the business

Successful exploitation can expose sensitive VSA data, compromise administrative workflows, alter managed-service configuration data, or support follow-on attacks against systems managed through VSA. Because VSA is an administrative platform with broad operational reach, compromise can have outsized business consequences, including service disruption, loss of trust, incident response costs, and potential downstream impact to managed endpoints. Although this CVE is not currently listed in CISA KEV and no fixed version was provided in the input, the high CVSS score and high EPSS value indicate meaningful exploitation risk, especially for internet-facing or legacy VSA deployments that have not been fully updated since the 2021 disclosure.

How an attack unfolds

An attacker first obtains access to a valid VSA web session or session-related cookie, potentially through another vulnerability, credential theft, phishing, or reuse of an exposed session. With that semi-authenticated access, the attacker sends HTTP GET requests to /InstallTab/exportFldr.asp and injects SQL logic into the fldrId query parameter. By comparing application responses for true and false SQL conditions, such as a normal Export Folder page versus a server error, the attacker can infer database values one bit or condition at a time. Over repeated requests, the attacker can enumerate schema details, extract sensitive records, or test whether higher-impact SQL operations are possible. If database permissions allow writes or execution of dangerous database functionality, the attacker may attempt to alter records, create persistence through application data changes, or chain the SQL injection with other weaknesses to expand control of the VSA application.

How to fix it

Upgrade Kaseya VSA to a vendor-supported, fully patched release that includes the SQL injection fix for /InstallTab/exportFldr.asp and related 2021 VSA security updates. If exact fixed versions are not available from internal asset records, verify current guidance directly from Kaseya and apply the latest cumulative security updates rather than attempting to patch only this single issue. Restrict VSA administrative interfaces from direct internet exposure wherever possible by placing them behind VPN, zero-trust access controls, or allowlisted administrative networks. Enforce strong authentication, review and invalidate active sessions after patching, and rotate credentials for privileged VSA users. As compensating controls, deploy WAF or reverse-proxy rules that block SQL metacharacters and SQL keywords in the fldrId parameter for /InstallTab/exportFldr.asp, but do not rely on filtering as a substitute for patching. Review database account permissions used by the application and ensure least privilege is enforced.

How to confirm the fix worked

Confirm the deployed Kaseya VSA version is vendor-supported and includes the post-disclosure security updates addressing this vulnerability. Validate that /InstallTab/exportFldr.asp no longer accepts SQL expressions in fldrId and that the parameter is treated strictly as an expected identifier, preferably a numeric value. A controlled test can compare a normal fldrId request with benign SQL-like payloads and confirm that all invalid inputs are rejected consistently with a 400-series response or equivalent validation error, without backend SQL behavior differences. Review web server and application logs for historical requests to /InstallTab/exportFldr.asp containing encoded parentheses, SELECT, CASE WHEN, UNION SELECT, quote characters, or other SQL injection patterns. Confirm that VSA administrative access is restricted to approved networks and that no obsolete internet-facing VSA instances remain exposed.

Typical attack path

1. Identify an accessible Kaseya VSA web interface.
2. Acquire or reuse a valid low-privilege or semi-authenticated VSA session.
3. Send a baseline request to /InstallTab/exportFldr.asp with a normal numeric fldrId value.
4. Submit crafted SQL expressions in the fldrId parameter and observe response differences such as HTTP 200 versus HTTP 500.
5. Use boolean-based blind SQL injection techniques to infer database content through repeated true/false conditions.
6. Enumerate database structure, users, session-related data, or application configuration values.
7. Attempt unauthorized data access, data modification, privilege escalation, or chaining with additional vulnerabilities depending on database permissions and application exposure.

How to detect it

To determine whether this vulnerability was already exploited, review web server, reverse proxy, WAF, and Kaseya VSA application logs for requests to /InstallTab/exportFldr.asp where the fldrId parameter contains SQL syntax rather than a simple expected identifier. Focus on encoded or decoded strings containing SELECT, CASE WHEN, UNION SELECT, 1=1, quote characters, parentheses used as SQL expressions, and payloads that produce alternating HTTP 200 and HTTP 500 responses. Because this is blind SQL injection, exploitation may appear as many repetitive requests from the same source IP, session, user agent, or authenticated account with small variations in fldrId. Correlate suspicious requests with ASP session cookies, VSA session identifiers, login events, failed application errors, database errors, privilege changes, new or modified VSA users, unexpected agent procedures, and configuration changes. Also review database logs, if available, for unusual SELECT statements, SQL errors, conditional CASE expressions, UNION queries, or high-volume repetitive queries originating from the VSA application account around the same timestamps.

• /InstallTab/exportFldr.asp?fldrId=
• fldrId=%28SELECT%20%28CASE%20WHEN
• fldrId=(SELECT (CASE WHEN
• CASE%20WHEN%20%281%3D1%29
• CASE WHEN (1=1)
• UNION%20SELECT
• UNION SELECT
• SELECT%201%20UNION%20SELECT%202
• SELECT 1 UNION SELECT 2
• /InstallTab/exportFldr.asp?fldrId=%28SELECT
• /InstallTab/exportFldr.asp?fldrId='
• /InstallTab/exportFldr.asp?fldrId=%27
• HTTP/1.1" 500
• GET /InstallTab/exportFldr.asp

What your security team should do

• Immediately inventory all Kaseya VSA instances, including externally hosted, legacy, disaster recovery, and test deployments.
• Prioritize patching or decommissioning any internet-accessible VSA instance that has not received the full 2021 security update set and current vendor patches.
• Restrict access to VSA administrative endpoints using VPN, zero-trust access, IP allowlisting, and MFA.
• Search historical HTTP access logs for SQL injection patterns targeting /InstallTab/exportFldr.asp and the fldrId parameter.
• Invalidate active VSA sessions and rotate privileged credentials if exploitation is suspected or patch status is uncertain.
• Add WAF/SIEM detections for SQL keywords and encoded SQL syntax in requests to /InstallTab/exportFldr.asp.
• Review VSA database and application audit logs for suspicious reads, failed errors, privilege changes, unexpected configuration changes, and abnormal administrative activity.
• Treat positive exploitation indicators as a high-severity incident because VSA compromise may enable broader impact to managed systems.