CVE-2021-30118

What it actually does

The flaw is an unauthenticated arbitrary file upload that can become remote code execution when an attacker writes server-executable content, such as an ASPX web shell, into a web-accessible directory. The vulnerable upload handler accepts attacker-controlled filename and destination path parameters and does not properly validate the session cookie, allowing a remote attacker with network access to create files wherever the web server process has write permission. If the file is placed under the webroot, the attacker can request it over HTTP and execute code in the context of the web server process, potentially leading to credential theft, data access, lateral movement, service disruption, and full host compromise. The supplied product metadata is inconsistent: the vulnerability description identifies Kaseya VSA RMM 9.5.4.2149, while the package metadata lists axiomatic-systems/bento4 fixed at commit dc198bee70181d671421798112b464dab15cf958; teams should validate exposure using both application inventory and endpoint behavior.

Why it matters to the business

Successful exploitation can give an unauthenticated internet-facing attacker control of a remote monitoring and management server or other affected web application host. Because RMM platforms often have privileged access to many downstream endpoints, compromise can create a high-impact operational incident involving mass software deployment abuse, credential exposure, customer or managed-device compromise, outage risk, and emergency containment work. The CVSS score is critical and exploit maturity is weaponized, with a high EPSS probability of exploitation, so exposed systems should be treated as urgent even though the provided KEV and ransomware flags are false.

How an attack unfolds

An attacker first identifies an exposed vulnerable web application and confirms that the upload endpoint is reachable. They send a crafted POST request to the upload handler with a syntactically present but unvalidated sessionId cookie, a chosen filename through the upload filename parameter, and a destination path pointing to a directory where the web server can write, commonly the application webroot. The request body contains attacker-controlled ASPX or similar server-side code. If the upload succeeds, the attacker then browses to the newly written file, causing the web server to compile or interpret the file and run the attacker's commands under the web server identity. From there, the attacker may enumerate the host, dump configuration files and credentials, stage additional tooling, create persistence, pivot to connected systems, or abuse the management platform's legitimate deployment functions.

How to fix it

Upgrade affected software to a vendor-fixed version and verify that the vulnerable upload handler is no longer exploitable. For environments where software composition data identifies axiomatic-systems/bento4, update to a build containing commit dc198bee70181d671421798112b464dab15cf958 or later. For Kaseya VSA exposure matching the described behavior, upgrade from 9.5.4.2149 to the vendor-remediated VSA release and follow all vendor hardening guidance. If immediate patching is not possible, remove public internet exposure, restrict access to trusted administrative networks or VPN, block requests to /SystemTab/uploader.aspx at the reverse proxy or WAF where operationally safe, disable or remove the vulnerable upload functionality, and ensure the web server identity cannot write to executable web directories. Also review filesystem ACLs so upload directories are non-executable, enforce strong request validation and authentication on upload paths, and rotate credentials stored on or used by the affected server after any suspected exposure.

How to confirm the fix worked

Confirm the installed application version or package commit is at or beyond the fixed release, including verification that any SCA finding for axiomatic-systems/bento4 resolves to commit dc198bee70181d671421798112b464dab15cf958 or later where applicable. From an unauthenticated test context, verify that requests to /SystemTab/uploader.aspx or equivalent upload endpoints are rejected before file write logic executes. Confirm that arbitrary PathData or filename values cannot write outside approved upload directories and that uploaded content cannot be executed as server-side code. Review webroot permissions to ensure the web server process does not have unnecessary write access to executable directories. Validate WAF or reverse-proxy rules by confirming suspicious requests containing PathData, qqfile, and .aspx filenames are blocked or alerted. Finally, perform a filesystem sweep for recently created executable files in web directories and inspect IIS or web server logs for historical upload attempts.

Typical attack path

1. Discover an exposed affected web application or RMM server reachable over HTTP or HTTPS.
2. Probe /SystemTab/uploader.aspx or the relevant upload handler to determine whether unauthenticated requests are accepted.
3. Send a crafted POST request with a numeric sessionId cookie and attacker-controlled Filename, qqfile, and PathData parameters.
4. Write an executable server-side file, commonly an .aspx web shell, into the webroot or another executable directory.
5. Request the uploaded file over HTTP or HTTPS to execute commands as the web server process.
6. Use the initial command execution to collect configuration files, database connection strings, local secrets, and service account credentials.
7. Deploy additional tooling or persistence and attempt privilege escalation on the host.
8. If the compromised application is an RMM platform, abuse trusted management functions to reach managed endpoints or distribute payloads.

How to detect it

Use IIS or web server access logs, reverse-proxy logs, WAF events, Windows Security logs, Sysmon or EDR telemetry, application logs, and filesystem change records. Look for unauthenticated or unusual POST requests to /SystemTab/uploader.aspx, especially requests containing Filename, qqfile, PathData, __RequestValidationToken, numeric sessionId cookies, encoded Windows paths, or .aspx filenames. Correlate any successful upload-like request with new or modified files under web-accessible directories, especially C:\Kaseya\WebPages\ or equivalent application webroots. Investigate ASPX files containing server-side directives, command execution classes, encoded payloads, or web-shell terms. On Windows hosts, hunt for w3wp.exe spawning shells, scripting engines, download utilities, compilers, archive tools, or network discovery commands. Check for outbound connections initiated by the web server process shortly after suspicious uploads, new scheduled tasks or services, changes to startup locations, credential dumping behavior, and unexpected RMM job or agent deployment activity. If logs are missing or rotated, use file creation timestamps, USN journal data, AmCache/ShimCache, Prefetch, PowerShell logs, and EDR process lineage to reconstruct activity.

• /SystemTab/uploader.aspx
• POST /SystemTab/uploader.aspx
• qqfile=
• PathData=
• Filename=
• __RequestValidationToken=
• Cookie: sessionId=
• C%3A%5CKaseya%5CWebPages%5C
• C:\Kaseya\WebPages\
• /SystemTab/uploader.aspx?Filename=
• /SystemTab/uploader.aspx?Filename=*.aspx
• PathData=C%3A%5CKaseya%5CWebPages%5C
• <%@ Page Language="C#"
• <script runat="server">
• System.Diagnostics
• System.Data.SqlClient
• validateRequest="false"
• w3wp.exe -> cmd.exe
• w3wp.exe -> powershell.exe
• w3wp.exe -> certutil.exe
• w3wp.exe -> bitsadmin.exe
• w3wp.exe -> mshta.exe
• w3wp.exe -> csc.exe
• w3wp.exe -> wscript.exe
• w3wp.exe -> rundll32.exe
• *.aspx created under C:\Kaseya\WebPages\

What your security team should do

• Immediately inventory internet-facing instances of the affected web application or RMM platform and prioritize any reachable systems for patching or isolation.
• Apply the vendor-fixed version; where package metadata applies, ensure axiomatic-systems/bento4 is updated to commit dc198bee70181d671421798112b464dab15cf958 or later.
• Temporarily restrict administrative and upload endpoints to trusted networks, VPN, or allowlisted management IP ranges until patch validation is complete.
• Search IIS, reverse-proxy, WAF, EDR, and file integrity logs for POST requests to /SystemTab/uploader.aspx and unexpected .aspx file creation in web directories.
• Hunt for web server child processes such as cmd.exe, powershell.exe, certutil.exe, bitsadmin.exe, mshta.exe, csc.exe, or wscript.exe spawned by w3wp.exe.
• If exploitation is suspected, preserve forensic evidence, isolate the server, collect volatile process and network data, and rotate application, database, service account, and RMM credentials.
• Review downstream device management activity for unauthorized script execution, software deployment, agent procedure runs, or mass file distribution after the first suspicious upload event.
• Implement filesystem controls preventing the web server identity from writing to executable directories and add continuous monitoring for new server-side scripts under the webroot.