CVE-2026-78553: RansomLook Auth Bypass Vulnerability

CVE-2026-78553 Overview

RansomLook, an open-source ransomware intelligence platform, created its Flask session-signing key file without explicitly restricting file permissions. The secret_key file was written using the process's default umask, commonly resulting in mode 0644. Any local user with access to the RansomLook home directory could read the cryptographic secret used to sign Flask session cookies and derive legacy API keys. This weakness is classified under CWE-276: Incorrect Default Permissions.

Critical Impact

A local attacker who reads the exposed secret_key can forge valid Flask session cookies, impersonate authenticated users including administrators, and fully compromise RansomLook's authentication and authorization controls.

Affected Products

• RansomLook (open-source ransomware tracking platform)
• Instances where the Flask secret_key file was generated under a permissive umask (for example, 022)
• LDAP-integrated deployments where the session user loader does not validate against local users

Discovery Timeline

• 2026-08-24 - CVE-2026-78553 published to NVD
• 2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-78553

Vulnerability Analysis

RansomLook generates a Flask secret_key file at first startup to sign session cookies. The application wrote this file using default file-creation semantics, inheriting the process umask. On systems with a common 022 umask, the resulting mode is 0644, making the file world-readable. Any local account on the host can read the signing key.

The key is security-critical for two reasons. It signs Flask session cookies, so possession of the key allows an attacker to mint arbitrary signed sessions. It also participates in the legacy API-key derivation, expanding the blast radius beyond web sessions.

In LDAP-backed deployments the impact is amplified. The session user loader does not require the supplied username to correspond to an existing local user, so an attacker can forge a session for any account name including an administrator without prior enumeration.

Root Cause

The root cause is missing explicit permission control at file creation. The code path that materialized the secret_key did not call os.open with mode 0o600, did not set a restrictive umask, and did not verify or tighten permissions on existing key files at startup.

Attack Vector

Exploitation requires local read access to the RansomLook home directory. An attacker with an unprivileged shell reads the secret_key, then constructs a forged Flask session cookie using the recovered key and submits it to the RansomLook web interface to gain authenticated access as any chosen user.

 from werkzeug.security import generate_password_hash
 
 from ransomlook.default import DB_TASKS, get_config, get_homedir, get_socket_path
+from ransomlook.default.logging import get_logger
 
 
 def load_user_from_request(request):  # type: ignore

Source: RansomLook commit df9d47e. The patch creates new secret-key files atomically with mode 0600 and tightens permissions on any pre-existing key file during application startup.

Detection Methods for CVE-2026-78553

Indicators of Compromise

• Presence of a RansomLook secret_key file with permissions broader than 0600 (for example, 0644 or group/world readable).
• Flask session cookies presented from clients that never completed a successful login flow in application logs.
• Administrator-level actions in RansomLook audit logs originating from unusual source IPs or user-agents.
• LDAP-authenticated sessions for usernames that do not exist in the connected directory.

Detection Strategies

• File integrity monitoring on the RansomLook home directory to alert on secret_key files created with permissive modes.
• Periodic permission audits using find <ransomlook_home> -name 'secret_key' -not -perm 600.
• Web application logging that correlates session identifiers to authentication events, flagging sessions with no prior login.

Monitoring Recommendations

• Monitor local user access to the RansomLook home directory, especially read operations on secret_key by accounts other than the service user.
• Track unusual administrator activity within RansomLook, including configuration changes and API key issuance.
• Alert on RansomLook process restarts followed by cookie signature changes, which can indicate secret rotation attempts by an attacker.

How to Mitigate CVE-2026-78553

Immediate Actions Required

• Update RansomLook to the version that includes commit df9d47e, which enforces 0600 permissions on the secret_key file.
• Rotate the existing secret_key value on any host where the file may have been readable by other local users, and invalidate all outstanding sessions and legacy API keys.
• Audit local accounts on RansomLook hosts and remove any accounts that do not require access to the application.

Patch Information

The upstream fix is available in RansomLook commit df9d47edcf02dd0125db869d5bc19d93f426d892. The patch creates new secret_key files atomically with mode 0600 and restricts permissions on existing key files during application startup, closing the exposure without requiring administrator intervention after upgrade.

Workarounds

• Manually restrict permissions on the existing key file with chmod 600 <ransomlook_home>/secret_key and confirm ownership matches the RansomLook service account.
• Run the RansomLook service under a dedicated user account and restrict the home directory with chmod 700.
• Set a restrictive umask (umask 077) for the RansomLook service unit until the patch is applied.
• For LDAP-integrated deployments, add server-side validation that session usernames correspond to directory entries before authorizing requests.

# Configuration example
chmod 700 /path/to/ransomlook
chmod 600 /path/to/ransomlook/secret_key
chown ransomlook:ransomlook /path/to/ransomlook/secret_key
find /path/to/ransomlook -name 'secret_key' -not -perm 600 -exec chmod 600 {} \;