GHSA-RJ39-56XF-V987

Vulnerability from github – Published: 2026-08-21 12:30 – Updated: 2026-08-21 18:34
VLAI
Details

An application using Micrometer Tracing with W3C baggage propagation in the Brave bridge is vulnerable to denial of service (DoS) due to unbounded object allocation when extracting incoming baggage headers.

Specifically, an application is vulnerable when all the following are true:

  • The application uses a vulnerable version of io.micrometer:micrometer-tracing-bridge-brave.
  • W3C propagation is active (either configured manually or active by default, such as in Spring Boot 3.x+).
  • Baggage propagation is enabled (which is the default in Spring Boot 3.x+) and a baggage manager (such as BraveBaggageManager) is configured to handle baggage fields.
  • The application processes requests or messages from untrusted sources with baggage headers which it normally should not, see:  https://www.w3.org/TR/trace-context/#security-considerations .
  • Network components including the (HTTP) server that receives the request do not limit the header size or the limit is high enough to cause issues.

The last two points are very important: normally this should not affect applications because they should not receive untrusted and unlimited input for baggage.

  • The application processes requests or messages from untrusted sources with baggage headers.

When extracting baggage from the W3C baggage header, incoming entries are parsed without enforcing limits on the number of entries or header size as mandated by the W3C Baggage specification. An attacker can send requests or messages with artificially inflated baggage headers containing many key-value pairs, causing unconditional BaggageField allocations per entry. This leads to garbage collection pressure, high CPU usage, and potential application crash via OutOfMemoryError.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-59323"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-21T10:16:38Z",
    "severity": "MODERATE"
  },
  "details": "An application using Micrometer Tracing with W3C baggage propagation in the Brave bridge is vulnerable to denial of service (DoS) due to unbounded object allocation when extracting incoming\u00a0baggage\u00a0headers.\n\n\n\nSpecifically, an application is vulnerable when all the following are true:\n\n  *  The application uses a vulnerable version of\u00a0io.micrometer:micrometer-tracing-bridge-brave.\n  *  W3C propagation is active (either configured manually or active by default, such as in Spring Boot 3.x+).\n  *  Baggage propagation is enabled (which is the default in Spring Boot 3.x+) and a baggage manager (such as\u00a0BraveBaggageManager) is configured to handle baggage fields.\n  *  The application processes requests or messages from untrusted sources with\u00a0baggage\u00a0headers which it normally should not, see:\u00a0 https://www.w3.org/TR/trace-context/#security-considerations .\n  *  Network components including the (HTTP) server that receives the request do not limit the header size or the limit is high enough to cause issues.\n\n\n\n\nThe last two points are very important: normally this should not affect applications because they should not receive untrusted and unlimited input for baggage.\n\n  *  The application processes requests or messages from untrusted sources with\u00a0baggage\u00a0headers.\n\n\n\n\nWhen extracting baggage from the W3C\u00a0baggage\u00a0header, incoming entries are parsed without enforcing limits on the number of entries or header size as mandated by the W3C Baggage specification. An attacker can send requests or messages with artificially inflated\u00a0baggage\u00a0headers containing many key-value pairs, causing unconditional\u00a0BaggageField\u00a0allocations per entry. This leads to garbage collection pressure, high CPU usage, and potential application crash via\u00a0OutOfMemoryError.",
  "id": "GHSA-rj39-56xf-v987",
  "modified": "2026-08-21T18:34:56Z",
  "published": "2026-08-21T12:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59323"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-59323"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.