Currently browsing: Technology

Overview
A heap-based buffer overflow exists in the Tight JPEG decoding component of the TightVNC Windows Viewer version 1.3.10 and affected UltraVNC Windows Viewers. An attacker controlling a malicious VNC server can trigger memory corruption by sending a specially crafted screen update. Successful exploitation can crash the viewer and may allow arbitrary code execution, although only denial of service conditions were demonstrated during testing.
Description
TightVNC and UltraVNC provide remote desktop access using the Remote Framebuffer (RFB) protocol. Their viewer applications connect to VNC servers and decode screen updates for local display. Tight encoding supports JPEG compression of image data within these updates.
The Windows viewer function DecompressJpegRect() allocates a heap buffer using a hardcoded maximum row width of 8,192 pixels but converts JPEG pixel data using the server-supplied rectangle width without adequately checking that the output fits within the buffer. A malicious server can supply an oversized Tight JPEG rectangle that causes the conversion loop to write beyond the allocated memory. In an allocation demonstrated during testing, which included 256 bytes of padding, the out-of-bounds write began at a rectangle width of 8,257 pixels.
Exploitation requires a vulnerable viewer to establish a session with an attacker-controlled or compromised VNC server and process its crafted update. The server can advertise a sufficiently large framebuffer, so checking that the rectangle fits within the advertised framebuffer does not, by itself, prevent this overflow. Authentication or transport encryption does not prevent exploitation by a malicious server participating in the session.
Impact
An attacker controlling a VNC server can corrupt heap memory in a connected vulnerable viewer, terminating the application and interrupting the remote desktop session. Memory corruption may also permit arbitrary code execution with the privileges of the user running the viewer, but only denial of service was confirmed during testing.
Solution
Review the Vendor Information section for product-specific patch information.
According to UltraVNC’s release notes, the Tight JPEG heap overflow vulnerability was addressed in version 1.8.2.8. Users should upgrade to a current supported release containing that fix, such as version 1.8.3.1.
Unfortunately, we were unable to reach TightVNC to coordinate a fix for the affected 1.3.10 Windows viewer. Users should replace affected viewers with a maintained version or an alternative solution that has been confirmed to address the vulnerability.
Until a corrected viewer is deployed, restrict connections to trusted VNC servers only. This reduces exposure but does not protect against a compromised trusted server.
Acknowledgements
Thank you to re9rch for reporting this vulnerability. This document was written by Michael Bragg.

Overview
Multiple arbitrary file read and write vulnerabilities have been identified in applications that use ImageMagick with insufficiently restrictive security policies. Collectively referred to as ImageTragick2, these issues arise when ImageMagick processes attacker-controlled SVG or PostScript content using dangerous coders or delegates permitted by its default or application-supplied configuration. An attacker who can upload an image, or otherwise cause an application to process crafted image content, may be able to read or write files accessible to the ImageMagick process. In some deployments, these capabilities may be chained to achieve arbitrary code execution, compromising the confidentiality, integrity, and availability of the affected application and host.
Description
ImageMagick is a widely used open-source image-processing suite. Web and content-management applications, including Ruby on Rails, WordPress, MediaWiki, ownCloud Classic, and Redmine, may use ImageMagick for operations such as thumbnail generation, cropping, conversion, and transformation. ImageMagick is also commonly included in containerized AI image-processing pipelines. It may operate before inference to normalize or transform inputs, or after inference to convert and prepare generated output. In these environments, images may originate not only from direct uploads but also from URLs, automated agents, datasets, model outputs, or other upstream services.
Two vulnerability variants have been identified:
Coder invocation through SVG (MSL injection)
ImageMagick’s SVG processing can allow a crafted SVG <image> element to invoke a dangerous coder through its xlink:href value, for example, by referencing an MSL: resource. ImageMagick may then interpret the referenced content as a Magick Scripting Language (MSL) script. The script can invoke additional image readers and direct attacker-controlled image data to selected filesystem paths, enabling unauthorized file access. Exploitation depends on the internal SVG coder and the required dangerous coders being available to the ImageMagick process.
Ghostscript invocation through content detection
ImageMagick’s content-based format detection may identify crafted input as PostScript and invoke Ghostscript, a separate interpreter used by ImageMagick to handle PostScript, EPS, and PDF, even when the filename or declared type suggests another format. Although Ghostscript is invoked with -dSAFER, the observed configuration permits file access within /tmp. A crafted PostScript file may therefore read or write data in that directory. This can affect applications that use shared temporary storage for uploaded files, processing artifacts, sessions, or other security-sensitive data.
These issues highlight an important aspect of ImageMagick’s security model: Behavior that can be restricted through a custom security policy is treated as a configuration issue, not a vulnerability in ImageMagick itself. Applications and distributions are therefore responsible for deploying a policy appropriate to their threat model. Many integrations, however, process untrusted content without a sufficiently restrictive policy.
Impact
An attacker who can cause an affected application to process crafted SVG or PostScript content may be able to read or write files in directory locations accessible to the ImageMagick process. In some cases, arbitrary code execution is possible when file access can be combined with writable executable content. AI-enabled services that utilize ImageMagick may face additional exposure because of untrusted image processing. In container deployments, writable host mounts, shared volumes, credentials, or inference artifacts can substantially increase the impact of a successful exploit.
Solution
Consult the Vendor Information section for product-specific updates and mitigations. Users of products that integrate ImageMagick, including Ruby on Rails, WordPress, MediaWiki, ownCloud Classic, and Redmine, should install vendor-provided updates when available. Updating ImageMagick alone may be insufficient if its security policy continues to permit dangerous coders or delegates.
Apply a custom policy.xml based on an allowlist: enable only the formats and operations the application requires, and disable unnecessary coders and delegates, including MSL, MVG, PS, EPS, and PDF. ImageMagick’s bundled secure policy template may not be sufficient for every deployment; verify the effective policy and confirm that prohibited formats are rejected.
Additional recommendations include:
– Isolate image processing: Process untrusted images in a dedicated, minimally privileged environment with restricted filesystem access. Apply the same controls to AI preprocessing and post-processing pipelines.
– Validate and constrain input: Verify file content rather than relying on filenames, extensions, or client-supplied media types.
– Monitor processing activity: Alert on ImageMagick policy violations, unexpected delegate or coder use, unusual processing failures, and unexpected file creation.
Acknowledgements
Thanks to RyotaK of GMO Flatt Security Inc. for reporting these vulnerabilities. The pwn.ai team independently discovered Variant 2 and reported it to WordPress as CVE-2026-65640. This document was written by Vijay Sarvepalli and Molly Jaconski.

Overview
The npm library promzard, versions 4.0.0 and earlier, is vulnerable to remote code execution due to direct string interpolation of context object keys, which allows unsanitized JavaScript code injection.
Description
promzard is a Node.js library designed to automate configuration workflows by evaluating template modules and generating data objects via interactive prompting. The library allows users to provide a context object ctx to expose specific data to the template module.
promzard builds an object by walking the template module for prompt() and asynchronous functions. The keys of ctx, however, are treated as raw JavaScript source code instead of inert data. The implementation performs direct string interpolation of ctx keys, without validation or sanitization, into the parameter list of a function-expression source string that is then evaluated with vm.runInThisContext(). A key containing attacker-controlled JavaScript syntax can be executed during evaluation.
Impact
An attacker capable of influencing the ctx object’s keys (e.g. via parsed configuration file, an HTTP request, or environment variables) can break out of the function parameter list and inject arbitrary JavaScript code. This results in remote code execution within the context of the Node.js process.
Solution
Unfortunately, the maintainers of promzard could not be reached to coordinate the vulnerability. The CERT/CC recommends users ensure that any data used to populate ctx is strictly validated, and that arbitrary keys should not be passed from untrusted sources.
Acknowledgements
Thanks to Abdullah Hamdan for reporting this vulnerability. This document was written by Alex Lewis.

Overview
ComfyUI-Easy-Use version 1.4.1 and earlier contains a vulnerability in its save_preview() handler that allows an unauthenticated attacker to overwrite an installed custom node’s Python file. An attacker who can reach the affected ComfyUI instance over the network can use the overwrite to execute arbitrary code when ComfyUI restarts.
Description
ComfyUI is a node-based interface for building generative AI workflows. ComfyUI-Easy-Use is an extension that adds custom nodes and workflow utilities.
An attacker can upload a Python file to ComfyUI’s input directory then use save_preview() to copy that file over an installed custom node’s __init__.py. Upon restart, ComfyUI will import and execute the modified node. Remote exploitation requires a deployment that exposes the affected routes to the attacker without authentication.
Impact
An unauthenticated attacker who can reach the affected routes can execute arbitrary Python code and operating system commands with the privileges of the ComfyUI process. The attacker can read or modify models, workflows, and other files accessible to the process and obtain credentials available in its environment. Exploitation requires no user interaction. The reporter confirmed the vulnerability in ComfyUI-Easy-Use version up to verion 1.4.1.
Solution
Unfortunately, the maintainer of ComfyUI-Easy-Use could not be reached to coordinate this vulnerability. To mitigate the vulnerability, remove the extension or restrict network access to ComfyUI to trusted users. The maintainer have released a fix in main as commit 8a0f2fc412.
Acknowledgements
Thanks to Nguyen Huy Hoang for reporting this vulnerability. This document was written by Alex Lewis and Michael Bragg.

Overview
Multiple vulnerabilities in the FrodoBots EarthRover Mini+ firmware (version 6.2.4_6.2.5_0.614.0) may allow remote code execution, unauthorized access to onboard sensors, disclosure of sensitive information, and full compromise of affected devices. Exploitation may enable an attacker to remotely control the rover, access audiovisual streams, or pivot into the user’s network.
Description
The FrodoBots EarthRover Mini+ is a compact, internet‑connected mobile robot used in educational and consumer environments. The device includes a camera, microphone, motor controllers, and multiple onboard services. Multiple vulnerabilities in the EarthRover Mini+ firmware (version 6.2.4_6.2.5_0.614.0) can allow remote code execution, unauthorized access to onboard sensors, exposure of sensitive data, and complete device compromise. An attacker could potentially take remote control of the rover, access its audio and video streams, or use it to gain a foothold in its network.
CVE-2026-121685: The firmware contains several sets of hard-coded, fleet‑wide credentials, including BasicAuth credentials for an Agora token service, AWS IAM (Amazon Web Services Identity and Access Management) access keys, Amazon Web Services Internet of Things Message Queuing Telemetry Transport (AWS IoT MQTT) credentials, and a Slack incoming webhook URL. Agora Token Service is an open source server that generates secure, time‑limited authentication tokens for use with Agora.io’s RTC (Real‑Time Communication) and RTM (Real‑Time Messaging) services. A Slack incoming webhook URL is a unique endpoint that lets external systems send messages into a Slack channel without the need for a full Slack application. These are embedded directly in frodobot.bin and are accessible through static analysis of the publicly downloadable firmware or from any device. Extraction requires no special privileges.
CVE-2026-121686: Unauthenticated remote command execution is allowed via Message Queuing Telemetry Transport (MQTT). A firmware method accepts arbitrary shell commands delivered via Amazon Web Services Internet of Things Message Queuing Telemetry Transport (AWS IoT MQTT) messages and executes them as root. Access is gated only by shared Internet of Things (IoT) credentials, with no per‑device authentication, enabling remote code execution (RCE) as root across the fleet. The IoT credentials are hard-coded in the firmware as discussed in CVE-2026-121685.
CVE-2026-121687: Several local interfaces are exposed without authentication. These services allow full local compromise of device functionality and provide access to sensitive information.
* HTTP REST API on port 80 (motor control, telemetry/GPS/IMEI) contains endpoints that reveal the plaintext Wi‑Fi password, enable Wi‑Fi join functionality, diagnostic export services
* Android Debug Bridge (ADB) root shell on port 5555
* SSH on port 22
CVE-2026-121688: The firmware contains an insecure STM32 update mechanism. STM32 is a family of 32-bit microcontrollers and is based primarily on Arm Cortex-M processor cores. They are widely used in embedded systems, IoT devices, industrial controls, robotics, automotive electronics, and consumer products. The STM32 motor‑controller firmware is fetched over unencrypted HTTP. Integrity is validated only via MD5, with the hash provided in the same unprotected response. No code‑signing mechanism is implemented, allowing firmware to be replaced with potentially malicious code.
CVE-2026-121689: The firmware exposes sensitive credentials through multiple insecure mechanisms. The Wi‑Fi PSK is stored in plaintext in wpa_supplicant.conf and is disclosed through unauthenticated API endpoints and diagnostic exports. Additionally, unauthenticated ADB access allows retrieval of the /etc/shadow file.
CVE-2026-121690: The firmware executes code with unnecessary privileges. All processes run as root and the system lacks privilege separation. The compromise of any single service results in full administrative control of the device.
Impact
Exploitation of these vulnerabilities may allow:
* Unauthorized access to live camera and microphone feeds.
* Fleet‑wide remote root access and full robot control via MQTT.
* Extraction of the user’s Wi‑Fi credentials and lateral movement onto the local network.
* Persistent compromise through tampered motor‑controller firmware.
* Unauthorized posting to the vendor’s Slack channels and potential exposure of backend infrastructure via IAM credential misuse.
* Given the rover’s mobility and sensor suite, exploitation may enable both digital and physical impacts.
Solution
As of this writing, the vendor has provided the following remediation status:
CVE-2026-121685 (Hard-coded credentials): Addressed
Most embedded credentials have been removed. One credential remains for requesting an Agora session token; backend authorization checks restrict misuse. Remaining credentials are limited to session‑bound operations.
CVE-2026-121686 (Remote command execution): Addressed
Arbitrary shell command execution has been removed. The device now supports only a small set of predefined management commands (e.g., reboot).
CVE-2026-121687 — CVE-2026-121690. (Local interfaces and privilege model): Addressed or not remotely exploitable under current deployment model.
Local interfaces require connection to the device’s Wi‑Fi access point, which has a configurable password. The vendor asserts that an attacker must be physically near the device and connected to its Wi‑Fi network to exploit these interfaces. The firmware update process is manual and conducted through the local Wi‑Fi network.
The vendor validated changes via static analysis and internal implementation review, and considers the findings fixed, mitigated, or not applicable in the current deployment model.
Users are encouraged to update to the latest version of the FrodoBots EarthRover Mini+ firmware.
Acknowledgements
Thank you to Justin Davis for reporting these vulnerabilities. This document was written by Bob Kemerer.

Overview
PrestaShop’s back-office Performance > Debug mode functionality contains a PHP code injection vulnerability. An authenticated attacker with permission to modify debug-mode configuration can submit crafted cookie configuration values that are written into an executable PHP configuration file. Successful exploitation could allow arbitrary code execution with the privileges of the PHP process.
Description
PrestaShop is an open-source e-commerce platform for creating and managing online stores. Its back-office Performance configuration includes a Debug mode for developers, which is enabled based on a specified cookie name and value.
PrestaShop’s debug-mode configuration code inserts the user-controlled values debug_cookie_name and debug_cookie_value into a PHP expression without adequately escaping or sanitizing them for use in PHP source code. The application writes this expression into the PHP define() statement in config/defines.inc.php or config/defines_custom.inc.php. A crafted value can terminate the intended string and introduce attacker-controlled PHP statements. The modified configuration file is loaded during application initialization, causing the injected code to execute on a subsequent request.
Exploitation requires an authenticated back-office account with permission to modify debug mode settings and a configuration file writable by the PHP process. Root or operating-system administrator privileges are not required. Cross-site request forgery (CSRF) protection helps prevent unauthorized requests made through another user’s session, but does not prevent exploitation by an attacker controlling an account with the required permissions. Injected code executes with the privileges of the PHP process. Affected release versions remain to be confirmed.
Impact
An authenticated attacker with the required configuration permissions could execute arbitrary PHP code in the security context of the PHP process. This could allow access to application secrets and customer data, modification or deletion of application files and database contents, and disruption of store operations. Operating-system command execution depends on the PHP configuration and available functions. The vulnerability does not independently grant root privileges.
Solution
PrestaShop version 9.2.1 addresses this vulnerability. Administrators should upgrade affected installations to version 9.2.1 or later.
If an immediate upgrade is not possible, allow only trusted administrators to modify Performance and Debug mode settings, and restrict network access to the back office. Where operationally feasible, prevent the PHP process from writing to config/defines.inc.php and config/defines_custom.inc.php. This may also prevent legitimate configuration changes.
Acknowledgements
Thanks to Deflask13 for reporting this vulnerability. This document was written by Michael Bragg.

Overview
Multiple vulnerabilities have been identified in the Android application, BaseChat – Audio Dating App, version 9.8.1, which ultimately compromise the privacy of users’ personal data and activity.
Description
BaseChat is an online dating platform built in Flutter and targeted toward users over 18. It facilitates anonymous, voice-first interaction between users. Three distinct vulnerabilities have been identified within the shipped Android application.
VU#124705.1: The application fails open when validating TLS server certificates for connections to its backend API host. The application allows any self-signed certificate to bypass standard TLS security checks.
VU#124705.2: Paid user accounts are mapped to a third-party RevenueCat subscriber database using raw MSISDNs (phone numbers), which are a guessable public identifier. Because the RevenueCat Software Development Kit (SDK) includes a public API key within the application’s Android Package Kit (APK), an attacker can query the RevenueCat’s API using predictable identifiers to retrieve individual user metadata.
VU#124705.3: The application writes Personally Identifiable Information (PII) to Android system logs in its production build. During voice calls, the application logs the remote party’s MSISDN through unstripped debug statements, which allows an attacker to recovery phone numbers of callers who are intended to remain anonymous.
Impact
Impacts of successful exploitation vary by vulnerability.
VU#124705.1: A network-positioned attacker can intercept and modify API communication, potentially leading to account takeover via session credential theft.
VU#124705.2: An attacker can locate the public RevenueCat SDK key and query the RevenueCat API using arbitrary phone numbers to retrieve associated user metadata, including activity and purchase history.
VU#124705.3: The personal data, or PII, of other users, intended to be anonymous, can be accessed through local system logs. The application’s backend sending other users’ MSISDNs to the client in any capacity presents a privacy violation.
These vulnerabilities have been confirmed against Basechat – Audio Dating App, Android version 9.8.1.
Solution
Unfortunately, Mobile Trading GmbH, the owners of BaseChat, could not be reached to coordinate this vulnerability.
Acknowledgements
Thanks to Mahmoud Ali Khan for reporting these vulnerabilities. This document was written by Alex Lewis.

Overview
INFINITT PACS installations using System Manager versions 3.0.11.3 and 3.0.11.5 contain vulnerabilities that may allow an attacker to execute arbitrary code. INFINITT Healthcare has remediated the issues in System Manager versions 3.0.12.3 and 3.0.12.5.
Description
INFINITT PACS is an enterprise web-based medical imaging platform that stores, retrieves, and displays patient scans.
CVE-2026-16305
An improperly protected update manifest may allow a local attacker to execute commands with administrative privileges when an update is approved.
SmartExecute.exe reads and runs commands from execlist.txt after an update. Because of insecure file permissions on execlist.txt, a low-privileged attacker can modify the file before it is processed to add arbitrary malicious commands. After SmartUpdate.exe launches, it runs SmartExecute.exe and the user can be prompted by User Account Control (UAC), which can allow the malicious command to execute with administrative privileges.
CVE-2026-16306
An unsafe command dispatch through the registered imodular:// URI scheme may result in code execution.
A vulnerability in IModular.exe allows an attacker to execute certain application functions by supplying a crafted imodular:// link. The application reads the cmd value from the link and executes the corresponding function without verifying that the command is permitted or safe. By convincing an end user to open a crafted imodular:// link, an attacker can cause IModular.exe to access attacker-controlled files or run specific programs from a local folder or network share. The link also accepts a url parameter that causes IModular.exe to connect to an attacker-controlled SignalR endpoint, creating an unauthorized outbound connection.
Impact
Successful exploitation of CVE-2026-16305 may allow a local, low-privileged attacker to execute arbitrary commands with administrative privileges on the affected workstation. An attacker could then install or modify software, access protected files, disable security controls, or establish persistent access to the system.
Successful exploitation of CVE-2026-16306 may allow a remote attacker to execute code with the privileges of the affected user, access or modify data available to that user, and use the compromised workstation as a foothold for further attacks. The vulnerability may allow unauthorized outbound communication with an attacker-controlled SignalR server, potentially exposing sensitive information or enabling additional malicious activity.
Solution
There are no indications that these vulnerabilities have been exploited. INFINITT Healthcare recommends upgrading affected installations to one of the following fixed System Manager versions:

System Manager 3.0.12.3
System Manager 3.0.12.5

Organizations should apply the appropriate update as soon as operationally feasible.
Acknowledgements
Thanks to Piotr Berlinski from CyberArms.io for identifying these vulnerabilities, and to INFINITT for quickly addressing the problems. This document was written by Michael Bragg.

Overview
Fireblocks’ mpc-lib library contains a cryptographic fail-open vulnerability in its BIP32 hardened derivation implementation in the case of a missing private parent key. This breaks the ancestor isolation property of hardened derivation, allowing an attacker with a compromised lower-level signer share to recover the higher-level share it was derived from.
After reviewing the feedback from Fireblocks and further analysis of the case, we have determined that this does not constitute a valid vulnerability. Fireblocks clarified that mpc-lib’s signing protocols use only non-hardened BIP32 derivation and that a hardened index is handled as a non-hardened one. Effective exploitation would require privileged access, at which point the attacker would already hold the master share, rendering the issue moot.
Description
Fireblocks is a digital-asset custody and wallet platform that secures the private keys behind cryptocurrency wallets for institutions and exchanges, using multi-party computation (MPC) so that no single machine ever holds a complete key.
Fireblocks’ key security pipeline contains two layers: MPC, which splits a single key into shares, and hardened derivation, which mathematically isolates each share from its key hierarchy. Normally, the derivation delta between parent and child keys is formed by hashing the private parent key, a derivation index, and associated metadata.
VU#701544.1
A fail-open vulnerability was identified within the BIP32 hardened derivation implementation which fails to reject operations where no parent secret is present. If a parent key is missing, the implementation substitutes the secret parent contribution with a null buffer. Because the buffer becomes a known constant, 0, the delta becomes computable, violating ancestor isolation.
Impact
An attacker who compromises a single MPC party’s descendant signer share, and who knows the associated chain code, can compute the public derivation delta and subtract it to recover that party’s ancestor share, repeating the operation up the hierarchy to obtain that party’s root share. The isolation between derivation levels is reduced to a publicly computable scalar, so a single leaf-level share compromise extends to that party’s shares across the entire key hierarchy managed by the MPC cluster.
The primary MPC secret-sharing layer still prevents reconstruction of a full private key from a single compromised party’s shares, so this flaw does not by itself yield a spendable key. Its significance is the elimination of a defense-in-depth layer: hardened derivation no longer provides post-compromise ancestor isolation, threshold-security assumptions degrade as compromise propagates across derivation levels over time, and the downgrade occurs silently with no error or log signal. In BIP32 deployments where the chain code is treated as public, the precondition of knowing the chain code is trivially met.
Solution
At the time of writing, Fireblocks could not be reached to coordinate this vulnerability, and no vendor fix is available. Integrators can, however, reduce exposure with the following mitigations.

Treat the chain code as secret. The attack is only available to a party that knows the chain code, because the derivation delta is computed as HMAC-SHA512(chaincode, …). Chain codes should not be distributed in watch-only extended public keys or otherwise exposed to untrusted parties. Where a deployment can keep the chain code confidential, the delta is no longer publicly computable and ancestor-share recovery is not possible. This is the most effective mitigation available without a code change.

Do not rely on hardened derivation for isolation between signer shares. Audit derivation paths for hardened segments and treat the compromise of any single share as potentially exposing that party’s other shares across the derivation hierarchy.

A complete fix requires a change in the library.
Acknowledgements
Thanks to hodlturk for reporting this vulnerability. This document was written using AI assisted tools by Alexander Curtis and Alex Lewis.

Overview
vsomeip, COVESA’s open source implementation of the SOME/IP automotive communication middleware, contained a memory allocation vulnerability present in versions 3.7.3 and below. A vsomeip reliable (TCP) SOME/IP endpoint grows its receive buffer to an attacker-declared message size before validating that the declared bytes have actually been received, allowing a remote, unauthenticated peer to exhaust host memory and deny service. The issue was reported publicly as COVESA/vsomeip issue #1009 and fixed in release 3.7.4 (2026-07-06).
Description
CVE-2026-91141
vsomeip is a middleware implementation of the Scalable service-Oriented MiddlewarE over IP (SOME/IP) protocol, widely used for service-oriented communication between electronic control units (ECUs) in automotive and other embedded environments. A SOME/IP message begins with a 16-byte header that includes a 32-bit length field declaring the size of the message that follows.
A vulnerability was discovered in the handling of this length field on reliable (TCP) endpoints. When a message arrives, vsomeip grows its receive buffer to the size declared in the length field in order to read the incoming message, before confirming that those bytes have actually been received. In the default configuration, no size limit is applied to reliable endpoints, so a peer can declare a message size of up to roughly 4 GB and cause the receiver to allocate that memory. Because a freshly accepted connection reaches this path on its first message, no valid service, credentials, or SOME/IP authentication are required to trigger the allocation. The client endpoint contains the same behavior, where a malicious or compromised server can attack a connecting client.
Deployments that explicitly configure a reliable message-size limit are not affected.
This issue is publicly known. It was reported as COVESA/vsomeip issue #1009 (opened 2026-02-26) and fixed in release 3.7.4 (released 2026-07-06).
Impact
A remote, unauthenticated peer can force the host to allocate an attacker-chosen amount of memory, up to approximately 4 GB per connection, by sending a single short message on a normal TCP connection to any reachable reliable SOME/IP endpoint in the default configuration. On a memory-constrained node this can terminate the service outright: a service limited to 1.5 GB was OOM-killed by a single 16-byte message claiming a 3 GB payload. On a memory-rich host, the allocation for a single connection is released when the connection closes, so sustained memory exhaustion and denial of service follow from holding or repeating connections, each forcing its own allocation.
Solution
Upgrade to vsomeip 3.7.4 or later. This issue is fixed in release 3.7.4 (released 2026-07-06). The fix replaces the unlimited compile-time default (MESSAGE_SIZE_UNLIMITED) with a bounded DEFAULT_MAX_MESSAGE_SIZE of 10 MiB, so reliable endpoints reject an oversized declared length before growing the receive buffer even when no limit is explicitly configured. The release also adds a regression test for an oversized length field. The issue and fix are tracked publicly in COVESA/vsomeip issue #1009.
Deployments that cannot upgrade immediately should apply the following mitigations.

Deployments can explicitly set max-payload-size-reliable (or the equivalent per-service reliable message-size limit) to a value appropriate for the service. Endpoints with such a limit configured reject oversized declared lengths and are not affected by this issue. This is the most effective mitigation available without upgrading.

Because the vulnerability is reachable by any host that can open a TCP connection to a reliable SOME/IP endpoint, exposure should be minimized through network segmentation. Reliable endpoints should be confined to trusted, isolated in-vehicle or lab networks, and firewall or access-control rules should limit connectivity to known, authorized peers. SOME/IP endpoints should never be exposed to untrusted or external networks.

Operators should monitor for anomalous memory growth on services offering reliable endpoints and for unexpected or repeated inbound TCP connections to SOME/IP ports, which may indicate attempts to exploit this vulnerability.

Acknowledgements
Thank you to the Jaafer Rahmani for reporting this vulnerability. This document was written by Alexander Curtis.