CVE-2026-78387

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 does not consistently enforce authorization checks when accessing groups, markets, and ransom notes marked as private. An unauthenticated or otherwise unauthorized remote attacker can access information associated with private entities through several web views and API endpoints. The /compare functionality can also be queried directly with the name of a private entity, allowing an unauthorized user to retrieve information such as post counts, mirror totals, and uptime even when the entity is excluded from the normal user interface.

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.