Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-reachable endpoint, no complexity or interaction required; pure availability impact with no confidentiality or integrity effect; PR:N assumes unauthenticated endpoints, which operators should verify.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Unbounded attachment ingestion in Apache CXF enables remote denial-of-service against any endpoint that processes multipart messages. Versions prior to 4.2.3, 4.1.8, and 3.6.12 imposed no default ceiling on the 'attachment-max-size' parameter, allowing attackers to exhaust server memory or processing capacity by submitting arbitrarily large attachments. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog, but the low attack complexity makes this a realistic threat for internet-exposed CXF deployments.
Technical ContextAI
Apache CXF (cpe:2.3:a:apache_software_foundation:apache_cxf:*:*:*:*:*:*:*:*) is a widely-adopted open-source Java services framework used to build SOAP and REST APIs. Its multipart/attachment handling exposes a configurable parameter 'attachment-max-size' to cap inbound attachment size; however, prior to the fixed releases, this parameter carried no default value. CWE-770 (Allocation of Resources Without Limits or Throttling) precisely describes the root cause: the runtime allocates heap memory proportional to the supplied attachment without enforcing an upper bound, making resource exhaustion trivially achievable. The fix in 4.2.3/4.1.8/3.6.12 imposes a 50 MB default, which operators can still override if a larger limit is intentionally required.
RemediationAI
Upgrade to Apache CXF 4.2.3, 4.1.8, or 3.6.12 as appropriate for the deployed branch. These releases introduce a 50 MB default attachment size limit, providing immediate protection without configuration changes. Full advisory details are at https://lists.apache.org/thread/h2bjqm6g58z0j6893qzh728kdtk1byfy. If an immediate upgrade is not possible, operators should explicitly set the 'attachment-max-size' property to a business-appropriate value (e.g., 10mb or 50mb) in their CXF endpoint or bus configuration - this workaround is available in all affected versions and eliminates the vulnerability without requiring a code change. Additionally, placing a web application firewall or API gateway upstream that enforces a request-body size limit (via 'client_max_body_size' in nginx or equivalent) provides defense-in-depth and limits exposure even before the CXF layer processes the payload.
More in Apache Cxf
View allArbitrary certificate disclosure in Apache CXF's XKMS server lets remote attackers abuse an LDAP injection flaw (CWE-90)
Unsafe deserialization in Apache CXF's JMS transport allows any party able to publish to the service's JMS destination t
Remote code execution in Apache CXF (versions before 3.6.11, 4.0.0-4.1.5, and 4.2.0) arises because the fix for CVE-2025
XML External Entity injection in Apache CXF's WSDL import processing allows attackers who can influence imported WSDL or
Denial of service persists in Apache CXF due to an incomplete remediation of CVE-2026-50645, allowing unauthenticated ne
Authorization scope escalation in Apache CXF's OAuth2 Dynamic Client Registration endpoint allows any registering client
XML External Entity injection in Apache CXF's WS-Transfer module exposes SOAP endpoints to server-side file read and int
Double-spending of OAuth2 authorization codes in Apache CXF's JCacheCodeDataProvider enables issuance of multiple valid
Apache CXF's JwtRequestCodeFilter blindly copies all claims from a validly-signed JWT request object into the OAuth2 aut
Authentication bypass in Apache CXF's OIDC relying-party implementation allows network-accessible attackers to forge sel
Apache CXF's DefaultEncryptingCodeDataProvider allows captured OAuth 2.0 authorization codes to be redeemed an unlimited
Token revocation bypass in Apache CXF's DefaultEncryptingOAuthDataProvider allows revoked OAuth access and refresh token
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-53851
GHSA-h9mr-9vh5-65gw