fulgur EUVD-2026-82425

Requires that the target application expose fulgur's HTML/CSS-to-PDF conversion to attacker-supplied input - i.e., a service that accepts untrusted HTML (typically a multi-tenant/network-facing conversion endpoint) and passes it to fulgur < 0.26.0 without first validating or constraining CSS dimensions. The trigger is a childless box resolving to a pathologically tall height (large height/vh) via any non-painting replaced element: an unresolved img src, a visibility:hidden image, an undecodable image format, or an empty <svg> (plus a trailing-sibling variant). No authentication or user interaction is required by the vendor vector (PR:N/UI:N), and the payload is only a few bytes. Limiting factors: the flaw is inert if fulgur is only fed trusted/first-party HTML, if untrusted CSS heights are validated/capped before rendering (the documented workaround), or if the crate is already upgraded to 0.26.0+. Versions < 0.19.0 are worse (unbounded pages / non-terminating loop, tracked as GHSA-j5cx-ph8g-95v3).

The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) reflects a pure availability impact and is internally consistent with the description: a few bytes of attacker-supplied HTML amplify into ~10,000 blank PDF pages, exhausting CPU and memory and denying service to the host and co-tenants. The AV:N choice is a deliberate library worst-case assessment - the advisory itself notes (per CVSS v3.1 User Guide §3.7) that fulgur performs no network I/O and that a concrete deployment splitting HTML ingestion from rendering could legitimately assess AV:L environmentally, so treat 7.5 as an upper bound rather than a universal value. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no evidence of active or automated exploitation; this is a real, low-complexity, unauthenticated DoS but is NOT a confirmed in-the-wild threat. Real priority is moderate: the flaw is trivially triggerable against any exposed multi-tenant fulgur conversion service, but overall risk is bounded by the crate's apparently niche deployment footprint and by the availability-only impact (no confidentiality or integrity loss). The most important limiting caveat is that exploitability hinges on whether the embedding application actually exposes fulgur to untrusted, network-supplied HTML - verify that per deployment.

An attacker submits a trivially small HTML payload (e.g. a childless box with a huge CSS height such as an <img> with an unresolved src, a visibility:hidden image, an undecodable image, or an empty <svg>) to a multi-tenant service that uses fulgur to render HTML/CSS to PDF. The non-painting replaced element bypasses the childless-collapse defense and amplifies into ~10,000 blank pages, driving CPU and memory exhaustion that denies service to the host and all co-tenants. No public exploit code is identified at time of analysis, though the technique is fully described in the advisory.