News, updates, trends and the latest
info you need to know about IT

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.