Skip to main content

cognee CVE-2026-105141

| EUVDEUVD-2026-92086 MEDIUM
Use of Hard-coded Credentials (CWE-798)
2026-10-04 VulDB GHSA-xrgh-2vxr-rhm4
5.3
CVSS 4.0 · Vendor: VulDB
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Identify internet-facing cognee API
  2. Delivery
    Sign forged JWT with default "super_secret" key
  3. Exploit
    Present token as admin user
  4. Execution
    Bypass authentication
  5. Impact
    Read and modify all stored knowledge-graph data

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Credential externalization
MITRE ATT&CK

2 techniques across 2 tactics: Persistence, Credential Access

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitable only when the operator has NOT set the FASTAPI_USERS_JWT_SECRET environment variable (and, for related flows, FASTAPI_USERS_RESET_PASSWORD_TOKEN_SECRET / FASTAPI_USERS_VERIFICATION_TOKEN_SECRET), causing cognee <=1.5.4 to sign JWTs with the built-in literal "super_secret" in get_api_auth_backend.py. This is the shipped default behavior, so default/unconfigured installs are vulnerable; the attacker needs network reachability to the cognee API and knowledge of the public default secret, but no account. The primary limiting factor is configuration: any deployment that explicitly set a strong secret is unaffected, and v1.6.0 removes the fallback entirely by generating a per-process random secret.

Impact

This is a hard-coded credentials flaw (CWE-798): when FASTAPI_USERS_JWT_SECRET is left unset, cognee up to 1.5.4 falls back to the publicly known literal value "super_secret" to sign authentication JWTs, as confirmed by the GitHub source diff. Anyone who knows this default (now public in the repo and this advisory) can forge valid tokens - including admin tokens, which the removed cognee/get_token.py helper demonstrates directly - yielding a full authentication bypass against any deployment that relied on the default. The input CVSS 4.0 vector (PR:L, VC:L/VI:L/VA:L, score 5.3/MEDIUM) UNDERSTATES this: forging a token requires no prior privileges (should be PR:N, not PR:L) and grants administrative access, so impact is realistically High, not Low - verify with vendor/VulDB. No EPSS score was provided and the CVE is NOT in CISA KEV; no public exploit is catalogued, so there is no evidence of active exploitation. The decisive real-world limiter is configuration: deployments that already set a strong FASTAPI_USERS_JWT_SECRET are not affected, and in v1.6.0 the fallback was replaced with a per-process random secret. Net: the headline MEDIUM score masks a trivially exploitable critical-style auth bypass for default/unconfigured installs, but exposure is gated by deployment hygiene and the product's limited footprint rather than by attacker difficulty.

Exploit ScenarioDerived

An attacker locates an internet-reachable cognee API deployed with FASTAPI_USERS_JWT_SECRET unset (the default). Because the signing key is the publicly known string "super_secret", the attacker crafts and signs a JWT asserting an admin user_id/roles (exactly as the shipped get_token.py helper does) and presents it to the API. The server validates the forged token and grants administrative access with no credentials; no formal public PoC is catalogued, but the removed get_token.py effectively serves as a working token-forging primitive.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 04, 2026

Authentication token forgery in topoteretes cognee through 1.5.4 lets a remote attacker who can reach the API mint valid JWTs without any account, because the application signs tokens with the publicly known literal "super_secret" whenever the FASTAPI_USERS_JWT_SECRET environment variable is left unset. Because that fallback is the shipped default behavior, unconfigured or default deployments are exposed, and the same pattern affects the password-reset and email-verification token secrets; successful forgery yields full compromise of confidentiality, integrity, and availability of the cognee instance. Upgrading to 1.6.0 removes the shared fallback entirely and replaces it with a per-process random secret; no public exploit code was identified at time of analysis, and CISA KEV does not list this issue.

RemediationAI

Vendor-released patch: upgrade to cognee 1.6.0 (https://github.com/topoteretes/cognee/releases/tag/v1.6.0), which removes the hard-coded fallback and generates a per-process random secret via the new get_auth_secret module. If immediate upgrade is not possible, the actionable mitigation is to explicitly set FASTAPI_USERS_JWT_SECRET - plus FASTAPI_USERS_RESET_PASSWORD_TOKEN_SECRET and FASTAPI_USERS_VERIFICATION_TOKEN_SECRET - to long, randomly generated values in the environment or .env file on every instance; this overrides the "super_secret" default, but the secret must be identical across all API workers, replicas, and separate API/worker processes, otherwise tokens issued by one process will be rejected by another (the same multi-process caveat the 1.6.0 implementation documents). Because tokens are only as trustworthy as the key, treat any instance that ran with the default as compromised: rotate the secrets and invalidate existing JWTs, which invalidates active user sessions and forces re-authentication and re-issuance of password-reset and email-verification links. Also restrict network exposure of the cognee API (bind to localhost or a trusted reverse proxy/private network, block public access) as a compensating control, with the trade-off of reduced accessibility for legitimate clients. Applying the upstream PR/commit diff manually is possible where a tagged upgrade is impractical, but only the 1.6.0 release is independently confirmed as the fixed version.

Affected VersionsENISA

cognee 1.5.4
cognee 1.5.2
cognee 1.5.0
cognee 1.5.3
cognee 1.5.1

Affected Packages

euvd cognee no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw is CWE-798 (use of hard-coded credentials) in cognee's FastAPI authentication stack. In cognee/modules/users/authentication/get_api_auth_backend.py, the JWT signing secret was resolved as os.getenv("FASTAPI_USERS_JWT_SECRET", "super_secret"), so any deployment that did not explicitly export the variable signed and verified HS256 tokens with a constant, source-published string; the removed cognee/get_token.py helper repeated the same default. An attacker who knows that constant (it is visible in the repository and in the .env.template shipped with the product) can craft a JWT with arbitrary user_id, tenant_id, and roles claims that the server will accept, effectively bypassing authentication and authorization without possessing valid credentials - consistent with the Authentication Bypass tag and with the independent assessment's CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H vector, which treats the attack as unauthenticated despite the vendor-supplied CVSS 4.0 vector listing PR:L. The upstream fix (PR #5062, commit fa65fc0cd86cdba48d19aa76e36be862be982f5d, release v1.6.0) introduces cognee/modules/users/authentication/get_auth_secret.py, which reads the environment variable and, when it is unset or blank, generates a per-process secret via secrets.token_urlsafe(64) instead of a shared default, caching it with lru_cache and warning once at server startup through resolve_auth_secrets(). The affected CPE cpe:2.3:a:topoteretes:cognee:*:*:*:*:*:*:*:* covers all releases; ENISA EUVD enumerates 1.5.0 through 1.5.4 as vulnerable. The trade-off documented by the vendor is that generated secrets are process-local, so tokens stop verifying after a restart and are not shared across replicas.

Know when Cognee gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (VulDB) PRIMARY 5.3 MEDIUM
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
vuln.today AI 9.8 CRITICAL

Known default signing key lets a remote unauthenticated attacker forge admin JWTs (PR:N/AC:L), bypassing auth and gaining full read/write/delete over data (C:H/I:H/A:H).

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (VulDB).

CVSS VectorVendor: VulDB

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
Low
User Interaction
None
Vulnerable system: Confidentiality
Low
Vulnerable system: Integrity
Low
Vulnerable system: Availability
Low
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

A security flaw has been discovered in topoteretes cognee up to 1.5.4. The affected element is the function get_user_id_by_email of the file cognee/modules/users/authentication/get_api_auth_backend.py of the component JWT Signing Key Handler. The manipulation of the argument FASTAPI_USERS_JWT_SECRET results in hard-coded credentials. The attack may be launched remotely. Upgrading to version 1.6.0 is sufficient to fix this issue. The patch is identified as fa65fc0cd86cdba48d19aa76e36be862be982f5d. Upgrading the affected component is advised.

Threat Intelligence Overview

EPSS Score
0.3%
Top 75% exploitable
Prevalence
Low
niche open-source AI memory/knowledge-graph framework, limited production footprint
Social Media
1
Sightings
Data Quality
8 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment CIRCL GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

26
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +26
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy