CVE-2026-78386: Unauthenticated Disclosure of Scraping Credentials and Bypass Configuration via RansomLook API
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; initscript, 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the RansomLook API so public location records returned to unauthenticated callers use an explicit allowlist of fields and remove/strip operator-side scraping/bypass configuration fields (e.g., header, init_script, browser) before responding.
RansomLook API public location records field_allowlist/public response schema = Enable explicit allowlist of permitted fields and strip operator-side fields from unauthenticated responses
Event History
Frequently Asked Questions
Which deployments are exposed to unauthenticated retrieval of sensitive fields?
Deployments are exposed where location records are available through the affected API and the location is not marked private. Public location records could return operator-side fields verbatim before the patch.
Does an attacker need an account or other prior access?
No. The affected API responses could be queried remotely by unauthenticated callers.
What information should be checked for prior exposure?
Review unauthenticated API responses for public location records and determine whether they include fields such as header, init_script, or browser. The header field may contain authentication headers, session cookies, or other credentials.
What changes with the patch?
The patch applies an explicit allowlist for fields permitted in public location records and removes operator-side fields from responses to unauthenticated users.