CVE-2024-57968

What it actually does

Advantive VeraCore versions before 2024.4.2.1 allow a remote authenticated user to use upload.aspx to place uploaded files outside the intended upload location. Technically, this is an authenticated arbitrary or unintended file upload/path traversal weakness: if an attacker can control the destination path or folder, they may be able to write content into web-accessible directories. Impact depends on server configuration and file handling controls. In the highest-impact scenario, an attacker uploads an executable server-side file such as an ASPX web shell and then requests it through the web server, resulting in code execution in the context of the VeraCore/IIS application pool. Even where execution is blocked, the flaw can still enable malicious file hosting, phishing content, tampering with application-accessible files, or exposure of files to other users.

Why it matters to the business

Successful exploitation can let an attacker with VeraCore access turn the application into a staging point for malware, unauthorized content, or potentially a foothold on the application server. Because this vulnerability is listed in CISA KEV, has active in-the-wild exploitation, and had a CISA remediation deadline of 2025-03-31, exposed vulnerable deployments should be treated as urgent legacy risk. Operational consequences may include compromise of order, warehouse, fulfillment, or business workflow data handled by VeraCore, disruption of the application, incident response costs, regulatory notification analysis, and loss of trust if the platform is used to host malicious files or access sensitive records.

How an attack unfolds

An attacker first obtains a valid VeraCore account or session through credential theft, password reuse, phishing, abuse of an exposed account, or another vulnerability. The attacker then sends a crafted authenticated request to upload.aspx with a file and a destination that causes the application to write the file into an unintended folder, such as a directory reachable by the web server. If the application or IIS permits the uploaded file type to execute, the attacker uploads a server-side script such as an ASPX web shell and browses directly to the uploaded file to issue commands. From there, the attacker may enumerate the application server, read configuration files, access application data available to the service account, dump credentials, pivot to adjacent systems, or deploy additional tooling. If execution is not possible, the attacker may still use the issue to host malicious files, tamper with web-accessible content, or place files where other users may retrieve them.

How to fix it

Upgrade Advantive VeraCore to version 2024.4.2.1 or later. Treat any version before 2024.4.2.1 as vulnerable. After upgrading, review and harden upload handling: enforce server-side allowlists for file extensions and MIME types, generate server-controlled filenames, prevent user-controlled directory selection, canonicalize paths before writing files, reject traversal sequences, store uploads outside executable web roots, disable script execution in upload directories, and restrict upload permissions to the minimum required roles. If immediate upgrade is not possible, restrict access to VeraCore and upload.aspx to trusted networks or VPN, reduce the number of accounts with upload privileges, monitor all upload activity, and use web server controls to block execution of uploaded dynamic content such as ASPX files.

How to confirm the fix worked

Confirm the installed VeraCore version is 2024.4.2.1 or later using vendor-supported version checks, application release information, or administrative UI/package metadata. Verify upload directories are not executable by testing that uploaded dynamic files cannot run as server-side code. Review IIS/application configuration to ensure web-accessible upload locations do not allow script execution. Attempt a controlled, authorized upload test with traversal-like path input and confirm the application rejects it or writes only to the intended server-controlled directory. Search web roots and upload locations for unexpected recently created files, especially ASPX, ASHX, ASA, CONFIG, ZIP, EXE, DLL, PS1, or script-like content. Validate that upload.aspx is not reachable anonymously and is only accessible to intended authenticated roles.

Typical attack path

1. Acquire valid VeraCore credentials or hijack an authenticated VeraCore session.
2. Identify that the target is running a VeraCore version earlier than 2024.4.2.1.
3. Send an authenticated upload request to upload.aspx with a crafted destination path or folder value.
4. Write the uploaded file into an unintended or web-accessible directory.
5. Request the uploaded file through the web server to confirm it is reachable.
6. If server-side execution is allowed, use the uploaded script as a web shell to execute commands under the web application context.
7. Enumerate files, configuration, credentials, connected services, and application data accessible to the compromised process.
8. Maintain access, stage additional payloads, exfiltrate data, or use the server as a pivot point.

How to detect it

To determine whether this was already exploited, review IIS access logs, VeraCore application logs, authentication logs, EDR telemetry, and file system audit data. Focus on authenticated POST requests to upload.aspx, especially requests containing traversal patterns, encoded dot-dot-slash sequences, unusual destination paths, or uploads of executable file types. Correlate upload requests with subsequent GET requests to newly created files in web-accessible locations. Examine VeraCore web roots and upload directories for recently created or modified files that do not match normal application content, particularly ASPX/ASHX/ASA files or files with double extensions. Review process telemetry for IIS worker processes spawning command shells, PowerShell, scripting engines, archive utilities, credential tools, network discovery commands, or outbound connections shortly after upload activity. Investigate anomalous logins preceding suspicious uploads, including impossible travel, new source IPs, rare user agents, and activity from accounts that do not normally upload files. Because this is KEV-listed and exploitation is active in the wild, absence of obvious web shell filenames should not be treated as proof of no compromise; combine log review, file integrity review, and endpoint telemetry.

• POST /upload.aspx
• upload.aspx
• ../
• ..\\
• %2e%2e%2f
• %2e%2e%5c
• %252e%252e%252f
• %252e%252e%255c
• .aspx
• aspx.aspx
• .ashx
• .asa
• cmd.exe /c
• powershell.exe -enc
• powershell.exe -EncodedCommand
• w3wp.exe -> cmd.exe
• w3wp.exe -> powershell.exe
• w3wp.exe -> cscript.exe
• w3wp.exe -> wscript.exe
• w3wp.exe -> rundll32.exe

What your security team should do

• Immediately identify all VeraCore deployments and confirm whether any are running versions before 2024.4.2.1.
• Prioritize patching or vendor upgrade to VeraCore 2024.4.2.1 or later because the vulnerability is in CISA KEV and has active exploitation reported in the wild.
• If patching cannot be completed immediately, restrict network access to VeraCore and specifically monitor or limit access to upload.aspx.
• Review recent authenticated upload activity, especially from unusual users, IP addresses, geographies, user agents, or outside normal business hours.
• Hunt for newly created or modified executable web files in VeraCore web roots and upload-accessible directories.
• Inspect IIS logs for POST requests to upload.aspx followed by GET requests to newly uploaded files.
• Investigate any IIS worker process spawning operating system shells or scripting interpreters such as cmd.exe, powershell.exe, wscript.exe, cscript.exe, or rundll32.exe.
• Rotate credentials and invalidate sessions for accounts that performed suspicious upload activity.
• Preserve web logs, application logs, uploaded files, and file system timestamps before remediation if compromise is suspected.
• Add detection rules for traversal patterns and executable upload attempts targeting upload.aspx.