vsomeip SOME/IP flaw enables memory exhaustion DoS
Free public brief. Slack alerts on the vendors you run come with the paid plans, and a new account gets three days of them, no card.
A memory allocation bug in vsomeip's reliable SOME/IP endpoints lets unauthenticated remote peers force up to ~4GB allocations, causing denial of service; fixed in 3.7.4.
CERT/CC published VU#128947 describing CVE-2026-91141, a memory allocation vulnerability in vsomeip, COVESA's open-source implementation of the SOME/IP automotive middleware used for service-oriented communication between ECUs. Versions 3.7.3 and earlier fail to validate that a declared message length in the SOME/IP header has actually been received before growing the receive buffer to match that declared size. On reliable (TCP) endpoints with no explicit size limit configured (the default), an attacker can declare a message size of up to roughly 4GB, forcing the receiver to allocate that much memory on the very first message of a freshly accepted connection—no authentication, credentials, or valid service interaction required. The same code path affects client endpoints, meaning a malicious or compromised server can similarly attack a connecting client.
The impact ranges from immediate service termination on memory-constrained nodes (a service capped at 1.5GB was OOM-killed by a single 16-byte message claiming a 3GB payload) to sustained denial of service on memory-rich hosts via repeated or held connections, each forcing its own allocation. The vulnerability is publicly tracked as COVESA/vsomeip issue #1009, reported by Jaafer Rahmani, and was fixed in release 3.7.4 (2026-07-06), which introduces a bounded default maximum message size of 10MiB in place of the previous unlimited default.
Defenders should upgrade to vsomeip 3.7.4 or later. Where immediate upgrade isn't possible, explicitly configure max-payload-size-reliable (or equivalent per-service limits) to reject oversized declared lengths, restrict reliable SOME/IP endpoints to trusted, segmented in-vehicle or lab networks via firewall/access-control rules, and never expose SOME/IP endpoints to untrusted or external networks. Monitor for anomalous memory growth and unexpected or repeated inbound TCP connections to SOME/IP ports as potential exploitation indicators. There is no indication of in-the-wild exploitation; this is a publicly disclosed and patched vulnerability.
Mentioned in this report
Source reporting: https://kb.cert.org/vuls/id/128947
What this brief leaves out
This page is the free tier: the write-up, the severity, the names. In the app the same report carries live profiles of the CVEs it names. The paid plans add the security research and news reporting the free tier leaves out.
It sits in a corpus of 14,247 reports from 143 sources, 594 of them written in the last seven days, and it grows through the day.
A new account starts with three days of all of it, no card, then keeps the government and CERT reporting free. Slack alerts are a paid-plan feature: name the vendors you run and Slack hears about the reports that touch them — about forty a week that are yours, not the four hundred that are not.
Create a free account What it costs