vsomeip flaw lets one 16-byte message crash car middleware

vsomeip flaw lets one 16-byte message crash car middleware

26 October 2026: A flaw in vsomeip, COVESA's open-source implementation of the SOME/IP middleware that electronic control units in cars use to talk to each other, lets an unauthenticated peer make a service allocate up to about 4 GB of memory with a single short message. Tracked as CVE-2026-91141, it affects vsomeip 3.7.3 and earlier in their default configuration and is fixed in release 3.7.4. CERT/CC has now published a note on it, which Japan's JVN relayed a day later.

Not yet independently verified. CERT/CC has no statement from COVESA and gives no CVSS score. Which carmakers or suppliers ship the affected versions is not public. We will update this when it can be confirmed, and remove this note.

A length field trusted before the bytes arrive

Every SOME/IP message starts with a 16-byte header carrying a 32-bit length. On reliable (TCP) endpoints, vsomeip grew its receive buffer to whatever size that field declared before checking that the bytes had actually arrived, and by default no size limit applies to reliable endpoints. A freshly accepted connection reaches this code on its first message, so no valid service, credentials or SOME/IP authentication are needed. The client side behaves the same way, so a malicious server can attack the clients that connect to it.

CERT/CC's test shows the effect: a service capped at 1.5 GB of memory was killed by the out-of-memory handler after one 16-byte message claiming a 3 GB payload. On a machine with plenty of memory the allocation is freed when the connection closes, so a lasting denial of service needs connections to be held open or repeated.

Fixed in July, published in October

The bug was reported publicly as issue #1009 on 26 February and fixed in vsomeip 3.7.4, released on 6 July. The fix replaces the unlimited compile-time default with a ceiling of 10 MiB (DEFAULT_MAX_MESSAGE_SIZE), so oversized lengths are refused even where no limit is configured, and adds a regression test. CERT/CC notified COVESA on 13 July and lists its status as unknown, with no vendor statement.

Because automotive software is pinned to a version for a vehicle programme and updated slowly, the useful question is not whether a fix exists but whether it reached the build in a given ECU, gateway, test bench or simulator.

What integrators and test labs should do

• Upgrade to vsomeip 3.7.4 or later.
• Where an upgrade has to wait, set max-payload-size-reliable, or the per-service reliable message-size limit, to a value that suits the service; endpoints with a limit configured are not affected.
• Keep reliable SOME/IP endpoints on isolated in-vehicle or lab networks, allow only known peers, and never expose them to external networks.
• Watch for unexplained memory growth in services with reliable endpoints and for repeated inbound TCP connections to SOME/IP ports.

The note credits Jaafer Rahmani with the report. It does not name affected vehicles or suppliers, and none has published its own advisory so far.

Related on TrustList:

• Rivian moves every R1 to RivianOS 2 with software update 2026.31
• China drafts mandatory car data security and automated parking standards
• Mobileye will supply cloud-mapped driver assist to Stellantis from 2027

Sources

• CERT/CC: Vulnerability Note VU#128947, vsomeip unbounded memory allocation (CVE-2026-91141), 26 October 2026
• COVESA vsomeip on GitHub: release 3.7.4, 6 July 2026
• JVN: JVNVU#90363302 (Japanese relay of VU#128947), 27 October 2026