GHSA-J497-X9HR-X34X
Vulnerability from github – Published: 2026-09-17 17:04 – Updated: 2026-09-17 17:04Summary
A data integrity and protocol corruption vulnerability exists in the AMQP client's property serialization logic. When encoding AMQP short string (shortstr) fields—such as identifiers, routing strings, and content metadata—the length of the string is explicitly cast to a fixed-size 8-bit unsigned integer (uint8).
If an application provides a property string exceeding 255 bytes, the length counter silently wraps around (e.g., a length of 300 wraps to 44). As a result, the parser writes only a truncated portion of the string into the outgoing connection buffer without returning an error. This leads to silent data corruption, broken RPC routing, and unpredictable broker-side state behavior.
Vulnerability Details
Mechanism
The vulnerability resides in the wire-level serialization logic for application publishing properties:
// write.go:246
length := uint8(len(b)) // wraps silently when len(b) > 255 (e.g., 300 -> 44)
Because Go allows silent integer truncation during explicit type casting, lengths larger than $2^8 - 1$ lose their most significant bits. The underlying stream writer reads length to determine how many bytes to pull from the buffer. Because no error or boundary check accompanies this truncation, the application believes the full payload was transmitted successfully.
Affected Properties
This truncation behavior affects every standard AMQP field serialized as a shortstr:
* CorrelationId
* ReplyTo
* MessageId
* Expiration
* UserId
* AppId
* ContentType
* ContentEncoding
* Type
Impact
The critical consequence is silent protocol desynchronization at the application layer. The underlying TCP stream remains framed properly (because the shortened length matches the bytes written), but the business logic is corrupted. Distributed transactions, request-reply correlations, and tracing headers are truncated, causing downstream systems to drop messages or route them to incorrect consumers.
Attack Vector
An attacker who can influence metadata fields processed by an upstream application (such as a user-supplied tracking ID or a long content-type header) can exploit this to break system components:
- Targeting RPC Routing: A user passes a malicious or overly long
CorrelationIdof 300 bytes through an application endpoint. - Silent Truncation: The library wraps the length value to 44, transmitting only the first 44 bytes to the rabbitMQ broker.
- Broken Correlation: When the service processes the request and responds, the replying consumer attempts to route the message using the full 300-byte identifier. Because the broker only recognizes the truncated 44-byte ID, the reply loop breaks silently, leading to hanging processes or data leaks across transaction boundaries.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rabbitmq/amqp091-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77408"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T17:04:15Z",
"nvd_published_at": "2026-09-16T15:17:49Z",
"severity": "CRITICAL"
},
"details": "## Summary\nA data integrity and protocol corruption vulnerability exists in the AMQP client\u0027s property serialization logic. When encoding AMQP short string (`shortstr`) fields\u2014such as identifiers, routing strings, and content metadata\u2014the length of the string is explicitly cast to a fixed-size 8-bit unsigned integer (`uint8`). \n\nIf an application provides a property string exceeding 255 bytes, the length counter silently wraps around (e.g., a length of 300 wraps to 44). As a result, the parser writes only a truncated portion of the string into the outgoing connection buffer without returning an error. This leads to silent data corruption, broken RPC routing, and unpredictable broker-side state behavior.\n\n---\n\n## Vulnerability Details\n\n### Mechanism\nThe vulnerability resides in the wire-level serialization logic for application publishing properties:\n\n```go\n// write.go:246\nlength := uint8(len(b)) // wraps silently when len(b) \u003e 255 (e.g., 300 -\u003e 44)\n```\n\nBecause Go allows silent integer truncation during explicit type casting, lengths larger than $2^8 - 1$ lose their most significant bits. The underlying stream writer reads `length` to determine how many bytes to pull from the buffer. Because no error or boundary check accompanies this truncation, the application believes the full payload was transmitted successfully.\n\n### Affected Properties\nThis truncation behavior affects every standard AMQP field serialized as a `shortstr`:\n* `CorrelationId`\n* `ReplyTo`\n* `MessageId`\n* `Expiration`\n* `UserId`\n* `AppId`\n* `ContentType`\n* `ContentEncoding`\n* `Type`\n\n### Impact\nThe critical consequence is **silent protocol desynchronization at the application layer**. The underlying TCP stream remains framed properly (because the shortened length matches the bytes written), but the business logic is corrupted. Distributed transactions, request-reply correlations, and tracing headers are truncated, causing downstream systems to drop messages or route them to incorrect consumers.\n\n---\n\n## Attack Vector\nAn attacker who can influence metadata fields processed by an upstream application (such as a user-supplied tracking ID or a long content-type header) can exploit this to break system components:\n\n1. **Targeting RPC Routing:** A user passes a malicious or overly long `CorrelationId` of 300 bytes through an application endpoint.\n2. **Silent Truncation:** The library wraps the length value to 44, transmitting only the first 44 bytes to the rabbitMQ broker.\n3. **Broken Correlation:** When the service processes the request and responds, the replying consumer attempts to route the message using the full 300-byte identifier. Because the broker only recognizes the truncated 44-byte ID, the reply loop breaks silently, leading to hanging processes or data leaks across transaction boundaries.",
"id": "GHSA-j497-x9hr-x34x",
"modified": "2026-09-17T17:04:15Z",
"published": "2026-09-17T17:04:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-j497-x9hr-x34x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77408"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/amqp091-go/pull/354"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/amqp091-go/commit/6959423aa2784a1971e399175dfb2065dea0f3b0"
},
{
"type": "PACKAGE",
"url": "https://github.com/rabbitmq/amqp091-go"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/amqp091-go/releases/tag/v1.13.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:H/SC:L/SI:H/SA:L",
"type": "CVSS_V4"
}
],
"summary": "RabbitMQ amqp091-go: Silent Data Truncation and State Corruption via Shortstr Integer Overflow"
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.