Yes. CISA added CVE-2025-2775 to its Known Exploited Vulnerabilities catalogue on 22 July 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. SysAid On-Prem contains an improper restriction of XML external entity reference vulnerability in the Checkin processing functionality, allowing for administrator account takeover and file read primitives.
What the CISA KEV listing tells you about CVE-2025-2775
The practical answer is that this is no longer a theoretical weakness. A KEV listing means the vulnerability has enough real-world exploitation evidence to justify urgent attention, so the first task is to confirm whether any SysAid On-Prem instance exists in your environment, whether it is internet-reachable, and whether it is still within the exposure window covered by your own logging and asset inventory.
For exploitation-in-the-wild questions, the signal is the combination of active abuse and a known product footprint, not the CVE label alone. Treat the CISA KEV entry as the operational trigger, then use the vendor advisory and CISA Known Exploited Vulnerabilities Catalog for the authoritative remediation details and priority status.
That same triage logic is reflected in NHIMG’s Zero-Day and Exploited Vulnerabilities Guide, which is built around confirmed exploitation, emergency mitigation, and post-patch hunting rather than routine vulnerability scoring alone.
How to confirm exposure and decide whether this is an incident
Start with two questions: do you run SysAid On-Prem, and does your environment show any signs that the Checkin processing path was reachable during the vulnerable period? If the answer to either is unclear, assume exposure until you can prove otherwise. For web-facing administrative software, uncertainty is itself a risk condition because exploitation often leaves only partial logs or sparse indicators.
Once exposure is confirmed, look for the consequences named in the advisory context, especially administrator takeover and file-read behavior. Those are not minor side effects. They can indicate that the flaw was used as an initial access path, which means your response should include compromise assessment, not just patch validation. If you have alerting on unusual admin logins, unexpected configuration changes, or suspicious file access, review those signals before declaring the system clean.
NHIMG’s Web Application Attacks Guide is useful here because XXE sits in a broader class of input-handling weaknesses that can expose internal files, metadata, or privileged application behavior when XML parsing is not tightly constrained.
Containment, patching, and what to do if patching must wait
If you can patch immediately, do that first, then verify the fix against the vendor advisory. If you cannot patch at once, reduce exposure by removing internet access, restricting administrative reachability, and tightening any reverse proxy or WAF rules that can narrow who can reach the affected functionality. For a KEV-listed issue, compensating controls are only a temporary bridge, not a substitute for remediation.
Because the vulnerability can lead to administrator account takeover, rotate any credentials, sessions, or access paths that could have been exposed through the affected application. That includes admin accounts used for SysAid, any local service accounts tied to the platform, and downstream integrations that may trust the appliance. If you delay rotation, you are assuming the attacker did not already turn the product into a persistence point, which is a weak assumption once active exploitation is known.
When you need a model for this kind of response discipline, NHIMG’s Vulnerability Management Guide is the closest fit for prioritisation, verification, exception handling, and post-remediation confirmation.
Risk and Threat Considerations
KEV-listed XML external entity flaws are dangerous because they can convert a parsing bug into privileged data access or administrative control. In this case, the likely threat is not just disclosure, but follow-on compromise through stolen application trust, altered settings, or a foothold that survives ordinary remediation if credentials and sessions are not also addressed.
Failure mechanism: The application processes attacker-controlled XML in a way that permits external entity resolution, allowing file read primitives or privilege escalation through the application’s trusted execution context.
Impact: An attacker may read sensitive files, seize administrative access, and use the compromised system as a launch point for broader internal access, persistence, or additional data theft.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Asset Inventory | SysAid exposure requires knowing whether the asset exists and is reachable. |
| DE.CM-01 — Monitor for Unauthorized Personnel, Connections, Devices, and Software | Active exploitation calls for monitoring suspicious access and admin behavior. | |
| Recommendation — Inventory all SysAid On-Prem assets and confirm their exposure status. Monitor for unusual SysAid access and administrative activity. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The issue is a known exploited software flaw requiring prompt remediation. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Compromise assessment depends on reviewing logs for abuse indicators. | |
| IA-5 — Authenticator Management | Credential rotation is material when account takeover may have occurred. | |
| Recommendation — Apply vendor remediation quickly and verify the vulnerable component is fixed. Review audit records for signs of check-in abuse and admin takeover. Rotate exposed credentials, sessions, and related secrets after suspected compromise. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed exploitation requires prioritised vulnerability handling and verification. |
| CIS-8 — Audit Log Management | Detecting abuse depends on preserving and reviewing logs. | |
| Recommendation — Prioritise and track remediation of the exploited SysAid vulnerability. Preserve and analyse logs for signs of exploitation and persistence. | ||
Practitioner Guidance
What to verify: Confirm whether any SysAid On-Prem instance was reachable during the exploitation window, whether logs show anomalous check-in activity, and whether admin or service-account behavior changed unexpectedly. If logs are incomplete, treat the assessment as inconclusive rather than safe.
Decision rule: If the instance was internet-facing or otherwise broadly reachable, prioritise containment, patching, and credential/session review before spending time on root-cause refinement. If the system was isolated and strongly monitored, you can move faster to targeted hunting, but do not skip validation of file integrity and account state.
Practitioner takeaway: For KEV-listed flaws, the right question is not only whether exploitation is possible, but whether your environment can prove it was not used as an entry point, because active abuse changes both the urgency and the scope of response.
Related resources from NHI Mgmt Group
- Is CVE-2025-2776 (SysAid On-Prem Improper Restriction of XML External Entity Reference) being exploited in the wild?
- How do you patch or mitigate CVE-2025-2775 (SysAid On-Prem Improper Restriction of XML External Entity Reference)?
- CVE-2025-2775 (SysAid On-Prem Improper Restriction of XML External Entity Reference)
- Is CVE-2025-58360 (OSGeo GeoServer Improper Restriction of XML External Entity Reference) being exploited in the wild?