LoLLMs CVE-2026-10595: unauthenticated file read through the SPA route

CVE-2026-10595 was published on 9 August 2026 in LoLLMs, a platform for working with local and remote language models. An unauthenticated user could exploit the SPA catch-all route to read any file accessible to the server process. The flaw affects version 2.1.0 and—under the CNA range—releases earlier than version 3. Its CVSS 3.0 score is 7.5: exploitation is network-based, low-complexity and requires neither authentication nor user interaction, with high direct impact on confidentiality.

This is a useful example of a flaw outside the model, prompts and RAG mechanism. It existed in an ordinary function that delivered static web-interface files. An AI system inherits the entire application surface: HTTP routing, URL parsing, the filesystem, process privileges and the secrets required to connect models.

Where the flaw originated

The CVE-2026-10595 record identifies backend/routers/ui.py and the route handling single-page-application paths. The vulnerable implementation joined a user-controlled path to the static-file directory. URL-encoded parent-directory sequences could bypass earlier path normalisation by Starlette and then be interpreted by Python’s pathlib.

Two components consequently interpreted the same input at different stages:

1. the routing layer accepted the path as a value for the catch-all parameter;
2. the filesystem operation resolved it to a real location outside the frontend directory;
3. the code checked whether the file existed but not whether its resolved path remained inside the permitted directory.

This is a canonicalisation error. Filtering a string before complete decoding cannot guarantee that a later layer sees the same string. A security control needs to operate on the canonical resolved path and verify its relationship to a canonical base directory.

How the fix works

The LoLLMs fixing commit makes a small but significant change. It first resolves STATIC_DIR to its canonical path, then resolves the candidate, and finally calls is_relative_to(). A candidate outside the static directory receives a 404 response.

That order matters. Comparing raw text prefixes is error-prone: /app/static-old begins with a string resembling /app/static, while symbolic links can change the real location. resolve() followed by a relationship check validates the object the filesystem will actually access.

The change entered the repository on 1 June, while the public CVE record appeared today. The CNA identifies version 3 as the fixed boundary. An organisation should base its decision on the installed release, not only the date of a commit on the main branch.

What an attacker could read

The CVE confirms arbitrary file read within the LoLLMs process permissions. Exact content depends on the installation. Potentially material files include configuration, environment values stored in files, model-provider tokens, connection data, application history, service keys and system information.

Not every file exists in every deployment, and the public sources do not confirm theft of specific secrets. This is an impact-review list, not an incident claim. A container with broad mounts or a service account that can read user directories substantially amplifies one HTTP-routing defect.

In an AI application, a secret may cross another boundary: a paid model API, object storage for documents, a vector database or an agent tool. Response therefore cannot stop at “the attacker could only read files.” The team must establish what authority the readable data carried.

Who should respond

LoLLMs instances earlier than version 3 have the highest priority when they listen beyond localhost, sit behind a reverse proxy or are reachable from an untrusted network. An internal-only instance may still be targeted by an insider, compromised host or request generated through another application.

Review laboratory copies and developer workstations too. AI tools often begin as local experiments and later gain a tunnel, firewall rule or forwarded container port. The formal service owner may not know that a test instance is network-accessible.

Remediation and investigation plan

1. Update LoLLMs to version 3 or later and verify that the running process uses the new image or environment.
2. Until updating, restrict firewall and reverse-proxy access to trusted addresses; treat this as mitigation, not a fix.
3. Identify every file, directory and secret readable by the process account, including container mounts.
4. Preserve raw HTTP logs containing the original request target. A proxy may normalise the path before the application logs it.
5. Search for unusual URL encoding, repeated file-like responses and SPA-route requests that do not correspond to frontend assets.
6. If a vulnerable instance was reachable, rotate readable tokens and passwords and review their use at downstream services.
7. Run the service under a dedicated account, with minimal read-only mounts and no access to an administrator’s home directory.

Measuring the real impact on secrets

Begin with process identity instead of guessing filenames. Establish its UID or system account, working directory, home directory, environment, container mounts and volumes shared with other services. Then inventory files that the account can read, but do not copy their contents into an ordinary ticket. A report should classify secret type, owner, permission scope and last rotation date.

Ask four questions for each secret: was it present during exposure, could the process read it, do downstream service logs show unusual use, and can it be revoked safely? A model API token may represent cost and access to project history; vector-database credentials may open RAG documents; an object-storage key may cover much more than one application. Impact depends on policy at the destination, not the filename alone.

Rotate in an order that limits downtime: create a new secret, grant minimum scope, deploy it to the fixed instance, confirm operation and only then revoke the old value. If an attacker may have changed the secret source, replacing the value is insufficient—review startup mechanisms, images, service files and scheduled tasks too.

Protective layers beyond the application fix

A reverse proxy can require authentication before LoLLMs, limit request size and rate, and preserve the original target in a protected log. A firewall should restrict source networks, while the host or container should not see a management network without need. None of these controls replaces version 3, but they reduce the probability and effect of another web-layer defect.

The filesystem provides equally important mechanisms. The application image can be read-only, its working directory a separate volume, and secrets delivered by a mechanism that does not store them beside code. AppArmor, SELinux or a container policy can confine reads to defined directories. Test the control under the actual process identity: a declaration in deployment configuration does not prove enforcement on the running host.

Finally, add exposure testing to the infrastructure pipeline. After every image, proxy or routing change, an automated check should confirm that the service has not become public and the process has not received a new broad mount. Many incidents begin with a “temporary” port published for a demonstration rather than an application-code change.

A regression test for developers

Testing should cover ordinary SPA assets, normalised paths, repeated encoding, platform-specific separators, absolute paths and symbolic links. Every value escaping the base directory should produce the same safe error without revealing whether a file exists.

Place the control in one safe-path-join function rather than duplicating it across endpoints. Add an integration test covering the proxy and framework because a unit test of the helper alone will not reveal differences in how many times a URL is decoded.

Facts versus Breachroad conclusions

The confirmed facts are unauthenticated file read through encoded traversal, an affected range before version 3, CVSS 7.5 and a fix based on path resolution and containment. Public sources do not confirm campaign exploitation or access to particular data.

Breachroad’s conclusion is that AI security includes every conventional application boundary, while broad process authority magnifies a small web defect. Secure AI deployment training should connect models with AppSec and operations, while an AI security assessment can examine exposure, secrets, mounts and process privileges across the stack.