# vsomeip SOME/IP flaw enables memory exhaustion DoS

Published: 2026-10-26 · Severity: routine · Sectors: Manufacturing, Transportation
Canonical: https://vorant.io/reports/f4f0fe43-6497-5790-a41b-1c94196907ea/vsomeip-some-ip-flaw-enables-memory-exhaustion-dos

> 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

- Vulnerabilities: CVE-2026-91141

## Detection guidance (public sample)

### OOM Kill of vsomeip SOME/IP Routing Process

ATT&CK: T1499.004

Kernel OOM-killer terminating a vsomeip or routing manager process, consistent with CVE-2026-91141 memory exhaustion from an oversized declared SOME/IP message length. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.

```yaml
title: OOM Kill of vsomeip SOME/IP Routing Process
id: 7c9fb823-709a-5e1e-8522-69e19e21ca75
status: experimental
description: Detects the Linux kernel OOM-killer terminating a vsomeip-based process
  or the vsomeip routing manager. This is the observable impact of CVE-2026-91141,
  where a single SOME/IP header declaring a huge message length (up to ~4GB) on a
  reliable TCP endpoint forces a giant allocation. Repeated hits or hits right after
  new inbound TCP connections to SOME/IP ports suggest exploitation. Process names
  vary by deployment, so tune the list.
tags:
- attack.impact
- attack.t1499.004
logsource:
  product: linux
  service: syslog
detection:
  keywords_oom:
  - 'Out of memory: Killed process'
  - 'oom-kill:'
  - Memory cgroup out of memory
  keywords_proc:
  - vsomeip
  - routingmanagerd
  condition: keywords_oom and keywords_proc
falsepositives:
- Genuine memory leaks or under-provisioned memory limits on ECU or lab hosts running
  vsomeip services
- Load or stress testing of SOME/IP services in lab environments
level: medium
author: Vorant
references:
- https://kb.cert.org/vuls/id/128947
```

Behavioural rules are generated from public reporting — validate in your environment before deploying.

Source reporting: https://kb.cert.org/vuls/id/128947

---

This is the free public brief from Vorant Threat Intelligence. When citing, attribute "Vorant" and link https://vorant.io/reports/f4f0fe43-6497-5790-a41b-1c94196907ea/vsomeip-some-ip-flaw-enables-memory-exhaustion-dos.
In the app the same report carries its detections (Splunk SPL already written, plus Elastic and Microsoft KQL where they apply) and live profiles of the CVEs it names. The paid plans add the security research and news reporting the free tier leaves out. Slack alerts on the vendors, sectors and countries a reader follows come with the paid plans too. A new account starts with a three-day trial, no card: https://vorant.io/signup