CVE-2026-78372

RansomLook exposed complete API keys in the HTML source of the authenticated /admin/apikeys administration page. Although the interface displayed only a shortened representation of each key, the full token was embedded in hidden form fields used by the enable/disable, private-access, and delete actions.

RansomLook contains an authorization weakness in the web-based configuration editor exposed through the /admin/config endpoint. The endpoint requires an authenticated session but does not perform an explicit privilege or administrator authorization check before allowing access to configuration-management functionality. An authenticated low-privileged user can modify the config/generic.json file, changing notification, LDAP, SMTP, and general application settings.

RansomLook contains an authorization flaw in its legacy database export functionality that can allow unauthenticated remote users to retrieve information intended to remain private. The /export/<database> endpoint permits selected internal databases to be exported without requiring authentication. While limited filtering is performed for some entity databases, other exportable databases are returned directly without consistently applying the application's private-entity access restrictions. As a result, information associated with groups, markets, posts, or other records marked as private may be included in an export accessible to an unauthenticated requester.

RansomLook created its Flask session-signing key without restricting file permissions, resulting in permissions like 0644. Other local users can read the cryptographic secret, allowing them to generate valid session cookies and impersonate authenticated users, including administrators.

RansomLook contains multiple weaknesses in its authentication endpoint that allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially exhaust application worker resources. The issue stems from timing differences for existing vs. non-existing usernames and lack of rate limiting on failed login attempts.

RansomLook contains a stored cross-site scripting (XSS) vulnerability in the cryptocurrency wallet detail view. Cryptocurrency addresses and blockchain names from external sources, including the public crowd-sourced ransomwhe.re feed, were stored without sufficient validation and embedded directly into an inline JavaScript onclick handler. Although Jinja HTML autoescaping was applied, it does not protect against untrusted data in a JavaScript string inside an HTML attribute, allowing crafted addresses to execute arbitrary JavaScript.

RansomLook exposes sensitive operator-side scraping configuration through multiple unauthenticated API responses. Location records associated with ransomware groups and markets are returned largely verbatim to unauthenticated callers whenever the location itself is not marked as private. These records may contain internal fields such as authentication headers, session cookies, init scripts, and browser details.

RansomLook contains insufficient resource validation in the analysis PDF generation functionality. Analysis documents are converted from Markdown to HTML and passed to WeasyPrint for PDF rendering. Prior to the fix, WeasyPrint used its default URL fetcher, allowing resource references contained in an analysis to be resolved without restrictions.

RansomLook contains a path traversal vulnerability in the handling of the screen field associated with group posts. The GroupPost.get API handler concatenates the database-controlled screen value directly with the application's source/ directory and opens the resulting path without verifying that the resolved file remains within the intended directory. A malicious upstream instance can provide traversal sequences such as ../config/generic.json, leading to arbitrary file read.

The vulnerability in RansomLook is due to the failure to enforce the privacy status of ransomware groups and markets when distributing newly collected victim posts to external notification channels. The post-processing logic only checks whether an individual post is marked private, but does not verify whether the group or market to which the post belongs is configured as private. As a result, victim information from private groups or markets may be automatically published through enabled Rocket.Chat, Mastodon, Bluesky, and email notification channels, as well as added to the public MISP feed.