CVE-2023-47246

What it actually does

SysAid On-Premise versions before 23.3.36 contain an unauthenticated path traversal flaw that allows a remote attacker to write files outside the intended upload location. By traversing into the Apache Tomcat webroot and placing a server-side file such as a JSP web shell, the attacker can cause Tomcat to execute attacker-controlled code. Successful exploitation provides remote code execution in the context of the SysAid/Tomcat service account, enabling command execution, credential access, data theft, persistence, and lateral movement.

Why it matters to the business

This is a critical, internet-exploitable flaw with a very high exploitation likelihood, known in-the-wild exploitation, inclusion in the CISA Known Exploited Vulnerabilities catalog, and reported ransomware use. Compromise of a SysAid server can disrupt IT service management operations, expose help desk data, user information, attachments, and credentials, and provide attackers with a foothold into the broader enterprise network. Organizations running affected on-premise SysAid instances should treat exposure as an urgent incident-response priority, especially because the CISA remediation deadline was 2023-12-04 and exploitation has been public for a long period.

How an attack unfolds

An attacker identifies an exposed SysAid On-Premise server and sends a crafted request that abuses path traversal in the vulnerable file handling logic. Instead of writing a file only to the intended directory, the request causes the application to place attacker-controlled content into the Tomcat webroot. The attacker then requests that uploaded file over HTTP, causing Tomcat to execute it as server-side code. From the web shell or uploaded payload, the attacker runs operating system commands under the SysAid/Tomcat service context, commonly followed by reconnaissance, credential harvesting, payload staging, data collection, and movement to other systems. Because this vulnerability has been exploited in the wild and is associated with ransomware activity, post-exploitation activity should be assumed possible where vulnerable systems were internet-accessible.

How to fix it

Upgrade SysAid On-Premise to version 23.3.36 or later immediately. If an upgrade cannot be completed at once, remove internet exposure, restrict access to trusted management networks or VPNs, block unauthenticated access at the edge, and consider taking the server offline until it can be patched and inspected. After patching, assume vulnerable internet-facing systems may have been compromised: rotate credentials and secrets accessible to the SysAid server, remove unauthorized files from Tomcat webroots, review local and domain accounts for abuse, and rebuild from known-good media if web shells or attacker execution are found. Ensure Tomcat, Java, the operating system, and endpoint protection are also current, and enforce least privilege for the SysAid/Tomcat service account.

How to confirm the fix worked

Confirm the deployed SysAid On-Premise version is 23.3.36 or later using the product UI, package inventory, or vendor-supported version checks. Verify the server is not reachable from untrusted networks unless explicitly required and protected by strong access controls. Inspect Tomcat webroot and SysAid upload directories for unexpected JSP, WAR, class, executable, script, or archive files with timestamps after the likely exposure window. Review web access logs to confirm traversal attempts are no longer successful and that unauthenticated requests cannot write files. Where possible, perform a safe authenticated configuration review or vendor-approved vulnerability scan rather than attempting exploit validation in production.

Typical attack path

1. Scan for internet-accessible SysAid On-Premise servers.
2. Fingerprint the SysAid version or test for vulnerable file upload/path traversal behavior.
3. Send a crafted request containing traversal sequences to write a malicious file into the Tomcat webroot.
4. Access the newly written web-accessible file, such as a JSP web shell, to trigger code execution.
5. Run commands through the SysAid/Tomcat service account and establish persistence or additional tooling.
6. Collect credentials, configuration data, help desk attachments, and internal network information.
7. Move laterally, stage data for exfiltration, or deploy ransomware payloads.

How to detect it

Look for evidence that an attacker wrote files into the Tomcat webroot or executed commands through the SysAid/Tomcat process. Primary log sources include Tomcat access logs such as localhost_access_log files, catalina logs, SysAid application logs, Windows Security event logs, PowerShell logs, Sysmon or EDR process telemetry, webroot file system metadata, proxy logs, firewall logs, and DNS/HTTP egress records. Search historical logs for HTTP requests containing traversal sequences, encoded traversal, suspicious multipart uploads, and requests to newly created JSP/WAR files. On Windows, correlate Tomcat or Java processes spawning command interpreters or administrative tools. Investigate unexpected files under SysAidServer and Tomcat webapps directories, especially JSP files, WAR files, class files, executables, archives, or scripts not present in a known-good installation. Because exploitation has been observed in ransomware activity, also hunt for credential dumping, unusual archive creation, bulk file access, lateral movement tooling, remote service creation, scheduled tasks, and abnormal outbound connections from the SysAid server.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e%5c
• ..%2f
• ..%5c
• /WEB-INF/
• /webapps/
• /tomcat/webapps/
• SysAidServer/tomcat/webapps
• SysAidServer\\tomcat\\webapps
• .jsp
• cmd.exe /c
• powershell.exe
• powershell -enc
• powershell -EncodedCommand
• java.exe spawned cmd.exe
• java.exe spawned powershell.exe
• tomcat spawned cmd.exe
• tomcat spawned powershell.exe
• catalina.out
• localhost_access_log
• C:\\Program Files\\SysAidServer\\tomcat\\webapps
• C:\\Program Files\\SysAidServer\\root
• C:\\Program Files\\SysAidServer\\tomcat\\logs
• C:\\Program Files\\SysAidServer\\tomcat\\webapps\\ROOT

What your security team should do

• Immediately identify all SysAid On-Premise instances and prioritize any internet-facing systems.
• Upgrade all affected deployments to SysAid On-Premise 23.3.36 or later.
• Treat unpatched or previously internet-exposed instances as potentially compromised because exploitation is active in the wild and associated with ransomware campaigns.
• Hunt for unexpected JSP/WAR files, web shell activity, and SysAid/Tomcat child processes such as cmd.exe, powershell.exe, wscript.exe, cscript.exe, rundll32.exe, or certutil.exe.
• Review Tomcat access logs, SysAid application logs, Windows event logs, EDR telemetry, and network egress for evidence of file upload, command execution, staging, or exfiltration.
• Rotate credentials, API keys, database passwords, service account secrets, and any other sensitive material accessible from the SysAid server.
• If compromise is confirmed, isolate the host, preserve forensic evidence, rebuild from known-good media, and conduct lateral movement and ransomware readiness investigations.
• Add detections for path traversal attempts against SysAid endpoints and for server-side script execution from Tomcat webroot locations.