Enterprise Build of Quarkus EUVD-2026-51135

Exploitation requires that the target Quarkus REST application expose an endpoint that accepts multipart MIME input (multipart/form-data or similar), since the flaw lies in accumulating multipart part-header bytes - an application with no multipart endpoints is not reachable through this vector. Given the CVSS vector (AV:N/AC:L/PR:N/UI:N), no authentication, no user interaction, and no non-default framework configuration are needed once such an endpoint exists. The primary limiting factor is deployment: the affected versions (3.27.1-3.27.4.SP2 or 3.33.1-3.33.2.SP2 of IBM Enterprise Build of Quarkus) must be running and the multipart endpoint must be network-reachable by the attacker; an upstream proxy that enforces body/header size limits also constrains or neutralizes the attack.

The signals are internally consistent for a genuine but availability-only issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5 HIGH) reflects a network-reachable, low-complexity, unauthenticated attack with high availability impact and no confidentiality or integrity impact - a classic resource-exhaustion DoS. No EPSS score, KEV listing, or POC was provided in the intelligence, so exploitation probability cannot be quantified and there is no evidence of active exploitation; this is not a confirmed in-the-wild threat. The practical risk is real for internet-facing services that expose multipart endpoints (file uploads, form posts) without an upstream body-size limit, but it is bounded: the attacker gains only disruption, not code execution or data access. Priority should be driven by exposure - an unauthenticated multipart endpoint reachable from untrusted networks warrants prompt patching, whereas internal-only or gateway-size-limited deployments are lower urgency. EPSS and KEV data are MISSING and should be checked before final triage.

An attacker locates an internet-facing endpoint of a Quarkus REST application that accepts multipart/form-data (such as a file-upload or form handler) and sends a crafted multipart request in which a MIME part-header field is made extremely large or never terminated. The server buffers the part-header bytes without limit, driving heap consumption up until the JVM exhausts memory and the service crashes or becomes unresponsive, denying service to legitimate users. No authentication, user interaction, or special timing is required; no public POC is currently identified, but the low complexity makes independent exploit development straightforward.