CVE-2026-105141 in cognee
Summary
by MITRE • 10/04/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/04/2026
The vulnerability identified in topoteretes cognee versions up to 1.5.4 represents a critical configuration error within the JWT Signing Key Handler component, specifically located in the get_user_id_by_email function of the authentication module file get_api_auth_backend.py. This flaw stems from the improper handling of the FASTAPI_USERS_JWT_SECRET environment variable or configuration parameter. Instead of dynamically retrieving this secret key at runtime to ensure uniqueness and secrecy per deployment instance, the implementation inadvertently results in hard-coded credentials being used for JWT signing operations. Hard-coding cryptographic secrets is a severe anti-pattern that fundamentally undermines the security model of token-based authentication systems, as it removes the ability to rotate keys or maintain distinct secrets across different environments such as development, staging, and production.
From a technical perspective, this misconfiguration allows any party with knowledge of the default secret key to forge valid JSON Web Tokens (JWTs). Since JWT signatures are used to verify the integrity and authenticity of tokens issued by the server, an attacker who possesses the hard-coded secret can generate arbitrary tokens that appear legitimate to the application. This capability effectively bypasses authentication mechanisms entirely for any user account associated with the system. The vulnerability is classified under CWE-798 as Use of Hard-coded Credentials, which highlights the risk of exposing sensitive data through static code elements rather than secure configuration management practices. Furthermore, this flaw aligns with ATT&CK technique T1078 Valid Accounts, specifically in the context of credential spoofing or misuse, where an adversary leverages improperly secured credentials to gain unauthorized access without needing to crack passwords or exploit other authentication bypasses.
The operational impact of this vulnerability is severe due to its remote exploitable nature. An attacker can launch attacks from a remote location over a network connection, requiring no prior access to the system. By forging JWTs with arbitrary claims, such as elevated privileges or administrative roles, an adversary can gain full control over user sessions and potentially escalate their permissions within the application. This could lead to unauthorized data exposure, modification of critical records, or complete compromise of the backend services that rely on these tokens for authorization decisions. The persistence of this flaw across multiple versions indicates a systemic issue in how configuration secrets are managed during the build and deployment processes, posing a significant risk to any organization relying on cognee for user authentication and identity management.
To mitigate this vulnerability, it is imperative to upgrade topoteretes cognee to version 1.6.0 or later, where the patch identified as fa65fc0cd86cdba48d19aa76e36be862be982f5d addresses the root cause by ensuring that JWT signing keys are not hard-coded but instead derived securely from dynamic configuration sources. Organizations should also audit their deployment pipelines to ensure that secret management follows industry best practices, such as using dedicated secrets managers or environment-specific injection mechanisms rather than embedding values in source code. Additionally, implementing regular key rotation policies and monitoring for anomalous token usage patterns can provide an additional layer of defense against potential exploitation attempts while the upgrade is being implemented across all affected instances.