CVE-2026-1114
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn 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.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceIn parisneo/lollms 2.1.0, the session management uses a weak secret key for signing JSON Web Tokens (JWTs). An attacker can perform an offline brute-force attack to recover this secret key, then forge administrative tokens by modifying the JWT payload and re-signing with the cracked secret. This enables unauthorized privilege escalation to administrator level and access to restricted endpoints.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data= 2.1.0CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify installed Lollms versionRun 'pip show lollms' or check the package version in your environment using pip list | grep lollms, or look for a version file in the Lollms installation directoryAffected if Version is exactly 2.1.0
-
Locate JWT configuration filesSearch the Lollms installation directory for files containing 'jwt', 'secret', or 'token' in filenames, or examine the main configuration file for JWT-related settingsAffected if JWT secret is hardcoded, uses a default value, or uses a weak/guessable secret key
-
Inspect JWT secret key strengthExamine the JWT configuration to see the secret key used for signing tokens - check if it is short, uses common patterns, or appears in wordlistsAffected if The secret key is less than 32 characters, uses common words, or matches known weak patterns
-
Review active JWT tokensIf you have access to token logs or can inspect active sessions, examine JWT tokens for the 'alg' header (should not be 'none') and verify signatures where possibleAffected if Tokens can be validated with a publicly known or easily guessed secret key
-
Check for unauthorized administrative accessReview access logs for administrative endpoints, privilege escalation events, or accounts with admin role that were not created by known administratorsAffected if There are signs of admin-level access from accounts that should not have that privilege
You are affected if Lollms version 2.1.0 is installed and the JWT signing secret is weak, default, or easily guessable - this allows attackers to forge administrative tokens.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpgrade to version 2.2.0 immediately and rotate the JWT secret key, invalidating all existing sessions to prevent continued access by attackers who may have already cracked the key.
2.2.0
- 1. Verify current Lollms installation version by checking the installed package or running: pip show lollms or checking the version file
- 2. Create a full backup of the current Lollms installation including configuration files, databases, and any custom settings
- 3. Upgrade Lollms to version 2.2.0 using the package manager: pip install lollms==2.2.0 or pip install --upgrade lollms
- 4. If using a Docker container, pull the updated image tag for version 2.2.0 and redeploy
- 5. After upgrading, restart the Lollms service to load the new version
- 6. Verify the upgrade was successful by checking the version: pip show lollms
- 7. Confirm the JWT secret has been regenerated by checking configuration files for the new secret key implementation
- 8. Test that user authentication and session management work correctly with the updated version
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation3.0 h
- Implementation3.0 h
- Testing2.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,880.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-1114 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-1114 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data