Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify internet-facing cognee API
-
DeliverySign forged JWT with default "super_secret" key
-
ExploitPresent token as admin user
-
ExecutionBypass authentication
-
ImpactRead 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. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – 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
Affected Packages
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
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
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).
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
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
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-92086
GHSA-xrgh-2vxr-rhm4
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB