CVE-2026-39972
Cache Key Collision in Mercure Enables Unauthorized Data Access
Publication date: 2026-04-09
Last updated on: 2026-04-09
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| mercure | mercure | to 0.22.0 (exc) |
| dunglas | mercure | to 0.22.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1289 | The product receives an input value that is used as a resource identifier or other type of reference, but it does not validate or incorrectly validates that the input is equivalent to a potentially-unsafe value. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows private updates to be delivered to unauthorized subscribers or blocked from authorized ones by bypassing authorization checks. Such unauthorized data disclosure can lead to violations of data protection regulations like GDPR and HIPAA, which require strict controls over access to private and sensitive information.
Because the vulnerability impacts confidentiality by potentially exposing private data to unauthorized parties, affected organizations may face compliance risks if the vulnerability is exploited.
Users are strongly advised to upgrade to version 0.22.0 or later to remediate this issue and maintain compliance with relevant data protection standards.
Can you explain this vulnerability to me?
CVE-2026-39972 is a cache key collision vulnerability in the Mercure protocol's TopicSelectorStore component prior to version 0.22.0. The vulnerability arises because cache keys were created by concatenating the topic selector and topic strings with an underscore separator. Since both topic selectors and topics can contain underscores, different pairs can produce identical cache keys, causing collisions.
An attacker who can subscribe to the hub or publish updates with specially crafted topic names can exploit this collision to poison the match result cache. This can lead to private updates being delivered to unauthorized subscribers or blocking delivery to authorized ones, effectively bypassing authorization checks on private updates.
The vulnerability is fixed in version 0.22.0 by replacing the string-based cache keys with typed Go struct keys that prevent collisions, and by simplifying the caching mechanism.
How can this vulnerability impact me? :
This vulnerability can impact you by allowing attackers to bypass authorization checks on private updates in the Mercure protocol. Specifically, attackers can poison the cache to cause private data updates to be delivered to unauthorized subscribers or prevent authorized subscribers from receiving updates.
The impact includes unauthorized disclosure of private information (high confidentiality impact) and potential partial denial of service by blocking legitimate updates (low availability impact).
Because the attack can be performed remotely over the network with low complexity and low privileges required, it poses a significant security risk if the vulnerable versions are used.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability arises from cache key collisions in the Mercure hub's TopicSelectorStore component caused by crafted topic names containing underscores. Detection involves identifying if your Mercure hub version is prior to 0.22.0 and if it is susceptible to cache poisoning via topic selectors and topics with underscores.
Since the vulnerability is related to the internal cache key construction, direct detection on the network or system via commands is not explicitly described in the provided resources.
However, as a practical approach, you can check the Mercure version running on your system with commands like:
- mercure --version
- or check the version in your deployment manifests or package manager.
To detect potential exploitation attempts, monitor logs for suspicious topic names containing underscores that could cause cache key collisions or unexpected authorization bypasses.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade the Mercure hub to version 0.22.0 or later, where the vulnerability is fixed by replacing string-based cache keys with typed Go struct keys to prevent collisions.
If upgrading immediately is not possible, a recommended workaround is to disable the topic selector cache, which mitigates the vulnerability at the cost of reduced performance.
- Set `topic_selector_cache` to -1 in the Caddyfile configuration.
- Or, if using the library directly, pass a cache size of 0 to disable caching.
These steps prevent cache poisoning by avoiding the unsafe cache key construction that leads to collisions.