CVE-2026-1114: LoLLMs weak JWT secret

Q: Is CVE-2026-1114 actively exploited?

No confirmed active exploitation of CVE-2026-1114 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-1114?

Upgrade to lollms 2.2.0 immediately, which fixes the JWT signing issue. If upgrading isn't immediately possible, rotate/replace the JWT secret with a long, cryptographically random value and restart the service so all existing tokens are invalidated; do not expose the lollms admin interface directly to the internet — place it behind a VPN, reverse-proxy auth, or IP allowlist. Detection guidance: monitor for JWT tokens with unexpected admin claims, unusual admin-panel activity from unfamiliar sessions/IPs, and repeated authentication failures that could indicate offline brute-forcing attempts against captured tokens. Review commit https://github.com/parisneo/lollms/commit/a3b2b82b84d537a9da63e63a370a6a8ad55fed34 to confirm the fix scope for custom deployments.

Q: What systems are affected by CVE-2026-1114?

This vulnerability affects the following AI/ML architecture patterns: model serving, AI chat interfaces, agent frameworks.

Q: What is the CVSS score for CVE-2026-1114?

CVE-2026-1114 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.54%.

CISO Take

lollms, a self-hosted LLM web UI, signs its JWT session tokens with a weak, guessable secret key, letting an attacker crack it offline and forge a token claiming administrator privileges. This is a full authentication bypass on a public-facing AI interface — CVSS 9.8 with complete confidentiality, integrity, and availability impact, since admin access typically exposes model configuration, user management, and plugin/persona installation. There's no public exploit or Nuclei template yet and EPSS sits low (0.0054, though ranked in the top 59% of scored CVEs by percentile), and it isn't in CISA KEV, so this reads as a real but not-yet-weaponized risk rather than an active-exploitation emergency. It also isn't the package's first security issue — 9 other CVEs exist in lollms, and its OpenSSF Scorecard/package risk score (36/100) reflects that track record. Patch immediately to lollms 2.2.0, and if you can't patch today, rotate any JWT signing secrets, restrict network exposure of the admin interface, and audit logs for unexpected admin-scope token usage.

Sources: NVD GitHub Advisory EPSS ATLAS

What is the risk?

Severity is critical (CVSS 9.8, full C/I/A impact) but current exploitation pressure is low: EPSS is 0.0054, there is no CISA KEV listing, no public exploit code, and no Nuclei template. Exploitation requires an offline brute-force step against the JWT secret, which raises the bar above a trivial unauthenticated bypass but is still well within reach of a motivated attacker with basic tooling, especially if the default/weak secret is predictable. Zero tracked downstream dependents limits blast radius from a supply-chain perspective, but any organization running lollms directly (self-hosted deployments are the entire threat surface here, since it's an end-user application, not a library) is fully exposed. The package's history of 9 other CVEs and a package risk score of 36/100 suggest recurring security hygiene issues worth factoring into any risk acceptance decision.

How does the attack unfold?

Initial Access

Attacker reaches the lollms instance and obtains a JWT, either through a low-privilege account or by intercepting an existing session token.

AML.T0049

Offline Credential Cracking

The attacker brute-forces the weak JWT signing secret offline using standard cracking tools.

Token Forgery / Privilege Escalation

With the recovered secret, the attacker modifies the JWT payload to claim administrator role and re-signs it as a valid token.

AML.T0091.000

Impact

The forged admin token grants full access to restricted endpoints, enabling data exfiltration, configuration tampering, or further compromise of the deployment.

AML.T0012

Initial Access

Attacker reaches the lollms instance and obtains a JWT, either through a low-privilege account or by intercepting an existing session token.

AML.T0049

Offline Credential Cracking

The attacker brute-forces the weak JWT signing secret offline using standard cracking tools.

Token Forgery / Privilege Escalation

With the recovered secret, the attacker modifies the JWT payload to claim administrator role and re-signs it as a valid token.

AML.T0091.000

Impact

The forged admin token grants full access to restricted endpoints, enabling data exfiltration, configuration tampering, or further compromise of the deployment.

AML.T0012

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LoLLMs	pip	< 2.2.0	`2.2.0`
93 Pushed 24d ago 33% patched ~24d to patch Full package profile →

Do you use LoLLMs? You're affected.

How severe is it?

CVSS 3.1

9.8 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 43% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

Upgrade to lollms 2.2.0 immediately, which fixes the JWT signing issue. If upgrading isn't immediately possible, rotate/replace the JWT secret with a long, cryptographically random value and restart the service so all existing tokens are invalidated; do not expose the lollms admin interface directly to the internet — place it behind a VPN, reverse-proxy auth, or IP allowlist. Detection guidance: monitor for JWT tokens with unexpected admin claims, unusual admin-panel activity from unfamiliar sessions/IPs, and repeated authentication failures that could indicate offline brute-forcing attempts against captured tokens. Review commit https://github.com/parisneo/lollms/commit/a3b2b82b84d537a9da63e63a370a6a8ad55fed34 to confirm the fix scope for custom deployments.

How is it classified?

Auth Bypass Code Execution Framework Plugin AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application AML.T0091.000 - Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.2 / A.6.2.6 - AI system security controls and access management

NIST AI RMF

MANAGE-4.1 - Risks and benefits from third-party AI resources are monitored

Frequently Asked Questions

What is CVE-2026-1114?

lollms, a self-hosted LLM web UI, signs its JWT session tokens with a weak, guessable secret key, letting an attacker crack it offline and forge a token claiming administrator privileges. This is a full authentication bypass on a public-facing AI interface — CVSS 9.8 with complete confidentiality, integrity, and availability impact, since admin access typically exposes model configuration, user management, and plugin/persona installation. There's no public exploit or Nuclei template yet and EPSS sits low (0.0054, though ranked in the top 59% of scored CVEs by percentile), and it isn't in CISA KEV, so this reads as a real but not-yet-weaponized risk rather than an active-exploitation emergency. It also isn't the package's first security issue — 9 other CVEs exist in lollms, and its OpenSSF Scorecard/package risk score (36/100) reflects that track record. Patch immediately to lollms 2.2.0, and if you can't patch today, rotate any JWT signing secrets, restrict network exposure of the admin interface, and audit logs for unexpected admin-scope token usage.

Is CVE-2026-1114 actively exploited?

No confirmed active exploitation of CVE-2026-1114 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-1114?

Upgrade to lollms 2.2.0 immediately, which fixes the JWT signing issue. If upgrading isn't immediately possible, rotate/replace the JWT secret with a long, cryptographically random value and restart the service so all existing tokens are invalidated; do not expose the lollms admin interface directly to the internet — place it behind a VPN, reverse-proxy auth, or IP allowlist. Detection guidance: monitor for JWT tokens with unexpected admin claims, unusual admin-panel activity from unfamiliar sessions/IPs, and repeated authentication failures that could indicate offline brute-forcing attempts against captured tokens. Review commit https://github.com/parisneo/lollms/commit/a3b2b82b84d537a9da63e63a370a6a8ad55fed34 to confirm the fix scope for custom deployments.

What systems are affected by CVE-2026-1114?

This vulnerability affects the following AI/ML architecture patterns: model serving, AI chat interfaces, agent frameworks.

What is the CVSS score for CVE-2026-1114?

CVE-2026-1114 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.54%.

What is the AI security impact?

Affected AI Architectures

model servingAI chat interfacesagent frameworks

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

AML.T0091.000 Application Access Token

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.2 / A.6.2.6

NIST AI RMF: MANAGE-4.1

What are the technical details?

Original Advisory

In parisneo/lollms version 2.1.0, the application's session management is vulnerable to improper access control due to the use of a weak secret key for signing JSON Web Tokens (JWT). This vulnerability allows an attacker to perform an offline brute-force attack to recover the secret key. Once the secret key is obtained, the attacker can forge administrative tokens by modifying the JWT payload and resigning it with the cracked secret. This enables unauthorized users to escalate privileges, impersonate the administrator, and gain access to restricted endpoints. The issue is resolved in version 2.2.0.

Exploitation Scenario

An attacker locates an internet-exposed lollms instance (via scanning or a low-privilege account they already hold) and obtains a valid JWT, either by registering a normal user account or intercepting a session token. They take that token offline and run a brute-force/dictionary attack against the weak signing secret using standard JWT-cracking tools (e.g., hashcat/jwt_tool). Once the secret is recovered, they modify the JWT payload to claim administrator role and re-sign it with the cracked key, producing a valid forged admin token. Using this token, they access restricted admin endpoints to exfiltrate user data, alter model/plugin configuration, or pivot further into the deployment — all while appearing as a legitimately authenticated administrator to the application.

Weaknesses (CWE)

CWE-284 Improper Access Control Primary

CWE-284 — Improper Access Control: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

[Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.