Vulnerabilities

Horde IMP's AppleDouble MIME viewer writes an attacker-controlled attachment name into an HTML status block without escaping it. In lib/Mime/Viewer/Appledouble.php, _IMPrender() obtains the name of the data part with IMP_Contents::getPartName(), which returns the MIME part's own name parameter as supplied by the message, and passes it through sprintf into the text of an IMP_Mime_Status object. IMP_Mime_Status::__toString() concatenates each text entry directly into the surrounding table markup, so the value reaches the rendered page verbatim. A message crafted as multipart/appledouble whose data part carries markup in its name parameter therefore executes script in the context of any user who views it, and the payload persists in the mailbox. Exploitation requires no account on the target system, only the ability to send mail to a user. Version 7.2.0 escapes the value with htmlspecialchars(). The researcher additionally chains this flaw with the arbitrary file read of CVE-2026-58451, and reports that script running in an administrator's session can reach an application code-execution path.

TIM Flow before 26.0.6 contains a CRLF injection vulnerability that allows remote attackers to inject arbitrary HTTP headers and response body content by embedding unsanitized carriage return and line feed sequences in the rt URL parameter, which is reflected into Set-Cookie response headers. Attackers can craft malicious requests to induce authenticated users to execute arbitrary JavaScript in their browser context, enabling session token theft and account credential modification.

HCL Hive is affected by a missing rate limit which could allow an attacker unauthorized access via brute-force or credential stuffing attacks, or cause a denial of service.

TIM Flow before 26.0.6 contains an improper authorization vulnerability that allows any authenticated user to submit arbitrary SQL queries to a privileged dashboard Excel export endpoint intended for administrative use only. Attackers can craft and submit unauthorized SQL queries to the export endpoint to retrieve sensitive database contents as a downloadable spreadsheet, bypassing role-based access controls.

A heap-based buffer overflow vulnerability exists in Konami's Metal Gear Online 3, originating from improper validation of lobby data fields related to kicked players. The affected function processes a list of kicked player identifiers using the lobby data key "kick_num" to determine the number of entries, and individual kicked player IDs supplied via keys in the format "kicked_id_%i". The function does not validate that "kick_num" falls within the expected bounds. The game design limits matches to a maximum of 16 players, and the corresponding buffer for storing kicked player IDs is sized accordingly. If "kick_num" exceeds this limit, the function continues writing the provided player IDs past the end of the intended buffer and into adjacent memory regions. These adjacent regions contain Steam callback handler structures responsible for processing lobby data updates, lobby messages, and other related events. By supplying an oversized "kick_num" value and appropriate "kicked_id_%i" fields, an attacker can overwrite fields within the callback handler structures, including function pointers and callback argument values. Successful exploitation may enable control-flow hijacking, potentially allowing arbitrary code execution within the game process.

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.<br /> <br /> <br /> 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.<br /> <br /> <br /> 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&amp;#39;s collection mechanisms.<br /> <br /> <br /> 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.<br /> <br /> <br /> The accompanying change from to appears to be a functional correction allowing legitimate post titles containing / and does not, based on this patch alone, represent the security issue.

RansomLook contains an authorization flaw in its legacy database export functionality that can allow unauthenticated remote users to retrieve information intended to remain private.<br /> <br /> The /export/ 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&amp;#39;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.<br /> <br /> 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.<br /> <br /> 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.

RansomLook does not consistently <br /> enforce authorization checks when accessing groups, markets, and ransom <br /> notes marked as private. An unauthenticated or otherwise unauthorized <br /> remote attacker can access information associated with private entities <br /> through several web views and API endpoints.<br /> <br /> <br /> The affected functionality can <br /> disclose private group or market names, ransom-note content, and <br /> metadata associated with private groups. The /compare<br /> functionality can also be queried directly with the name of a private <br /> entity, allowing an unauthorized user to retrieve information such as <br /> post counts, mirror totals, and uptime even when the entity is excluded <br /> from the normal user interface. The patch explicitly adds a privacy <br /> check before returning this information. <br /> <br /> <br /> Ransom-note views, search results, <br /> and API endpoints were similarly missing consistent filtering. The fix <br /> introduces normalized private-group identifiers and alias handling, then<br /> rejects or filters notes associated with private groups before <br /> returning them to unauthorized callers. <br /> <br /> <br /> An attacker can exploit the issue <br /> remotely without authentication or user interaction, resulting in <br /> disclosure of information that was explicitly intended to be restricted <br /> to authorized users.

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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.

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.<br /> <br /> <br /> The /api/health/ 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.<br /> <br /> <br /> Similar unsafe interpolation was present in /api/crypto/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.<br /> <br /> <br /> 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.

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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.

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&amp;#39;s source/ directory and opens the resulting path without verifying that the resolved file remains within the intended directory.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> The vulnerability is addressed by resolving screen paths with os.path.realpath() and verifying that the resolved path remains beneath the application&amp;#39;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.