CVE-2026-108039 (GCVE-0-2026-108039)

Vulnerability from cvelistv5 – Published: 2026-10-09 10:22 – Updated: 2026-10-09 11:07
VLAI
Title
Apache CXF: Prevent unbounded XML document size in StaxUtils by adding default element and character limits
Summary
By default, StaxUtils placed no limit on the total number of elements or the total number of characters in an XML document. A very large request could therefore use a lot of memory and CPU during parsing, especially where CXF builds a DOM from the input (for example SAAJ or WS-Security), and could cause a denial of service when no request size limit was configured. Both limits now have defaults: the maximum element count is 100 × maxChildElements (5,000,000 by default), and the maximum document size is 256M characters. Applications that process larger documents can raise the limits with the org.apache.cxf.stax.maxElementCount and org.apache.cxf.stax.maxXMLCharacters properties. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.
Severity
No CVSS data available.
Assigner
apache CNA under the mitre root
CNA scorecard B 76/100 over 941 records in the last 180 days details
Impacted products
Vendor Product Version CPE status
Apache Software Foundation Apache CXF Affected: 4.2.0 , < 4.2.4 (semver)
Affected: 4.0.0 , < 4.1.9 (semver)
Affected: 0 , < 3.6.13 (semver)
guessed Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-09T11:07:55.068Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/09/14"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.cxf:cxf-core",
          "packageURL": "pkg:maven/org.apache.cxf/cxf-core",
          "product": "Apache CXF",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.2.4",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.1.9",
              "status": "affected",
              "version": "4.0.0",
              "versionType": "semver"
            },
            {
              "lessThan": "3.6.13",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Wanxin Yin (yaklang.io) \u003cyhellow123456@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "By default, StaxUtils placed no limit on the total number of elements or the total number of characters in an XML document. A very large request could therefore use a lot of memory and CPU during parsing, especially where CXF builds a DOM from the input (for example SAAJ or WS-Security), and could cause a denial of service when no request size limit was configured. Both limits now have defaults: the maximum element count is 100 \u00d7 maxChildElements (5,000,000 by default), and the maximum document size is 256M characters. Applications that process larger documents can raise the limits with the org.apache.cxf.stax.maxElementCount and org.apache.cxf.stax.maxXMLCharacters properties.\u003cbr\u003eUsers are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue."
            }
          ],
          "value": "By default, StaxUtils placed no limit on the total number of elements or the total number of characters in an XML document. A very large request could therefore use a lot of memory and CPU during parsing, especially where CXF builds a DOM from the input (for example SAAJ or WS-Security), and could cause a denial of service when no request size limit was configured. Both limits now have defaults: the maximum element count is 100 \u00d7 maxChildElements (5,000,000 by default), and the maximum document size is 256M characters. Applications that process larger documents can raise the limits with the org.apache.cxf.stax.maxElementCount and org.apache.cxf.stax.maxXMLCharacters properties.\nUsers are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "low"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-09T10:22:35.457Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread.html/ms2gbpof609o0v1bjlzb1rn7fwh61l1j"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache CXF: Prevent unbounded XML document size in StaxUtils by adding default element and character limits",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-108039",
    "datePublished": "2026-10-09T10:22:35.457Z",
    "dateReserved": "2026-10-09T09:27:04.033Z",
    "dateUpdated": "2026-10-09T11:07:55.068Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "collectionURL": "https://repo.maven.apache.org/maven2",
                "defaultStatus": "unaffected",
                "packageName": "org.apache.cxf:cxf-core",
                "packageURL": "pkg:maven/org.apache.cxf/cxf-core",
                "product": "Apache CXF",
                "vendor": "Apache Software Foundation",
                "versions": [
                  {
                    "lessThan": "4.2.4",
                    "status": "affected",
                    "version": "4.2.0",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.1.9",
                    "status": "affected",
                    "version": "4.0.0",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "3.6.13",
                    "status": "affected",
                    "version": "0",
                    "versionType": "semver"
                  }
                ]
              }
            ],
            "source": "security@apache.org"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "By default, StaxUtils placed no limit on the total number of elements or the total number of characters in an XML document. A very large request could therefore use a lot of memory and CPU during parsing, especially where CXF builds a DOM from the input (for example SAAJ or WS-Security), and could cause a denial of service when no request size limit was configured. Both limits now have defaults: the maximum element count is 100 \u00d7 maxChildElements (5,000,000 by default), and the maximum document size is 256M characters. Applications that process larger documents can raise the limits with the org.apache.cxf.stax.maxElementCount and org.apache.cxf.stax.maxXMLCharacters properties.\nUsers are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue."
          }
        ],
        "id": "CVE-2026-108039",
        "lastModified": "2026-10-09T16:33:39.007",
        "metrics": {},
        "published": "2026-10-09T11:17:02.387",
        "references": [
          {
            "source": "security@apache.org",
            "url": "https://lists.apache.org/thread.html/ms2gbpof609o0v1bjlzb1rn7fwh61l1j"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "url": "http://www.openwall.com/lists/oss-security/2026/10/09/14"
          }
        ],
        "sourceIdentifier": "security@apache.org",
        "vulnStatus": "Undergoing Analysis"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Important",
      "current_release_date": "2026-10-09T16:45:16+00:00",
      "cve": "CVE-2026-108039",
      "id": "CVE-2026-108039",
      "initial_release_date": "2026-10-09T10:22:35.457000+00:00",
      "product_status:known_affected": "11",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "org.apache.cxf/cxf-core: Apache CXF: Denial of Service via unrestricted XML parsing",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-108039.json",
      "version": "3"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…