CVE-2026-78553 in RansomLook
Summary
by MITRE • 08/24/2026
RansomLook created its Flask session-signing key without explicitly restricting the file permissions. The secret_key file was created using the process's default permissions and umask, resulting in permissions such as 0644 under a common 022 umask. Consequently, other local users able to access the RansomLook home directory could read the application's cryptographic secret.
The exposed key is security-critical because it is used to sign Flask session cookies and is also involved in the legacy API-key key derivation. An attacker who obtains the key can generate valid session cookies and impersonate an authenticated user, including an administrator. In LDAP configurations, exploitation may be particularly straightforward because the session user loader does not require the supplied username to correspond to an existing local user.
Successful exploitation requires local access sufficient to read the improperly protected file, but can result in complete compromise of RansomLook's authentication and authorization controls.
The patch creates new secret-key files atomically with permissions 0600 and also restricts permissions on existing key files during application startup.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/24/2026
RansomLook suffered from a critical misconfiguration regarding the file system security attributes applied to its cryptographic material, specifically the Flask session-signing key. The vulnerability originated in the initialization phase of the application where the secret_key file was generated without explicit permission restrictions. Instead of adhering to the principle of least privilege by setting restrictive access controls, the process relied on default operating system permissions and the current umask value. Under a standard environment with a 022 umask, this resulted in the key file being created with world-readable permissions, typically octal 0644. This configuration flaw meant that any local user account possessing read access to the RansomLook home directory could inspect the contents of the secret_key file, thereby gaining visibility into the cryptographic secrets essential for maintaining application integrity and confidentiality.
The exposure of this key carries severe security implications because it serves as the foundation for multiple authentication mechanisms within the Flask framework. The secret_key is utilized to sign session cookies, ensuring their authenticity and preventing tampering by clients or third parties. Additionally, in legacy configurations, this same key participates in API-key derivation processes. When an attacker obtains access to this unencrypted secret, they can cryptographically forge valid session tokens that are indistinguishable from those issued by the legitimate server. This capability allows for complete impersonation of any authenticated user within the system. The risk is amplified in environments utilizing LDAP integration because the application's session user loader does not strictly validate whether the username embedded in a forged token corresponds to an existing local or directory user, facilitating unauthorized access without needing valid credentials for specific accounts.
From a threat modeling perspective, this vulnerability aligns with CWE-732: Incorrect Permission Assignment for Critical Resource and CWE-522: Insufficiently Protected Credentials. The attack vector is classified under MITRE ATT&CK technique T1078.4: Valid Accounts - Local Account, as it leverages local file system access to escalate privileges through credential theft rather than exploiting a code execution flaw in the application logic itself. While exploitation requires an attacker to have at least basic read access to the RansomLook directory structure, which may imply prior compromise or insider threat activity, the resulting impact is disproportionate and catastrophic. Successful exploitation leads to the bypass of authentication controls, allowing attackers to assume administrative roles and potentially exfiltrate sensitive data or modify system configurations with full authority.
To remediate this issue, the developers implemented a patch that enforces strict file permission constraints during both new key generation and existing key initialization. The updated code now creates secret-key files atomically using permissions set explicitly to 0600 in octal notation, which restricts read and write access solely to the owner of the file, typically the application service account. Furthermore, upon startup, the application scans for any pre-existing key files with overly permissive settings and automatically corrects their ownership and permission bits to ensure compliance with security best practices. This mitigation effectively eliminates the attack vector by ensuring that even if an attacker gains access to the home directory, they cannot read the cryptographic material required to forge sessions or derive API keys, thereby preserving the integrity of the authentication subsystem.