{"document":{"acknowledgments":[{"urls":["https://kb.cert.org/vuls/id/128947#acknowledgements"]}],"category":"CERT/CC Vulnerability Note","csaf_version":"2.0","notes":[{"category":"summary","text":"### Overview\r\n\r\nvsomeip, COVESA's open source implementation of the SOME/IP automotive communication middleware, contained a memory allocation vulnerability present in versions 3.7.3 and below. A vsomeip reliable (TCP) SOME/IP endpoint grows its receive buffer to an attacker-declared message size before validating that the declared bytes have actually been received, allowing a remote, unauthenticated peer to exhaust host memory and deny service. The issue was reported publicly as COVESA/vsomeip issue #1009 and fixed in release 3.7.4 (2026-07-06).\r\n\r\n### Description\r\n**CVE-2026-91141**\r\nvsomeip is a middleware implementation of the Scalable service-Oriented MiddlewarE over IP (SOME/IP) protocol, widely used for service-oriented communication between electronic control units (ECUs) in automotive and other embedded environments. A SOME/IP message begins with a 16-byte header that includes a 32-bit length field declaring the size of the message that follows.\r\n\r\nA vulnerability was discovered in the handling of this length field on reliable (TCP) endpoints. When a message arrives, vsomeip grows its receive buffer to the size declared in the length field in order to read the incoming message, before confirming that those bytes have actually been received. In the default configuration, no size limit is applied to reliable endpoints, so a peer can declare a message size of up to roughly 4 GB and cause the receiver to allocate that memory. Because a freshly accepted connection reaches this path on its first message, no valid service, credentials, or SOME/IP authentication are required to trigger the allocation. The client endpoint contains the same behavior, where a malicious or compromised server can attack a connecting client.\r\n\r\nDeployments that explicitly configure a reliable message-size limit are not affected.\r\n\r\nThis issue is publicly known. It was reported as COVESA/vsomeip issue #1009 (opened 2026-02-26) and fixed in release 3.7.4 (released 2026-07-06).\r\n\r\n### Impact\r\n\r\nA remote, unauthenticated peer can force the host to allocate an attacker-chosen amount of memory, up to approximately 4 GB per connection, by sending a single short message on a normal TCP connection to any reachable reliable SOME/IP endpoint in the default configuration. On a memory-constrained node this can terminate the service outright: a service limited to 1.5 GB was OOM-killed by a single 16-byte message claiming a 3 GB payload. On a memory-rich host, the allocation for a single connection is released when the connection closes, so sustained memory exhaustion and denial of service follow from holding or repeating connections, each forcing its own allocation.\r\n\r\n### Solution\r\n\r\n**Upgrade to vsomeip 3.7.4 or later.** This issue is fixed in release 3.7.4 (released 2026-07-06). The fix replaces the unlimited compile-time default (`MESSAGE_SIZE_UNLIMITED`) with a bounded `DEFAULT_MAX_MESSAGE_SIZE` of 10 MiB, so reliable endpoints reject an oversized declared length before growing the receive buffer even when no limit is explicitly configured. The release also adds a regression test for an oversized length field. The issue and fix are tracked publicly in COVESA/vsomeip issue #1009.\r\n\r\nDeployments that cannot upgrade immediately should apply the following mitigations.\r\n\r\n* Deployments can explicitly set `max-payload-size-reliable` (or the equivalent per-service reliable message-size limit) to a value appropriate for the service. Endpoints with such a limit configured reject oversized declared lengths and are not affected by this issue. This is the most effective mitigation available without upgrading.\r\n\r\n* Because the vulnerability is reachable by any host that can open a TCP connection to a reliable SOME/IP endpoint, exposure should be minimized through network segmentation. Reliable endpoints should be confined to trusted, isolated in-vehicle or lab networks, and firewall or access-control rules should limit connectivity to known, authorized peers. SOME/IP endpoints should never be exposed to untrusted or external networks.\r\n\r\n* Operators should monitor for anomalous memory growth on services offering reliable endpoints and for unexpected or repeated inbound TCP connections to SOME/IP ports, which may indicate attempts to exploit this vulnerability.\r\n\r\n### Acknowledgements\r\n\r\nThank you to the  Jaafer Rahmani for reporting this vulnerability. This document was written by Alexander Curtis.","title":"Summary"},{"category":"legal_disclaimer","text":"THIS DOCUMENT IS PROVIDED ON AN 'AS IS' BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. ","title":"Legal Disclaimer"},{"category":"other","text":"CERT/CC Vulnerability Note is a limited advisory. It primarily identifies vendors impacted by the advisory and not specific products. We only support \"known_affected\" and \"known_not_affected\" status. Please consult the vendor's statements and advisory URL if provided by the vendor for more details ","title":"Limitations of Advisory"}],"publisher":{"category":"coordinator","contact_details":"Email: cert@cert.org, Phone: +1412 268 5800","issuing_authority":"CERT/CC under DHS/CISA https://www.cisa.gov/cybersecurity also see https://kb.cert.org/ ","name":"CERT/CC","namespace":"https://kb.cert.org/"},"references":[{"url":"https://certcc.github.io/certcc_disclosure_policy","summary":"CERT/CC vulnerability disclosure policy"},{"summary":"CERT/CC document released","category":"self","url":"https://kb.cert.org/vuls/id/128947"},{"url":"https://github.com/COVESA/vsomeip/issues/1009","summary":"https://github.com/COVESA/vsomeip/issues/1009"},{"url":"https://github.com/COVESA/vsomeip/commit/5c669a1cd7f073647cc3d588f760019a5bd3a3df","summary":"https://github.com/COVESA/vsomeip/commit/5c669a1cd7f073647cc3d588f760019a5bd3a3df"},{"url":"https://github.com/COVESA/vsomeip/releases/tag/3.7.4","summary":"https://github.com/COVESA/vsomeip/releases/tag/3.7.4"}],"title":"COVESA vsomeip excessive memory allocation in reliable (TCP) endpoint buffer handling","tracking":{"current_release_date":"2026-10-26T19:11:08+00:00","generator":{"engine":{"name":"VINCE","version":"3.0.51"}},"id":"VU#128947","initial_release_date":"2026-10-26 19:07:02.327124+00:00","revision_history":[{"date":"2026-10-26T19:11:08+00:00","number":"1.20261026191108.2","summary":"Released on 2026-10-26T19:11:08+00:00"}],"status":"final","version":"1.20261026191108.2"}},"vulnerabilities":[{"title":"A vulnerability in the default configuration of vsomeip allows a remote, unauthenticated attacker to trigger massive memory allocations by sending a small TCP packet with a large, attacker-declared SOME/IP length field.","notes":[{"category":"summary","text":"A vulnerability in the default configuration of vsomeip allows a remote, unauthenticated attacker to trigger massive memory allocations by sending a small TCP packet with a large, attacker-declared SOME/IP length field. Because the library lacks a default size limit for reliable (TCP) endpoints, it attempts to pre-allocate up to 4 GB of memory before validating the actual received data. This can lead to immediate service termination via OOM-kill on memory-constrained systems or total host memory exhaustion through repeated connections."}],"cve":"CVE-2026-91141","ids":[{"system_name":"CERT/CC V Identifier ","text":"VU#128947"}]}],"product_tree":{"branches":[]}}