Your application code passes every security review. Your internal XML parsing follows OWASP ASVS v4.0.3 guidance. But when Apache Tika 2.9.2 shipped with CVE-2025-66516—a CVSS 10.0 Critical XXE vulnerability—your document processing pipeline became an attack vector you never wrote.
This isn't theoretical. SysAid's XXE vulnerabilities landed in CISA's Known Exploited Vulnerabilities catalog because attackers found them first.
What Happened
Apache Tika, a content extraction library used across enterprise document processing systems, shipped with an XML External Entity (XXE) vulnerability that allowed attackers to:
- Read arbitrary files from the server filesystem
- Execute server-side request forgery (SSRF) attacks
- Trigger denial-of-service conditions
- Exfiltrate sensitive data through out-of-band channels
The vulnerability existed in Tika's XML parsing configuration, which processed external entities by default. Any application using the affected version to parse user-supplied documents—such as PDF metadata extraction or Office file conversion—was vulnerable.
SysAid's separate XXE issues followed a similar pattern: the vulnerability lived in how the application's dependencies handled XML, not in custom code that would surface during standard code review.
Timeline
Discovery Phase: Security researchers identified that Tika's XML parser configuration allowed external entity resolution without explicit opt-in from the application developer.
Severity Assessment: Apache assigned CVSS 10.0 Critical based on network attack vector, no privileges required, and complete confidentiality/integrity/availability impact.
Exploitation Window: The gap between public disclosure and patch deployment created the window attackers needed. For SysAid, this window closed only after CISA catalog inclusion forced emergency patching.
Remediation: Apache released patched versions with external entity processing disabled by default. Organizations had to identify every service using Tika, test the update against their document processing workflows, and deploy.
Which Controls Failed or Were Missing
Dependency Security Posture: Most organizations lack continuous monitoring of third-party library configurations. Your SBOM (Software Bill of Materials) might list "Apache Tika 2.9.2" but won't flag that its XML parser allows external entities.
Defense in Depth: Applications treated Tika as a trusted component and didn't implement additional input validation or sandboxing around document processing operations.
Automated Vulnerability Detection: Static analysis tools scanning your codebase wouldn't catch this—the vulnerable configuration lives in a JAR file you imported, not code you wrote.
Patch Management Cadence: Organizations running quarterly dependency updates faced months of exposure between CVE publication and remediation.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that security vulnerabilities are identified using industry-recognized sources and new vulnerabilities are assigned a risk ranking. A CVSS 10.0 in a document processing library used in cardholder data environments demands immediate action.
OWASP ASVS v4.0.3 Section 5.5.2 specifically addresses XML parsers: "Verify that XML parsers are configured securely to prevent XML External Entity (XXE) attacks." But this requirement assumes you control the parser configuration—third-party libraries often make that decision for you.
NIST 800-53 Rev 5 Control SI-2 (Flaw Remediation) requires organizations to install security-relevant software updates within the time period directed by the organization. For Critical vulnerabilities in internet-facing services, that period should be measured in days, not weeks.
ISO 27001 Annex A.8.8 (Management of Technical Vulnerabilities) requires timely information about technical vulnerabilities, evaluation of exposure, and appropriate measures. When the vulnerability lives in your dependency tree, "evaluation of exposure" means knowing everywhere that library runs.
Lessons and Action Items for Your Team
Build a Dependency Inventory That Includes Configuration State
Your SBOM tools track package names and versions. Extend them to flag security-relevant configurations. For XML parsing libraries, you need to know:
- Is external entity processing enabled?
- Which SAX/DOM parser implementation is active?
- Are DOCTYPE declarations allowed?
Tools like OWASP Dependency-Check can identify known CVEs, but you need custom policies to catch insecure-by-default configurations before they ship.
Implement Parser Hardening at the Application Layer
Don't trust library defaults. When you initialize any XML parser—whether in your code or via a dependency—explicitly disable:
- External general entities
- External parameter entities
- DOCTYPE declarations
- XInclude processing
For Java applications using libraries that wrap XML parsers, set these properties in your bootstrap code:
XMLInputFactory factory = XMLInputFactory.newInstance();
factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false);
factory.setProperty(XMLInputFactory.SUPPORT_DTD, false);
This creates a security baseline even if your dependencies ship with permissive defaults.
Establish Risk-Based Patching SLAs
CVSS 10.0 Critical vulnerabilities in internet-facing components need a 72-hour remediation window, not a quarterly update cycle. Build your patch management process around:
- Automated CVE monitoring with severity filtering
- Pre-approved emergency change procedures for Critical patches
- Staging environments that mirror production for rapid testing
Deploy Runtime Application Self-Protection (RASP) for Document Processing
If you process user-supplied documents, RASP tools can detect XXE exploitation attempts in real-time by monitoring:
- File access patterns (reads of /etc/passwd, cloud metadata endpoints)
- Outbound network connections from parser processes
- Excessive memory consumption during parsing
This won't prevent the vulnerability, but it limits blast radius when zero-days surface.
Segment Document Processing Services
Run document parsing in isolated containers with:
- No network egress except to specific internal services
- Read-only filesystem access except to designated temp directories
- Resource limits to contain denial-of-service attempts
An XXE vulnerability in a properly sandboxed service becomes a contained incident instead of a data breach.
The Apache Tika and SysAid incidents prove that your security posture extends beyond the code you write. When a third-party library makes a CVSS 10.0 mistake, your incident response time depends on how well you've mapped your dependency tree and how quickly you can test and deploy updates. Start building that capability before the next Critical CVE drops.
