TL;DR: Upgrade COVESA vsomeip to 3.7.4 or later. In 3.7.3 and earlier, a reliable (TCP) SOME/IP endpoint allocates memory to match an attacker-declared length before verifying the bytes exist — up to ~4 GB from a 16-byte message, unauthenticated, and in both directions (a malicious server can hit a client too). If you can't upgrade now, set an explicit reliable message-size limit, keep SOME/IP off untrusted networks, and monitor for anomalous memory growth. Tracked as CERT/CC VU#128947; severity HIGH.
SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the service-oriented communication protocol that ties together electronic control units (ECUs) and other components inside modern vehicles and embedded systems. vsomeip is COVESA's widely used open-source implementation of it. CVE-2026-91141 is a remote, unauthenticated denial-of-service flaw in vsomeip 3.7.3 and earlier, coordinated by the CERT Coordination Center as VU#128947 and fixed in vsomeip 3.7.4 on 6 July 2026. Because the vulnerable path sits in the transport layer — below any application running on top — secure coding in your service does not protect you if the underlying vsomeip build is affected.
What the flaw is
Every SOME/IP message begins with a fixed 16-byte header, and that header declares how long the message is going to be. In vsomeip 3.7.3 and earlier, a reliable endpoint — one running over TCP — reads that declared length and grows its receive buffer to match before confirming that the declared number of bytes have actually been received. In the default configuration, reliable endpoints have no message-size limit at all, so there is nothing to reject an absurd value. An attacker can declare a length of up to roughly 4 GB and the receiver will dutifully try to allocate it.
Why a 16-byte message is dangerous
The asymmetry is the whole problem. The attacker sends a tiny, cheap header; the victim does the expensive work of reserving gigabytes of memory to hold a payload that will never arrive. Worse, a newly accepted connection reaches this code path on its very first message — so no valid service, credentials, or SOME/IP authentication is required. And because the client side of vsomeip behaves the same way, the risk is bidirectional: a malicious or compromised server can attack a client that merely connects to it, not only the other way around.
| Property | Detail |
|---|---|
| Identifier | CVE-2026-91141 · CERT/CC VU#128947 |
| Component | COVESA vsomeip (SOME/IP middleware), reliable/TCP endpoints |
| Affected | vsomeip 3.7.3 and earlier, default configuration |
| Fixed in | vsomeip 3.7.4 (6 July 2026) |
| Class | Uncontrolled memory allocation → denial of service |
| Auth required | None (unauthenticated, first message on a new connection) |
| MITRE ATT&CK | T1499 Endpoint Denial of Service · T1499.004 |
| Severity | HIGH |
We are deliberately keeping this high level — there is no proof-of-concept or packet recipe here. Our job is to help defenders close the gap, not hand attackers a template.
Who is affected
Any deployment running vsomeip 3.7.3 or earlier with a reliable (TCP) endpoint and no explicit message-size limit. Two points decide your exposure:
- Configuration matters. Deployments that already set an explicit reliable maximum payload size are not affected — the limit rejects the oversized declared length before any buffer growth. The danger is the common default, which imposes no limit.
- The surface is wide and slow to patch. SOME/IP underpins service-oriented communication across automotive ECUs and other embedded systems, and automotive supply chains patch slowly. A low-complexity, unauthenticated DoS against safety-adjacent components is exactly the kind of exposure that lingers for years after a fix ships.
Real-world impact
The impact is remote, unauthenticated denial of service, and a single short message can cause an allocation of up to roughly 4 GB per connection. On memory-constrained systems that is enough to terminate the service outright: the CERT/CC advisory notes a service limited to 1.5 GB being OOM-killed by a 16-byte message that claimed a 3 GB payload. On larger hosts the allocation is released when the connection closes, so sustained exhaustion there requires an attacker to hold connections open or re-open them repeatedly — still cheap, still unauthenticated. For in-vehicle and embedded deployments, where memory is tight and availability is a safety property, the constrained-system case is the one that bites.
What to do now
- Upgrade vsomeip to 3.7.4 or later. The fix replaces the unlimited compile-time default with a bounded default maximum message size of 10 MiB and rejects oversized declared lengths before growing the receive buffer, even when no explicit limit is configured. It also adds a regression test for oversized length fields.
- If you can't upgrade immediately, set an explicit limit. Configure the reliable maximum payload size (or the per-service reliable message-size limit) to a bounded value appropriate for the service. Deployments that do this are not affected even on older builds.
- Keep SOME/IP off untrusted networks. Restrict reliable endpoints to trusted, isolated in-vehicle or lab networks, and enforce firewall or access-control rules that permit only known, authorized peers. SOME/IP endpoints should never be reachable from untrusted or external networks.
- Monitor for the symptom. Watch services that offer reliable endpoints for anomalous memory growth, and for unexpected or repeated inbound TCP connections to SOME/IP ports.
- Inventory where vsomeip actually runs. Including third-party components and appliances that bundle it — you cannot patch a service you have forgotten is there.
How to confirm your real exposure
The hard part of an embedded-middleware CVE is rarely the patch — it is knowing where a vulnerable, reachable endpoint actually exists. A SOME/IP service that was only ever meant to live on an isolated in-vehicle or lab segment, but drifted onto a routable network, is precisely the kind of forgotten exposure that turns a "trusted-network-only" assumption into an open door.
This is where external testing earns its keep. AssurePort's network and host penetration testing discovers exposed services, fingerprints them, and correlates versions against known-exploited vulnerabilities — so a reachable SOME/IP endpoint on a network it was never supposed to touch gets surfaced against your real external footprint, not an idealised diagram. It is the same argument we make for cadence over a once-a-year snapshot: the dangerous window is the stretch between a public advisory and your patch, and only continuous testing covers it. We walk through that response pattern in zero-day response: the first 24 hours.
Sources & further reading: The CERT/CC advisory VU#128947 and the NVD entry for CVE-2026-91141 are the authority on affected and fixed versions. The COVESA vsomeip project ships the 3.7.4 fix. This advisory summarises public reporting and contains no exploit code.
Frequently asked questions
What is CVE-2026-91141?
A remote, unauthenticated denial-of-service flaw in COVESA vsomeip (the open-source SOME/IP automotive middleware) 3.7.3 and earlier. A reliable TCP endpoint grows its receive buffer to an attacker-declared length — up to ~4 GB — before confirming the bytes arrived. Tracked as CERT/CC VU#128947; fixed in vsomeip 3.7.4 on 6 July 2026.
Which versions are affected and fixed?
vsomeip 3.7.3 and earlier are affected in the default (no limit) configuration. The fix is 3.7.4, which sets a bounded 10 MiB default and rejects oversized declared lengths. Builds that already configure an explicit reliable message-size limit are not affected.
Does the attacker need credentials?
No. The vulnerable path is reached on a connection's first message, so no service, credentials, or SOME/IP authentication is needed. It is also bidirectional — a malicious server can attack a connecting client.
What should I do right now?
Upgrade to 3.7.4 or later. If you can't, set an explicit reliable maximum payload size, keep SOME/IP endpoints on trusted isolated networks only, and monitor for anomalous memory growth and repeated inbound TCP connections to SOME/IP ports.