Search
Search Results (11 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-78385 | 1 Ransomlook | 1 Ransomlook | 2026-08-24 | N/A |
| 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. An authenticated attacker able to create or modify an analysis could embed crafted resource references using schemes such as file:// or http://. When the analysis was subsequently rendered as PDF, WeasyPrint would process these references with the privileges and network access of the RansomLook server. A malicious file:// reference could cause the renderer to access arbitrary files readable by the RansomLook process, potentially exposing sensitive configuration, credentials, or other local data through rendered resources. Network URLs could cause the server to initiate requests to localhost, internal network services, or external systems, resulting in server-side request forgery (SSRF) and potentially bypassing network-level access restrictions. The patch introduces a dedicated WeasyPrint URL fetcher that permits only data: resources, the RansomLook report logo, and files contained within the analysis asset directory. Network resources and filesystem paths outside these explicitly permitted locations are rejected. | ||||
| CVE-2026-78370 | 1 Ransomlook | 1 Ransomlook | 2026-08-24 | N/A |
| 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. An attacker able to reach the RansomLook web application can request the affected export endpoint and retrieve data that should only be available to authorized users. Depending on the contents of the instance, this may disclose private ransomware intelligence, victim information, internal tracking data, or other information deliberately excluded from public views. The patch removes the legacy unauthenticated export route and introduces centralized authorization handling that distinguishes ordinary authenticated API access from authorization to view private entries. API keys must now be explicitly granted private-data access, while existing keys do not automatically receive this privilege. The same private-data filtering is also applied consistently across API responses and database exports. | ||||
| CVE-2026-78369 | 1 Ransomlook | 1 Ransomlook | 2026-08-24 | N/A |
| RansomLook contains a missing authentication vulnerability in the /admin/crypto/group/new endpoint. While the endpoint provides an administrative function for creating new crypto group entries, it was not protected by the application's authentication mechanism. An unauthenticated remote attacker able to access the RansomLook web interface could therefore submit requests to this endpoint and create crypto group entries without possessing a valid authenticated session or administrative credentials. Successful exploitation allows an attacker to make unauthorized modifications to data that should only be manageable by authenticated administrators. Depending on how crypto group information is subsequently consumed by RansomLook, malicious or fraudulent entries could also affect the integrity of information presented or processed by the application. The vulnerability is addressed by applying the flask_login.login_required decorator to the /admin/crypto/group/new route, ensuring that only authenticated users can access the functionality. | ||||
| CVE-2026-78386 | 1 Ransomlook | 1 Ransomlook | 2026-08-24 | N/A |
| RansomLook exposed sensitive operator-side scraping configuration through multiple unauthenticated API responses. Location records associated with ransomware groups and markets were returned largely verbatim to unauthenticated callers whenever the location itself was not marked as private. These records could contain internal fields such as header, which may include authentication headers, session cookies, or other credentials used to access monitored websites; init_script, which may contain logic used to bypass CAPTCHA, anti-bot protections, or paywalls; and browser, which discloses details about the scraping environment. An unauthenticated remote attacker could query the affected API endpoints and obtain these values. Leaked authentication material could potentially be replayed against the monitored service, while disclosure of scraping and bypass logic could allow site operators or other attackers to identify and defeat RansomLook's collection mechanisms. The patch introduces an explicit allowlist of fields permitted in public location records and strips all operator-side fields before returning data to unauthenticated users. The accompanying change from <string:postname> to <path:postname> appears to be a functional correction allowing legitimate post titles containing / and does not, based on this patch alone, represent the security issue. | ||||
| CVE-2026-78372 | 1 Ransomlook | 1 Ransomlook | 2026-08-24 | N/A |
| 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 affected functionality can disclose private group or market names, ransom-note content, and metadata associated with private groups. 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. The patch explicitly adds a privacy check before returning this information. Ransom-note views, search results, and API endpoints were similarly missing consistent filtering. The fix introduces normalized private-group identifiers and alias handling, then rejects or filters notes associated with private groups before returning them to unauthorized callers. An attacker can exploit the issue remotely without authentication or user interaction, resulting in disclosure of information that was explicitly intended to be restricted to authorized users. | ||||
| CVE-2026-78378 | 1 Ransomlook | 1 Ransomlook | 2026-08-24 | N/A |
| Ransomlook contains a Redis glob pattern injection vulnerability caused by insufficient neutralization of user-controlled input before it is incorporated into Redis SCAN MATCH patterns. The /api/health/<name> endpoint attempted to resolve the supplied name to a known group or market, but when resolution failed it fell back to using the attacker-controlled value directly in a Redis key pattern. An unauthenticated attacker could therefore supply Redis glob metacharacters such as *, ?, [ or ] to broaden the SCAN operation beyond the intended group. For example, requesting /api/health/* could enumerate health information, mirror slugs, and uptime series belonging to all groups and markets, including entities marked as private. Similar unsafe interpolation was present in /api/crypto/chain/<chain> and in the delete_manual_torrent() function. The latter represents a potentially destructive sink because a crafted infohash containing glob metacharacters could cause the scan to match torrent-health keys belonging to other torrents if attacker-controlled input can reach that function. The patch removes the unsafe fallback from the health endpoint and introduces glob escaping for user-controlled values before they are incorporated into Redis SCAN MATCH expressions. | ||||
| CVE-2026-78387 | 1 Ransomlook | 1 Ransomlook | 2026-08-24 | N/A |
| 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 able to access the endpoint can submit crafted configuration values that are written directly to the application's config/generic.json file. The affected functionality permits modification of configuration sections including notification, LDAP, SMTP, and general application settings. Successful exploitation could therefore allow an attacker to alter security-sensitive application behavior, redirect integrations or notifications, modify authentication-related configuration, disrupt external services, or render the RansomLook installation unavailable. The configuration editor also operated on a configuration file containing sensitive values such as passwords, tokens, secrets, and API keys. Although the affected version contains logic intended to prevent recognized secret values from being returned to the browser, exposing configuration management through insufficiently authorized web functionality significantly increases the impact of a compromised or low-privileged account. The patch resolves the issue by completely removing the /admin/config route and associated configuration-editing interface, preventing application configuration from being modified through the web UI. | ||||
| CVE-2026-78391 | 1 Ransomlook | 1 Ransomlook | 2026-08-24 | N/A |
| RansomLook contains a stored cross-site scripting (XSS) vulnerability in the cryptocurrency wallet detail view. Cryptocurrency addresses and blockchain names originating from external sources, including the public crowd-sourced ransomwhe.re feed, were stored without sufficient validation and later embedded directly into an inline JavaScript onclick handler. Although Jinja HTML autoescaping was applied, it does not provide adequate protection when untrusted data is inserted into a JavaScript string inside an HTML attribute. HTML entities such as ' are decoded by the browser's HTML parser before the resulting attribute is interpreted as JavaScript. Consequently, a specially crafted cryptocurrency address containing quote characters and JavaScript syntax could escape the intended string literal and execute arbitrary JavaScript when a user clicked the affected wallet's CSV export button. Because cryptocurrency information imported from an untrusted upstream could reach the vulnerable rendering path, exploitation may not require an authenticated RansomLook account if an attacker can introduce a malicious wallet record into a consumed external data source. Successful exploitation could allow attacker-controlled JavaScript to execute in the security context of the RansomLook web application, potentially exposing information accessible to the victim or performing actions with the victim's privileges. The patch mitigates the issue by validating cryptocurrency addresses and blockchain identifiers before storage, restricting them to a safe character set, and replacing the inline JavaScript handler with data-* attributes and an external event listener so wallet values are treated strictly as data rather than executable JavaScript. | ||||
| CVE-2026-78381 | 1 Ransomlook | 1 Ransomlook | 2026-08-24 | N/A |
| 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. Because the screen field is free-form and can be populated either through the administrative post editor or through data imported from a remote RansomLook instance, a malicious upstream instance can provide traversal sequences such as ../config/generic.json. When the affected post is subsequently retrieved through the API, RansomLook resolves and reads the attacker-controlled path and returns the contents of the referenced file Base64-encoded in the API response. This can allow an attacker (being admin) controlling imported post data to read arbitrary files accessible to the RansomLook process, potentially exposing sensitive configuration data, API credentials, password hashes, or other application secrets. The attack does not require the malicious upstream to possess an account on the affected RansomLook instance. The vulnerability is addressed by resolving screen paths with os.path.realpath() and verifying that the resolved path remains beneath the application's source/ directory. Validation is performed both when values are written and immediately before files are read. Using canonical paths also prevents traversal through symbolic links that would bypass purely lexical path normalization checks. | ||||
| CVE-2026-78380 | 1 Ransomlook | 1 Ransomlook | 2026-08-24 | N/A |
| RansomLook fails to enforce the privacy status of ransomware groups and markets when distributing newly collected victim posts to external notification channels. The post-processing logic 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, newly parsed victim information associated with a private group or market may be automatically published through enabled Rocket.Chat, Mastodon, Bluesky, and e-mail notification channels despite the entity being explicitly configured to prevent public disclosure. A similar issue affects the public MISP feed. The feed previously determined privacy using groupinfo(), which only queries the group database. Consequently, victim information associated with private markets could be added to the public MISP feed because the corresponding market privacy flag was not evaluated. An attacker or other unauthorized party able to access these public notification channels or the MISP feed may obtain victim information that was intended to remain private. Depending on the collected data, this may disclose victim names, ransomware activity, incident information, or other information associated with privately monitored groups and markets. The fix introduces a common is_private_entity() check covering both groups and markets and prevents private entity posts from being distributed through external notification channels or the public MISP feed. Internal storage and dashboard alerting remain unaffected. | ||||
| CVE-2026-40584 | 1 Ransomlook | 1 Ransomlook | 2026-04-27 | 7.5 High |
| RansomLook is a tool to monitor Ransomware groups and markets and extract their victims. Prior to 1.9.0, the API in the affected application improperly filters private location entries in website/web/api/genericapi.py. Because the code removes elements from a list while iterating over it, entries marked as private may be unintentionally retained in API responses, allowing unauthorized disclosure of non-public location information. This vulnerability is fixed in 1.9.0. | ||||
Page 1 of 1.