CVE-2026-78555: RansomLook API Key Disclosure Through /admin/apikeys HTML Source
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.
As a result, API credentials could be recovered by inspecting the page source or DOM. The credentials could also be unintentionally exposed through components that retain or inspect HTTP response bodies, such as debugging proxies, browser caches, monitoring systems, or other intermediaries. An attacker obtaining one of these tokens could subsequently authenticate using the privileges assigned to that key, including access to private data where the key was granted such permissions.
The patch removes API keys from subsequent page rendering and replaces them with SHA-256-derived opaque handles. Administrative actions submit only these handles, which are resolved back to the corresponding token on the server. The full API key is therefore disclosed only once, when it is initially created.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the patch behavior so that /admin/apikeys no longer renders the complete API keys in subsequent page HTML/DOM; instead render opaque handles derived from SHA-256 and use those handles for enable/disable/private-access/delete actions.
RansomLook /admin/apikeys API key rendering in HTML source/DOM = Replace full API key with SHA-256-derived opaque handles (hidden form fields) after initial creation
Event History
Frequently Asked Questions
Who could recover the exposed API keys?
Any user authenticated to the /admin/apikeys administration page could recover complete keys by inspecting the page source or DOM. Keys could also be exposed to systems or personnel able to retain or inspect the page's HTTP response bodies, such as debugging proxies, browser caches, monitoring systems, or other intermediaries.
What access could an attacker gain with a recovered key?
A recovered key can be used to authenticate with the privileges assigned to that key. This can include access to private data when the key has private-access permissions.
How can teams determine whether they may already be affected?
Review whether complete API keys were rendered in responses for authenticated /admin/apikeys pages, including hidden form fields for enable/disable, private-access, or delete actions. Also review response-retaining components, such as proxy, cache, and monitoring records, for copies of those pages.
What should be done if keys may have been exposed before applying the patch?
Treat keys that appeared on affected administration-page responses as potentially disclosed, especially if response bodies were available to intermediaries or unauthorized administrators. The provided data indicates the patch prevents subsequent rendering of full keys; it does not state that previously exposed keys are invalidated.