CVE-2024-6985: LoLLMs path traversal

CISO Take

If your team runs LoLLMs (a local LLM WebUI) version 9.5.1 or earlier, a privileged local user can bypass path sanitization to read any directory on the host via the personality API. Exploitation requires High privileges and local access, limiting real-world blast radius — but in shared or multi-user deployments, this becomes a meaningful lateral movement primitive. Patch to a version beyond 9.5.1 or restrict API access to trusted users only.

What is the risk?

CVSS 4.4 Medium, but context matters. The Local attack vector (AV:L) and High privileges requirement (PR:H) significantly constrain exploitability — this is not remotely exploitable without prior access. EPSS of 0.00053 confirms near-zero current exploitation activity. However, the Confidentiality impact is HIGH, meaning a successful exploit gives full read access to any directory on the host. In shared environments or developer workstations where LoLLMs is exposed over a local network, the effective risk escalates. Not in CISA KEV.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LoLLMs	pip	<= 9.5.1	No patch
81 Pushed 8d ago 33% patched ~1d to patch Full package profile →

Do you use LoLLMs? You're affected.

How severe is it?

CVSS 3.1

4.4 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 27% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Local

AC Low

PR High

UI None

S Unchanged

C High

I None

A None

What should I do?

6 steps

Patch immediately

Update lollms to any version beyond 9.5.1. The fix is committed at github.com/parisneo/lollms/commit/28ee567.
Verify patch status

Run pip show lollms and confirm version > 9.5.1.
Restrict API access

If running LoLLMs as a service, bind it to localhost only (127.0.0.1) rather than 0.0.0.0. Use firewall rules or reverse proxy ACLs to block unauthenticated access to the API.
Audit exposure

Check if LoLLMs is exposed on any network-accessible interface in your environment.
Detection

Monitor for API requests to /api/open_personality_folder containing ../ or URL-encoded traversal sequences (%2e%2e, %2f) in logs.
Workaround (if patching is delayed): Restrict the LoLLMs process user account permissions to the minimum required directories using OS-level controls (chroot, AppArmor, systemd sandboxing).

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Extraction Auth Bypass Framework Agent AML.T0007 - Discover AI Artifacts AML.T0025 - Exfiltration via Cyber Means AML.T0037 - Data from Local System AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.10.3 - Security of AI system

NIST AI RMF

MANAGE 2.4 - Residual risks are managed

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2024-6985?

If your team runs LoLLMs (a local LLM WebUI) version 9.5.1 or earlier, a privileged local user can bypass path sanitization to read any directory on the host via the personality API. Exploitation requires High privileges and local access, limiting real-world blast radius — but in shared or multi-user deployments, this becomes a meaningful lateral movement primitive. Patch to a version beyond 9.5.1 or restrict API access to trusted users only.

Is CVE-2024-6985 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2024-6985, increasing the risk of exploitation.

How to fix CVE-2024-6985?

1. **Patch immediately**: Update lollms to any version beyond 9.5.1. The fix is committed at github.com/parisneo/lollms/commit/28ee567. 2. **Verify patch status**: Run `pip show lollms` and confirm version > 9.5.1. 3. **Restrict API access**: If running LoLLMs as a service, bind it to localhost only (127.0.0.1) rather than 0.0.0.0. Use firewall rules or reverse proxy ACLs to block unauthenticated access to the API. 4. **Audit exposure**: Check if LoLLMs is exposed on any network-accessible interface in your environment. 5. **Detection**: Monitor for API requests to `/api/open_personality_folder` containing `../` or URL-encoded traversal sequences (`%2e%2e`, `%2f`) in logs. 6. **Workaround** (if patching is delayed): Restrict the LoLLMs process user account permissions to the minimum required directories using OS-level controls (chroot, AppArmor, systemd sandboxing).

What systems are affected by CVE-2024-6985?

This vulnerability affects the following AI/ML architecture patterns: local LLM deployments, agent frameworks, model serving.

What is the CVSS score for CVE-2024-6985?

CVE-2024-6985 has a CVSS v3.1 base score of 4.4 (MEDIUM). The EPSS exploitation probability is 0.35%.

What is the AI security impact?

Affected AI Architectures

local LLM deploymentsagent frameworksmodel serving

MITRE ATLAS Techniques

AML.T0007 Discover AI Artifacts

AML.T0025 Exfiltration via Cyber Means

AML.T0037 Data from Local System

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.10.3

NIST AI RMF: MANAGE 2.4

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

A path traversal vulnerability exists in the api open_personality_folder endpoint of parisneo/lollms. This vulnerability allows an attacker to read any folder in the personality_folder on the victim's computer, even though sanitize_path is set. The issue arises due to improper sanitization of the personality_folder parameter, which can be exploited to traverse directories and access arbitrary files.

Exploitation Scenario

An adversary with privileged access to a shared development server running LoLLMs (common in ML teams with shared GPU workstations) sends a crafted GET request to the personality API endpoint with a traversal payload in the `personality_folder` parameter — e.g., `../../../../home/mldev/.ssh/`. Despite the `sanitize_path` call, the incomplete sanitization allows the traversal to succeed, returning a directory listing. The attacker iterates through known paths to harvest model API keys stored in config files, extract training data metadata, or pivot to SSH credentials for lateral movement. Because LoLLMs is often run with developer-level privileges for GPU access, the exposed paths can include sensitive model IP and infrastructure credentials.

Weaknesses (CWE)

CWE-23 Relative Path Traversal Primary

CWE-23 — Relative Path Traversal: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes: realpath() in C getCanonicalPath() in Java GetFullPath() in ASP.NET realpath() or abs_path() in Perl realpath() in PHP

Source: MITRE CWE corpus.