CVE-2025-2776

What it actually does

SysAid On-Prem versions 23.3.40 and earlier contain an unauthenticated XML External Entity (XXE) flaw in Server URL processing. An attacker can submit crafted XML that causes the application’s XML parser to resolve attacker-controlled external entities. Depending on runtime configuration and network access, this can expose local files, access internal resources reachable from the SysAid server, and support administrator account takeover. Because exploitation does not require authentication and the product commonly holds privileged IT service-management data and administrative workflows, successful exploitation can lead to full compromise of the SysAid application and sensitive operational data.

Why it matters to the business

Compromise of a SysAid On-Prem instance can expose helpdesk tickets, user information, IT asset data, credentials or tokens stored in workflows, and administrative functions used to manage support operations. Attackers may use the compromised system to impersonate administrators, pivot into internal infrastructure, disrupt service desk operations, or collect information useful for broader intrusion activity. This vulnerability is in CISA KEV, has high EPSS likelihood, and is reported as actively exploited in the wild, so unpatched internet-facing or broadly reachable instances should be treated as urgent remediation priorities. CISA-listed organizations were required to remediate by 2025-08-12.

How an attack unfolds

An attacker identifies a reachable SysAid On-Prem server running version 23.3.40 or earlier and targets the Server URL processing functionality. The attacker sends a crafted unauthenticated request containing XML with an external entity definition. If the vulnerable parser resolves the entity, the server may read local files or make outbound requests to attacker-controlled or internal endpoints. The attacker can use file-read results and application behavior to obtain sensitive configuration data, session material, credentials, or other secrets, then use those materials or the vulnerable workflow to take over an administrator account. After gaining administrative access, the attacker can review tickets and asset data, create or modify users, alter settings, stage persistence through application configuration, and use the SysAid server as a foothold for internal reconnaissance.

How to fix it

Upgrade SysAid On-Prem to a vendor-fixed release newer than 23.3.40 as soon as possible, following SysAid’s official advisory and upgrade documentation. If immediate upgrade is not possible, restrict access to the SysAid server to trusted administrative networks or VPN users only, block unauthenticated external access at reverse proxies and firewalls, and disable or tightly control the vulnerable Server URL processing functionality if the vendor provides a configuration-level mitigation. Ensure XML parsing is configured to disable DTDs and external entity resolution where administratively possible. Rotate credentials, API keys, service account passwords, and secrets stored on or used by the SysAid server if exploitation is suspected. Because this vulnerability enables administrator account takeover, review administrator accounts, sessions, integrations, and application configuration after patching.

How to confirm the fix worked

Confirm the installed SysAid On-Prem version is newer than 23.3.40 or matches a vendor-documented fixed build. Verify the patch level from the SysAid administrative interface, installation files, package inventory, or vendor-supported version command if available. Test externally and internally that the SysAid service is not exposed to untrusted networks unless required and protected. Validate that XML external entity resolution is disabled by sending a benign, controlled XXE test payload in an authorized test environment and confirming that no local file content is returned and no out-of-band DNS or HTTP callback occurs. Review access controls to ensure only trusted users and networks can reach administrative and Server URL processing functionality. After remediation, confirm that administrator accounts, integrations, and stored credentials have been reviewed or rotated where warranted.

Typical attack path

1. Scan for internet-facing or internally reachable SysAid On-Prem instances.
2. Fingerprint the instance or infer that it is running SysAid On-Prem version 23.3.40 or earlier.
3. Send a crafted unauthenticated XML payload to the Server URL processing endpoint that defines an external entity.
4. Confirm XXE behavior through out-of-band callbacks, error messages, or retrieved file contents.
5. Use file-read primitives to access sensitive local files, configuration files, credentials, tokens, or application secrets.
6. Leverage obtained secrets or application behavior to take over an administrator account.
7. Use administrator access to collect service desk data, modify application settings, create persistence, or pivot further into the network.

How to detect it

Review SysAid application logs, web server or reverse proxy access logs, endpoint telemetry, DNS logs, proxy logs, and firewall logs for signs of unauthenticated XML payloads and unexpected outbound connections from the SysAid server. Look for requests containing XML document type declarations, external entity definitions, or references to local files and internal metadata services. Investigate any outbound HTTP, HTTPS, LDAP, SMB, or DNS traffic from the SysAid server to unfamiliar external hosts around the time of suspicious inbound requests, especially if the destination is not part of normal integrations. Examine SysAid audit logs for administrator account takeover indicators, including unexpected password resets, new administrator users, privilege changes, session creation from unusual IP addresses, configuration changes, or integration changes. On the host, inspect for suspicious file access patterns, new or modified web application files, unexpected scheduled tasks or services, and anomalous child processes spawned by the SysAid application or Java process. Because public reporting identifies active exploitation, treat any vulnerable exposed instance as potentially compromised until logs and credentials are reviewed.

• <!DOCTYPE
• <!ENTITY
• SYSTEM "file://
• SYSTEM 'file://
• file:///etc/passwd
• file:///c:/windows/win.ini
• file:///C:/Windows/win.ini
• /etc/passwd
• C:\\Windows\\win.ini
• 169.254.169.254
• http://169.254.169.254
• https://169.254.169.254
• metadata.google.internal
• latest/meta-data
• oob
• xxe
• %xxe;
• %file;
• %dtd;
• java.net.URL
• SAXParseException
• DOCTYPE is disallowed
• External Entity
• external entity
• DisallowDoctypeDecl
• resolveEntity

What your security team should do

• Immediately inventory all SysAid On-Prem deployments and identify any instances running version 23.3.40 or earlier.
• Prioritize emergency patching of internet-facing or third-party-accessible SysAid On-Prem servers because the vulnerability is in CISA KEV and actively exploited in the wild.
• If patching cannot be completed immediately, isolate SysAid behind VPN or trusted network controls and block untrusted access to vulnerable functionality.
• Hunt for evidence of XXE exploitation, including suspicious XML payloads, external entity declarations, unexpected outbound HTTP/DNS traffic from the SysAid server, and anomalous administrator activity.
• Review SysAid administrator accounts, newly created users, authentication logs, integration settings, and configuration changes for unauthorized modifications.
• Rotate SysAid-related secrets, service account credentials, API tokens, and integration credentials if exploitation is possible or confirmed.
• Monitor vendor advisories and CISA KEV updates for additional indicators, fixed version details, and post-exploitation guidance.