CoreBunch Instatic EUVD-2026-55219

Exploitation requires that the target application runs CoreBunch/Instatic version 0.0.14 or earlier and that the GET /_instatic/hole/<nodeId> server island endpoint is reachable by unauthenticated network requests - which is the expected deployment mode of this feature. No non-default configuration, special privileges, or authentication is required from the attacker's perspective. Exploitation is further conditioned on the attacker's poisoning request being processed before the targeted nodeId cache entry is populated by a legitimate request, and the poisoned cache entry persisting until victim users load the affected island. The CVSS UI:R metric reflects that content-level impact is only realized when subsequent users visit pages embedding the poisoned server island, not upon the attacker's initial request. Exploitation is limited to: (1) applications actually using Instatic's server island feature, (2) instances where the /_instatic/hole/ path is not protected by additional access controls, and (3) cache entries that have not been evicted between the poisoning request and the victim's page load.

The CVSS 3.1 score of 6.1 (Medium) with vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N accurately reflects the attack profile: no authentication or special privileges are required, the network vector is fully remote, and the Changed Scope captures the multi-victim nature of cache poisoning. UI:R indicates that impact is only realized when other users subsequently load the affected server island, which slightly reduces urgency compared to a direct-impact vulnerability. No EPSS data was provided for this CVE, and there is no CISA KEV listing, meaning active exploitation has not been confirmed by any authoritative body. No public proof-of-concept code has been identified in the provided intelligence. The primary real-world risk limiter is deployment footprint: at version 0.0.14, Instatic appears to be an early-stage or experimental library with minimal production adoption, substantially constraining the number of exploitable targets. For the subset of environments that do use Instatic and expose the /_instatic/hole/ endpoint publicly, risk is material - a single unauthenticated request can degrade content integrity for all application users until the cache is cleared.

An unauthenticated attacker sends a crafted HTTP GET request to /_instatic/hole/<targetNodeId>?u=https://attacker-controlled.example/malicious-route, causing the server to render a fragment using the attacker's route template and store the result in the shared cache under targetNodeId. All legitimate users who subsequently load any page containing that server island receive the attacker-injected fragment content - such as malicious JavaScript, misleading UI elements, or exfiltration code - without any further attacker interaction. No public proof-of-concept has been confirmed, but the straightforward parameter manipulation requires no specialized tooling.