CVE-2026-91141VulnerabilityPublished 26 Oct 2026

VU#128947: COVESA vsomeip excessive memory allocation in reliable (TCP) endpoint buffer handling

Source CERT/CC

Not known to be exploited · fixed in 3.7.4 : patch affected systems soon.

Data as of 26 Oct 2026, 21:15 UTC

Severity

High

Rated High by Threat Radar's AI analysis · CVSS not yet scored by NVD

Patch: Available – fixed in 3.7.4

Exploitation evidence

Disclosed: evidence found.
Public on cve.org; its publication date is not in this record
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

AI-suggested

Upgrade to vsomeip version 3.7.4 or later, which fixes the vulnerability by enforcing a default maximum message size of 10 MiB. If immediate upgrade is not possible, explicitly configure the max-payload-size-reliable setting to an appropriate limit to reject oversized declared message lengths. Additionally, minimize exposure by restricting reliable SOME/IP endpoints to trusted, isolated networks and applying firewall or access-control rules to limit connectivity to authorized peers. Do not expose SOME/IP endpoints to untrusted or external networks. Monitor for anomalous memory usage and unexpected inbound TCP connections to SOME/IP ports as indicators of potential exploitation attempts.

Description

vsomeip, an open source implementation of the SOME/IP automotive communication middleware, contained a memory allocation vulnerability in versions 3.7.3 and below. The vulnerability allows a remote, unauthenticated peer to cause excessive memory allocation by declaring a large message size on a reliable (TCP) endpoint before the actual message bytes are received. This can lead to denial of service by exhausting host memory. The issue was fixed in version 3.7.4 by introducing a default maximum message size limit of 10 MiB.

Impact

A remote, unauthenticated attacker can cause a host running vulnerable vsomeip versions to allocate up to approximately 4 GB of memory per connection by sending a single short message with a large declared payload size. On memory-constrained devices, this can cause immediate service termination due to out-of-memory conditions. On memory-rich hosts, denial of service can be sustained by maintaining or repeatedly opening connections, each triggering large memory allocations. This can disrupt automotive or embedded systems relying on vsomeip for communication between electronic control units.

Summary

CVE-2026-91141 affects vsomeip versions 3.7.3 and earlier. The vulnerability arises because the reliable (TCP) SOME/IP endpoint grows its receive buffer to the size declared in the message length field before verifying that the full message has been received. Since no size limit is applied by default, an attacker can declare a message size up to approximately 4 GB, causing the host to allocate that much memory. This can be triggered by any remote, unauthenticated peer on the first message of a TCP connection. The vulnerability affects both server and client endpoints. The issue was publicly reported as COVESA/vsomeip issue #1009 and fixed in release 3.7.4 by replacing the unlimited default with a 10 MiB maximum message size limit, preventing oversized allocations. Deployments that configure explicit message size limits are not affected.

References

kb.cert.org/vuls/id/128947 (opens in a new tab)

Community reviews

Loading reviews…

Exploitation evidence

What to do

Description

AI analysisMachine-generated, updated 26 Oct 2026, 19:14 UTC

Technical details

References

Community reviews

Related threats