Description

Apache CXF allows to control the maximum attachment size via the "attachment-max-size". Prior to Apache CXF 4.2.3 and 4.1.8 and 3.6.12, there was no default placed on this size, meaning that a denial of service attack is possible if the user doesn't explicitly set the limit. Users should update to Apache CXF 4.2.3 or 4.1.8 or 3.6.12 which fixes this problem by imposing a default attachment size limit of 50mb.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-06T11:16:30.003Z",
  "pubdate": "2026-08-06T11:16:30.003Z",
  "executiveSummary": "Apache CXF is susceptible to a denial of service vulnerability arising from the absence of a default restriction on the \"attachment-max-size\" configuration parameter prior to patched releases.\nThis vulnerability impacts Apache CXF versions prior to 4.2.3, 4.1.8, and 3.6.12.\nThe primary risk implication is resource exhaustion, specifically memory and storage depletion on the host server, which can render the application unavailable to legitimate users.\nAn unauthenticated remote attacker can exploit this weakness by transmitting excessively large file attachments within requests processed by the framework, provided the administrator failed to explicitly define a custom attachment size limit.\nNo complex exploitation requirements or prior privileges are necessary beyond network connectivity to the vulnerable Apache CXF endpoint and the ability to submit multipart or attachment-bearing payloads.",
  "technicalDetails": "The root cause of this vulnerability is the historical lack of a secure-by-default hardcoded upper bound for the \"attachment-max-size\" property within Apache CXF.\nIn affected versions prior to Apache CXF 4.2.3, 4.1.8, and 3.6.12, if an application developer or system administrator omitted the explicit configuration of \"attachment-max-size\", the framework imposed no internal constraints on incoming attachment payloads.\nThe vulnerable component is the attachment processing subsystem responsible for parsing multipart messages and streaming or buffering incoming request data.\nThe attack flow proceeds as follows: an attacker crafts an HTTP request containing a maliciously oversized file attachment or an infinite/extremely large stream of binary data. Because the application lacks a default size threshold, the Apache CXF framework attempts to read, parse, and process the entire incoming payload into memory or temporary disk storage.\nAs the payload is processed, the target server rapidly exhausts available heap memory, system RAM, or disk space, leading to severe resource degradation or an application crash resulting in a denial of service.\nThe exploitation method relies entirely on application layer resource exhaustion via oversized inputs, requiring network exposure to the vulnerable web service endpoints.\nNo authentication or specific privileges are required to initiate the attack, as public-facing endpoints typically accept incoming client requests and attachments by design.\nThe post-exploitation impact is strictly limited to availability disruption, preventing normal service operations until the affected Java process or server is restarted and the offending traffic is blocked."
}