---
id: CVE-2026-78386
title: >-
  RansomLook exposed sensitive operator-side scraping configuration through
  multiple unauthenticated API responses
summary: >-
  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 wh…
severity: none
cwe:
  - CWE-200
published: '2026-08-24'
updated: '2026-10-14'
sourceUpdated: '2026-10-14T13:10:00.187'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-78386'
references:
  - url: >-
      https://github.com/RansomLook/RansomLook/commit/cc9182930306ff36c7b3424817d49f18df3c85d1
    label: 5a6e4751-2f3f-4070-9419-94fb35b644e8
tags:
  - nvd
epss: 0.00797
epssPercentile: 0.55344
ingestedAt: '2026-10-14T13:30:58.561Z'
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
