CVE-2025-2777

What it actually does

SysAid On-Prem versions 23.3.40 and earlier contain an unauthenticated XML External Entity vulnerability in the lshw processing functionality. An attacker can submit crafted XML that causes the server-side XML parser to resolve attacker-controlled external entities. This can expose local files readable by the SysAid application process and, according to the vulnerability description, can be chained to take over an administrator account. Because exploitation is unauthenticated and the CVSS score is critical, internet-exposed instances are high-risk, especially given the reported weaponized exploit maturity and high EPSS probability.

Why it matters to the business

Successful exploitation can allow an outside attacker to compromise the SysAid help desk platform, read sensitive server-side files, and take over administrator access. This can lead to exposure of tickets, user information, credentials or configuration secrets, disruption of IT service management operations, and potential lateral movement into systems integrated with SysAid. Although this issue is not currently listed in CISA KEV, the high EPSS score and weaponized exploit status make rapid remediation urgent.

How an attack unfolds

An attacker identifies a reachable SysAid On-Prem instance running version 23.3.40 or earlier. They send a crafted request to functionality that processes lshw XML data, embedding a malicious XML document type declaration and external entity references. If the XML parser is configured to resolve external entities, the SysAid server attempts to load local files or contact attacker-controlled infrastructure. The attacker uses the file-read primitive to retrieve sensitive configuration data, tokens, credentials, or other application secrets, then leverages the exposed data and application behavior to gain administrator-level access to SysAid. Once administrative control is obtained, the attacker can inspect tickets and assets, modify users or settings, deploy malicious changes through trusted workflows, or use the compromised platform as a pivot point into the broader environment.

How to fix it

Upgrade SysAid On-Prem to a vendor-fixed version newer than 23.3.40 as soon as possible. If an exact fixed version is provided by SysAid for the deployed branch, upgrade to that version or later. Until upgraded, restrict network access to SysAid to trusted administrative networks or VPN, block direct internet exposure, and apply web application firewall rules to reject XML payloads containing document type declarations or external entity definitions. Disable XML external entity resolution in any custom integrations or extensions that process lshw XML data, if configurable. Rotate credentials, API keys, integration secrets, and administrative passwords that may have been readable by the SysAid application process before remediation. Review SysAid administrator accounts and remove unauthorized or unexpected users, sessions, tokens, and configuration changes.

How to confirm the fix worked

Confirm the deployed SysAid On-Prem version is later than 23.3.40 or matches the vendor-designated fixed release. Verify that the lshw XML processing path no longer resolves external entities by testing in a controlled manner with a benign external entity payload that should not result in local file disclosure or outbound network callbacks. Review perimeter exposure to ensure SysAid is not reachable from untrusted networks unless explicitly required. Validate that the XML parser configuration disables DTDs and external entity resolution. Confirm that WAF or reverse proxy controls block suspicious XML constructs such as <!DOCTYPE, <!ENTITY, SYSTEM, file://, and external callback URLs. After patching, verify that no unauthorized administrator accounts, API tokens, integrations, scheduled jobs, or configuration changes remain.

Typical attack path

1. Scan for internet-accessible SysAid On-Prem instances.
2. Determine whether the instance is running SysAid On-Prem version 23.3.40 or earlier.
3. Send a crafted unauthenticated XML payload to the lshw processing functionality.
4. Use XML external entity resolution to read local files or trigger outbound callbacks to attacker-controlled infrastructure.
5. Extract configuration files, credentials, tokens, or other sensitive data available to the SysAid application process.
6. Use the obtained data or exploit chain to take over a SysAid administrator account.
7. Use administrator access to access sensitive tickets, users, assets, integrations, or to support further compromise.

How to detect it

Investigate whether SysAid servers received suspicious unauthenticated requests containing XML document type declarations, entity definitions, or references to local files and external URLs. Review SysAid application logs, web server or reverse proxy access logs, WAF logs, EDR file-access telemetry, DNS logs, proxy logs, firewall egress logs, and network flow records. Look for requests to lshw-related processing functionality with XML payloads containing <!DOCTYPE, <!ENTITY, SYSTEM, file://, jar://, gopher://, ftp://, or attacker-controlled HTTP/HTTPS callback domains. Check for outbound connections from the SysAid server to unusual external destinations shortly after XML-processing requests, especially DNS lookups or HTTP requests that include hostnames or paths resembling data exfiltration. Review file-read attempts by the SysAid or Java/Tomcat process against sensitive paths such as operating system password files, application configuration files, keystores, credential stores, and cloud or service account metadata endpoints. Also review SysAid administrative audit logs for new administrator accounts, role changes, password resets, token creation, integration changes, unexpected ticket exports, or logins from unfamiliar IP addresses after suspicious XML activity.

• <!DOCTYPE
• <!ENTITY
• SYSTEM "file://
• SYSTEM 'file://
• file:///etc/passwd
• file:///etc/shadow
• file:///proc/self/environ
• file:///c:/windows/win.ini
• file:///C:/Windows/win.ini
• http://169.254.169.254
• https://169.254.169.254
• jar://
• gopher://
• ftp://
• lshw
• /lshw
• DOCTYPE.*ENTITY
• ENTITY.*SYSTEM
• java.net.URL.openStream
• SAXParseException
• DocumentBuilderFactory
• external entity

What your security team should do

• Treat this as a critical, actively exploitable exposure because exploitation is unauthenticated, impact includes administrator account takeover, EPSS is high, and exploit maturity is weaponized.
• Immediately inventory all SysAid On-Prem deployments and identify any instances running version 23.3.40 or earlier.
• Upgrade affected instances to a vendor-fixed release newer than 23.3.40 and prioritize internet-facing systems first.
• Temporarily restrict access to SysAid from the internet and allow only trusted source networks until the upgrade is complete.
• Search historical logs for XXE payload patterns, lshw processing requests, suspicious XML document type declarations, and outbound callbacks from the SysAid server.
• Rotate SysAid administrator credentials, integration credentials, API keys, and secrets that may be stored in files readable by the application process.
• Review SysAid users, administrator roles, sessions, API tokens, integrations, ticket activity, and configuration changes for signs of unauthorized access.
• Implement egress monitoring or restrictions so application servers cannot freely connect to arbitrary external hosts.
• If exploitation is suspected, preserve SysAid application logs, web server logs, reverse proxy logs, EDR telemetry, and network flow data before rebuilding or restoring systems.