❌

Normal view

Breaking down the new Qualcomm chip vulnerability | Kaspersky official blog

Imagine handing your smartphone over for repair. A couple of days later, you pick it up β€” and great, it’s working again! But you won’t even realize that your device has been injected with malicious code, allowing attackers to access your smartphone even when it’s locked.

This is the beginning of the story shared by Kaspersky ICS CERT researchers, Alexander Kozlov and Sergey Anufrienko, at the Black Hat Asia 2026 conference. They managed to uncover a vulnerability that flips conventional assumptions about smartphone and IoT security on their head. Its core lies at the very heart of Qualcomm chips.

What is BootROM?

To grasp the severity of this discovery, we first need to look at how a modern device powered by a Qualcomm chip boots up. Think of it as a fortress with multiple layers of security. Each subsequent layer verifies the pass issued by the previous one. The bedrock foundation β€” the most trusted layer of them all β€” is the BootROM, a read-only memory baked directly into the silicon that can’t be modified once it comes off the fab.

The BootROM is the very first thing to run when a device powers on. It verifies the signature of the next bootloader, which in turn verifies the next, building a chain of trust all the way up to the operating system. If an attacker can compromise this chain at the BootROM level, it’s game over: the malicious code will execute before the main operating system even has a chance to load.

This is exactly what attackers can do by exploiting the CVE-2026-25262 vulnerability discovered by Kaspersky ICS CERT researchers.

Emergency Download Mode as an entry point

The research began with a protocol called Sahara. This is a component of Emergency Download Mode (EDL). Manufacturers and service centers use it to revive bricked devices: the phone is connected to a computer via USB, and a special utility program signed by the manufacturer (in this case, Qualcomm) is uploaded to it.

Sahara is implemented directly within the ARM PBL (Primary Boot Loader) β€” the BootROM itself. This means the protocol runs before any operating system boots, before any user access privileges are checked, and before any security controls are activated. The device simply waits for a USB connection, ready to accept data.

The communication scheme looks simple: the device sends a handshake (HELLO) to the computer, the computer selects the mode, a cycle begins to upload the utility program in chunks, and finally, the device executes the uploaded code. And it was within the verification logic of these very file chunks that the vulnerability was identified.

Write-what-where: the core of the vulnerability

In technical terms, the bug introduced by the developers is classified as CWE-123: Write-What-Where Condition. This is about as bad as it gets when it comes to flaws in low-level programming. An attacker can write arbitrary data to an arbitrary address in the device memory.

Without diving too deep into the technical weeds, suffice it to say that by exploiting the discovered vulnerability, attackers can gain access to any data on the device, including user-entered passwords, files, contacts, geolocation data, as well as the hardware sensors like the camera and microphone. In certain scenarios, complete control over the device is possible. Just a few minutes of physical access to the device via a cable connection, and the gadget has been compromised. This creates a risk if you hand your smartphone over to a repair shop, pass it to someone else to set up and install apps on, or just leave it unattended.

Which devices are affected

The CVE-2026-25262 vulnerability affects the following Qualcomm chip series: MDM9x07, MDM9x45, MDM9x65, MSM8909, MSM8916, MSM8952, and SDX50 β€” every single version released to date, until the vulnerability is patched by the manufacturer.

These are no obsolete museum pieces. The MDM9207, which we used for the bulk of our research, is integrated into modem modules for the internet of things (IoT), industrial equipment, smart home devices, healthcare monitoring systems, logistics trackers, and banking terminals. The MSM8916 powers many budget smartphones, while the SDX50 is used in automotive control units.

How vulnerable devices get attacked

The catch is that the attacker needs physical access to the device to pull this off. In the real world, this translates to:

  • Smartphone repairs at third-party repair shops, where the phone is left for several hours
  • Customs checkpoints in certain countries, where devices are withheld, inspected, and then returned
  • Lost and found scams, where your phone is stolen, tampered with, and then mysteriously found
  • Corporate espionage via an insider or a rogue employee

With just a few minutes of physical access to the device an attacker can plant a backdoor so deep inside that standard research tools won’t even detect it in most cases.

Why there’s no patch β€” and what to do

Qualcomm was notified of the discovery in March 2025 and confirmed the vulnerability in its chips. To identify it, the vendor reserved CVE-2026-25262, and on April 20, 2026, Kaspersky ICS CERT published technical information on the vulnerability and recommendations for users.

Qualcomm included this vulnerability in its May security bulletin. While fixing already-made devices is fundamentally impossible, the company promised to make all future chips without this vulnerability.

If you currently own a device with an affected chip, use our recommendations below to help mitigate the risk of infection.

  • Enforce strict physical control: don’t leave your devices unattended, especially when traveling or on business trips.
  • Choose only authorized service centers for repairs and maintenance.
  • Regularly update your firmware β€” this won’t patch the BootROM vulnerability, but it can eliminate many related vulnerabilities at higher levels.
  • Use a Kaspersky for AndroidΒ on your device. This will safeguard your gadget from other threats that, combined with this vulnerability, could lead to unpredictable consequences.

If you notice that your gadget with a vulnerable Qualcomm chip starts acting up β€” overheating when idle, reporting unexpected spikes in network traffic, or exhibiting strange app behavior β€” you may have fallen victim to this vulnerability. You can wipe the malicious code and reset your device to its baseline state simply by completely cutting its power. This means either pulling the battery or letting it drain all the way to zero until the gadget shuts down entirely. In this case, the malicious code will most likely not persist on the device β€” during our research, we were unable to confirm that it could achieve persistence in non-volatile memory.

Want to learn more about severe vulnerabilities in Android phones? Check out these posts:

VU#980487: Local privilege escalation in Linux Kernel (Dirty Frag)

Overview

A privilege escalation vulnerability, nicknamed "Dirty Frag," has been discovered in the Linux kernel versions 4.10 and later. This vulnerability is a result of chaining together two previously discovered vulnerabilities, xfrm-ESP Page-Cache Write CVE-2026-43284 and the RxRPC Page-Cache Write CVE-2026-43500. This vulnerability was publicly disclosed on May 07, 2026.

Description

Dirty Frag is a Linux kernel vulnerability affecting the IPv4/IPv6 fragmentation and reassembly subsystem. The issue stems from improper handling of overlapping or malformed fragment offsets during the reassembly process. An attacker capable of sending crafted network packets to a vulnerable host can exploit the flaw to trigger memory corruption conditions.

The publicly documented proof of concept demonstrates that fragmentation logic can be manipulated such that the kernel processes inconsistent fragment states, enabling a controlled write out-of-bounds scenario. When successfully exploited, this can result in local or remote denial of service (kernel panic) and, depending on configuration and kernel build options, may create a primitive for more advanced memory manipulation.

The vulnerability arises from insufficient validation of fragment metadata during reassembly, specifically around:

  • Incorrect or incomplete enforcement of fragment boundary checks
  • Acceptance of overlapping fragments in unsafe sequences
  • Inadequate cleanup when transitions occur between valid and invalid fragment states

The fragment queue logic in affected kernels does not fully verify that fragment offsets, sizes, and overlap conditions remain consistent throughout reassembly. This allows malformed sequences to be processed without proper rejection.

Impact

The primary security concern is potential privilege escalation, similar in nature to the previously disclosed VU#260001 ("Copy Fail") vulnerability.

Depending on system configuration, kernel hardening features, and network exposure, successful exploitation may result in:

  • Local or remote denial of service through kernel panic
  • Memory corruption within the Linux networking stack
  • Privilege escalation
  • Container escape in certain containerized environments
  • Additional exploit primitives when chained with other vulnerabilities

Solution

Update Linux distribution

Update your distribution’s kernel package as soon as vendor patches become available. Most major Linux distributions are expected to release fixes through their standard update channels.

Workarounds (if patching is not immediately possible):

1) Disable at-risk modules (if loaded and loadable):
Use the following command to remove the modules in which the vulnerabilities occur and clear the page cache.
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Note: you can verify if a module is currently being used using lsmod and the Used field or reviewing refcnt data in /sys/module/<module_name>/refcnt for e.g., cat /sys/module/esp4/refcnt

2) If affected modules esp4, esp6, rxrpc are compiled into the kernel (not a dynamic module), the following parameter can be added to grub, systemd-boot, or grubby, depending on your boot configuration:
initcall_blacklist=esp4,esp6,rxrpc
This prevents the module from initializing at boot time. A system reboot is required for this change to take effect.

Mitigation for Containers

For containerized environments, where this vulnerability may be leveraged for container escape, consider applying one or more of the following mitigations:

  • Secure computing (seccomp) filtering: Restrict or deny system calls that create sockets using the AF_ALG address family (protocol 38) and AF_RXRPC (protocol 33) .
  • AppArmor policies: Use AppArmor to block creation of AF_ALG sockets and AF_RXRPC via the network alg rule.
  • eBPF-based enforcement: Deploy BPF-based controls to deny socket creation with address family AF_ALG (38) and AF_RXRPC (33).

Acknowledgements

This vulnerability was disclosed by Hyunwoo Kim. This document was written by Bob Kemerer.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-43500 CVE-2026-43284
Date Public: 2026-05-20
Date First Published: 2026-05-20
Date Last Updated: 2026-05-20 21:23 UTC
Document Revision: 1

VU#777338: SGLang contains two remote code execution and one path traversal vulnerability

Overview

Three vulnerabilities have been discovered in the SGLang project, two enabling remote code execution (RCE), and one regarding a path traversal vulnerability. In order for an attacker to exploit these vulnerabilities, the multimodal generation mode must be enabled, and an attacker must have network access to the SGLang service. No patch is available at this time, and no response was obtained from the project maintainers during coordination.

Description

SGLang is an open-source framework for serving large language models (LLMs) and multimodal AI models, supporting models such as Qwen, DeepSeek, Mistral, and Skywork, and is compatible with OpenAI APIs. Three vulnerabilities have been discovered within the tool and are tracked as follows:

CVE-2026-7301
The multimodal generation runtime scheduler's ROUTER socket contains a sink that calls pickle.loads() on incoming messages, enabling RCE when exposed to the internet.

This vulnerability is distinct from CVE-2026-3060 and CVE-2026-3059, which would be open to the Internet via the ZMQ broker, which automatically binded to all network interfaces without user awareness. CVE-2026-7301 is exposed to the internet by default through the scheduler host, which binds to 0.0.0.0 by default.

CVE-2026-7302
The multimodal generation runtime is vulnerable to an unauthenticated path traversal vulnerability, allowing an attacker to write arbitrary files anywhere the server process has write access, by including ../ sequences in the upload filename when sent to specific endpoints.

CVE-2026-7304
The multimodal generation runtime is vulnerable to unauthenticated remote code execution when the --enable-custom-logit-processor option is enabled, as Python objects loaded via dill.loads() will be deserialized without validation.

Impact

If exploited, these vulnerabilities could allow an unauthenticated attacker to achieve remote code execution or arbitrary file writes on the host running SGLang. Deployments that expose the affected interface to untrusted networks are at the highest risk of exploitation.

Solution

Until a patch is available, affected users should consider the following mitigations:

Mitigation

  • Restrict access to the service interfaces and ensure they are not exposed to untrusted networks.
  • Implement network segmentation and access controls to prevent unauthorized interaction with the vulnerable endpoints.

Acknowledgements

Thanks to the reporter, Alon Shakevsky. This document was written by Christopher Cullen.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-7302 CVE-2026-7304 CVE-2026-7301
Date Public: 2026-05-18
Date First Published: 2026-05-18
Date Last Updated: 2026-05-18 10:40 UTC
Document Revision: 1

VU#471747: dnsmasq contains several vulnerabilities, including attacker DNS redirect, privilege escalation, and heap manipulation

Overview

dnsmasq is affected by multiple memory safety and input validation vulnerabilities, including heap buffer overflows, heap corruption, and code execution flaws. Collectively, these vulnerabilities enable attackers to poison cached DNS records, bypass security controls, crash the dnsmasq process, or under certain conditions, achieve local privilege escalation. dnsmasq has released version 2.92rel2 to fix the vulnerabilities.

Description

dnsmasq is an open-source networking tool that provides DNS forwarding, DHCP, and network boot services for small-to-medium sized networks and home routing devices. It can also function as a DNS resolver, which is the primary exploitation use case for several of the vulnerabilities described below, tracked collectively as CVE-2026-2291, CVE-2026-4890, CVE-2026-4891, CVE-2026-4892, CVE-2026-4893, and CVE-2026-5172.

CVE-2026-2291
dnsmasq's extract_name() function can be abused to cause a heap buffer overflow, enabling an attacker to inject false DNS cache entries. This could cause DNS queries to be redirected to attacker-controlled IP addresses or result in a Denial of Service (DoS).

CVE-2026-4890
An infinite-loop flaw in the DNSSEC validation of dnsmasq allows remote attackers to cause Denial of Service (DoS) conditions via a crafted DNS packet.

CVE-2026-4891
A heap-based out-of-bounds read vulnerability in the DNSSEC validation of dnsmasq allows remote attackers to leak memory information via a crafted DNS packet.

CVE-2026-4892
A heap-based out-of-bounds write vulnerability in the DHCPv6 implementation of dnsmasq allows local attackers to execute arbitrary code with root privileges via a crafted DHCPv6 packet.

CVE-2026-4893
An information disclosure vulnerability in dnsmasq allows remote attackers to bypass source checks via a crafted DNS packet containing RFC 7871 client-subnet information.

CVE-2026-5172
A buffer overflow vulnerability in dnsmasq’s extract_addresses() function allows attackers to trigger a heap out-of-bounds read and crash dnsmasq by exploiting a malformed DNS response.

Impact

These vulnerabilities collectively pose various risks:

DoS (CVE-2026-2291, CVE-2026-4890, CVE-2026-5172) β€” dnsmasq may crash or become unresponsive, terminating DNS resolution and affecting dependent services.

Cache Poisoning / Redirection (CVE-2026-2291, CVE-2026-4893) β€” Attackers may overwrite cache entries or manipulate response routing, enabling the silent redirection of users to malicious domains.

Information Disclosure (CVE-2026-4891, CVE-2026-4893) β€” Internal memory and network information may be inadvertently exposed.

Local Privilege Escalation (CVE-2026-4892) β€” A local attacker may execute arbitrary code as root via DHCPv6 manipulation.

Solution

dnsmasq has released version 2.92rel2 to fix the above vulnerabilities, and various vendors have published patches to address individual remediations. A full list of affected vendors and vendor patches can be found in the References section below. This note, as well as the CVE listings, will be updated as additional patches become available.

Acknowledgements

Thank you to the reporters for discovering these vulnerabilities:
* Hugo Martinez (hugomray@gmail.com) - CVE-2026-5172, CVE-2026-2291
* Andrew Fasano (NIST) - CVE-2026-2291
* Royce M (royce@xchglabs.com) - CVE-2026-4893, CVE-2026-4892, CVE-2026-4891, CVE-2026-4890, CVE-2026-2291
* Asim Viladi Oglu Manizada - CVE-2026-4892
* Mattia Ricciardi (mindless) - CVE-2026-2291

This document was written by Christopher Cullen and Molly Jaconski. Special thanks to Simon Kelly of dnsmasq and all participating vendors for their prompt engagement and coordination efforts.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-2291 CVE-2026-4893 CVE-2026-5172 CVE-2026-4890 CVE-2026-4892 CVE-2026-4891
Date Public: 2026-05-11
Date First Published: 2026-05-11
Date Last Updated: 2026-05-12 16:49 UTC
Document Revision: 5

VU#937808: Casdoor contains Arbitrary File Write vulnerability

Overview

Casdoor contains an arbitrary file write vulnerability in the implementation of its "Local File System" storage provider. Due to insufficient sanitization of user-supplied paths, an authenticated user with file upload permissions can escape the intended storage directory and write files elsewhere on the target filesystem. The vulnerability allows attackers to bypass Casdoor’s storage sandbox and perform unauthorized actions with the privileges of the Casdoor runtime user.

Description

Casdoor is an open-source identity and access management (IAM) platform and Model Context Protocol (MCP) gateway that provides authentication, single sign-on, and multi-protocol identity services for applications. Internally, it uses its Local File System storage provider to save files to a dedicated $CASDOOR/files/ directory.

During a file upload via the /api/upload-resource endpoint, the Casdoor application determines the target storage filepath by concatenating the user-supplied parameters pathPrefix and fullFilePath. However, values provided for pathPrefix are not properly sanitized, so directory traversal sequences such as ../../ are accepted without any integrity or permission checks beyond those of the OS user running the Casdoor process. The application does not verify that the destination filepath remains inside the dedicated storage directory, and it will create or overwrite any file that the Casdoor process has permission to modify.

CVE-2026-6815 An arbitrary file write vulnerability exists in Casdoor's Local File System storage provider. Due to insufficient path sanitization, an authenticated attacker with file upload privileges can perform a path traversal attack to create or overwrite arbitrary files elsewhere on the host filesystem, bypassing the application's intended storage sandbox.

Impact

Successful exploitation enables arbitrary file creation and modification on the host system, which can be used by an attacker to:
* Overwrite any file that is accessible to the Casdoor process.
* Establish persistence by creating scheduled tasks or cron jobs through the filesystem as the Casdoor user.
* Overwrite Casdoor’s backend database file casdoor.db, causing authentication services to fail and locking out all users and dependent applications.

Exploitation of this vulnerability requires the attacker to possess an authenticated session with sufficient permissions to manage storage providers and interact with the resource upload API. Depending on the privileges of the Casdoor service account, this vulnerability may allow escalation from application-level access to full host compromise.

Solution

A pull request has been submitted to the Casdoor repository that implements proper validation of storage paths, available here: https://github.com/casdoor/casdoor/pull/5458 . Otherwise, deployments should limit administrative access and restrict the filesystem permissions of the Casdoor service account. Administrators should avoid using the Local File System provider or disable this service in multi-user or exposed environments.

Acknowledgements

Thanks to Danilo Dell'Orco for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-6815
Date Public: 2026-05-11
Date First Published: 2026-05-11
Date Last Updated: 2026-05-11 14:48 UTC
Document Revision: 2

VU#260001: Linux kernel contains local privilege escalation vulnerability (Copy Fail)

Overview

A privilege escalation vulnerability has been discovered in Linux kernel versions version 4.17 (released 2017) and later. Many popular distributions and Linux-based containers are affected. This vulnerability was publicly disclosed on April 29, 2026, has been assigned CVE ID CVE-2026-31431, and is commonly referred to as "Copy Fail."

Description

The Linux kernel, since version 4.17, includes the algif_aead module, which provides user space access to authenticated encryption with associated data (AEAD) operations via the AF_ALG interface. This module may be available as a loadable kernel module or compiled directly into the kernel, depending on the Linux distribution or the custom built Linux install.

According to the https://copy.fail disclosure statement:

An unprivileged local user can write 4 controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root.

The vulnerability is caused by a logic flaw in the Linux kernel’s algif_aead (AF_ALG) implementation. An unprivileged local user can reliably perform a controlled 4-byte write into the page cache of any readable file without race conditions or timing dependencies.

Critically, the corrupted page is not marked dirty, so the modified contents are never written back to disk. The underlying file remains unchanged, allowing the in-memory corruption to bypass checksum and file integrity verification mechanisms. Because subsequent reads are served from the page cache, an attacker can target a setuid binary and modify its in-memory contents to achieve local privilege escalation to root.

A 732-byte proof-of-concept Python script demonstrates exploitation by modifying a setuid binary to obtain root privileges on many Linux distributions released since 2017. This vulnerability was discovered by Taeyang Lee of Theori, with assistance from their AI-based static application security testing (SAST) tool, Xint Code, during analysis of the Linux kernel cryptographic subsystem.

Impact

This vulnerability allows an unprivileged local user to modify the in-memory contents of a setuid binary and escalate privileges to root. Public proof-of-concept (PoC) exploit code is available, therefore increasing the likelihood of exploitation.

Solution

Patch the Kernel

Apply the upstream kernel patch that addresses the issue by reverting AF_ALG AEAD to an out-of-place operation.

Update Linux distribution

Update your distribution’s kernel package as soon as vendor patches become available. Most major Linux distributions are expected to release fixes through their standard update channels.

Workarounds (if patching is not immediately possible):

  1. Disable the algif_aead module (if loadable):
    echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
    rmmod algif_aead 2>/dev/null
    This prevents the module from being loaded and removes it if already active.

  2. If algif_aead is compiled into the kernel (not a dynamic module), the following parameter can be added to grub or systemd-boot or grubby depending on your boot configuration:
    initcall_blacklist=algif_aead_init
    This prevents the module from initializing at boot time. A system reboot is required for this change to take effect.

Note: These workarounds may impact applications that rely on AF_ALG cryptographic interfaces.

Mitigation for containers

For containerized environments, where this vulnerability may be leveraged for container escape, consider applying one or more of the following mitigations:

  • Secure computing (seccomp) filtering: Restrict or deny system calls that create sockets using the AF_ALG address family (protocol 38).
  • AppArmor policies: Use AppArmor to block creation of AF_ALG sockets via the network alg rule.
  • eBPF-based enforcement: Deploy BPF-based controls to deny socket creation with address family AF_ALG (38).

This is adopted from the guidance provided by bytedance for the vArmor community.

Note on Virtualization

While the internal kernel within a virtual machine (VM) or MicroVM is susceptible to this vulnerability, standard virtualization provides hardware-enforced memory isolation. This bug cannot be directly leveraged to facilitate a virtualization escape from a guest to the host. Virtualization and micro-virtualization technologies effectively contain the impact to the individual VM instance, protecting the host kernel and neighboring tenants from guest-originated attacks.

Acknowledgements

This vulnerability was disclosed by Theori.io research group. This document was written by Bob Kemerer and Vijay Sarvepalli.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-31431
Date Public: 2026-05-08
Date First Published: 2026-05-08
Date Last Updated: 2026-05-08 20:10 UTC
Document Revision: 3

VU#748485: Unauthenticated configuration modification vulnerability in Central Office Services - Content Hosting Component

Overview

A security flaw exists in the configuration management endpoint of the DRC INSIGHT software, allowing an unauthenticated user with access to the same network as the server to modify the server’s configuration file. This could enable data exfiltration, traffic redirection, or service disruption. DRC has acknowledged this vulnerability, tracked as CVE-2026-5756, and resolved it in Version 9.2, which is now available to clients. The patch will be included and deployed automatically with subsequent releases.

Description

Data Recognition Corporation (DRC) provides software for test proctoring, including the web-based DRC INSIGHT platform. A component of this platform, Central Office Services (COS), is typically deployed on a school or district local area network to host and distribute testing content to student devices.

COS uses a unified API router that serves both public content functions, such as exam delivery, and administrative functions, without meaningful separation between content-serving APIs and management APIs. The /v0/configuration administrative endpoint is accessible to systems on the same network as the COS server without authentication or origin validation. Any unauthenticated user or compromised device with network access to the server may submit requests that modify the server’s configuration file. The endpoint accepts and persists user-supplied JSON payloads without validating content, checking authorization, or verifying the safety of requested configuration changes. DRC has confirmed this issue and addressed it in Version 9.2.

Impact

Exploitation could allow an attacker to exfiltrate student data by overwriting storage configuration values or credentials so that test artifacts, responses, or audio recordings are sent to attacker-controlled external services instead of intended DRC-managed destinations. An attacker could also intercept or manipulate outbound traffic by inserting a malicious httpsProxy setting, causing HTTPS communications with DRC validation or content services to pass through an attacker-controlled proxy. In addition, malformed JSON, invalid port bindings, or incorrect service endpoints could disrupt operations by preventing the server from starting or interfering with active assessments.

Mitigations

Coordination with the vendor was unsuccessful prior to resolution, and no patch was available at the time of initial disclosure. Organizations that have not yet upgraded should restrict network access to the COS server by placing it on a dedicated, isolated network segment accessible only to trusted administrative systems. Student and guest networks should not be permitted to reach the server. Host-based or network firewalls should be used to restrict access to the /v0/configuration endpoint, ideally limiting access to localhost or specifically authorized administrative IP addresses. Outbound network traffic should be restricted to approved destinations, such as DRC infrastructure, and monitored for unexpected connections to unknown storage services or proxy endpoints. Administrators should enable logging and monitoring capable of detecting requests to the /v0/configuration endpoint, unauthorized configuration changes, and unusual outbound traffic patterns. Services should run with least privilege, with write access to configuration files limited wherever possible. Signed backups of configuration files should be maintained and their integrity verified before restoration or redeployment.

With the release of Version 9.2, the recommended action is immediate upgrade. Clients currently running affected versions should coordinate with DRC support to apply the patch without delay.

Acknowledgments

Thanks to Caen Jones for responsibly disclosing this vulnerability.
Document prepared by Timur Snoke with the assistance of AI.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-5756
Date Public: 2026-04-23
Date First Published: 2026-04-23
Date Last Updated: 2026-05-26 13:26 UTC
Document Revision: 2

VU#518910: Ollama GGUF Quantization Remote Memory Leak

Overview

Ollama’s model quantization engine contains a vulnerability that allows an attacker with access to the model upload interface to read and potentially exfiltrate heap memory from the server. This issue may lead to unintended behavior, including unauthorized access to sensitive data and, in some cases, broader system compromise.

Description

Ollama is an open-source tool designed to run large language models (LLMs) locally on personal systems, including macOS, Windows, and Linux. Ollama supports model quantization, an optimization technique that reduces the numerical precision used in models to improve performance and efficiency.

An out-of-bounds heap read/write vulnerability has been identified in Ollama’s model processing engine. By uploading a specially crafted GPT-Generated Unified Format (GGUF) file and triggering the quantization process, an attacker can cause the server to read beyond intended memory boundaries and write the leaked data into a new model layer.

CVE-2026-5757: Unauthenticated remote information disclosure vulnerability in Ollama's model quantization engine allows an attacker to read and exfiltrate the server's heap memory, potentially leading to sensitive data exposure, further compromise, and stealthy persistence.

The vulnerability is caused by three combined factors:

  • No Bounds Checking: The quantization engine trusts tensor metadata (like element count) from the user-supplied GGUF file header without verifying it against the actual size of the provided data.
  • Unsafe Memory Access: Go's unsafe.Slice is used to create a memory slice based on the attacker-controlled element count, which can extend far beyond the legitimate data buffer and into the application's heap.
  • Data Exfiltration Path: The out-of-bounds heap data is inadvertently processed and written into a new model layer. Ollama's registry API can then be used to "push" this layer to an attacker-controlled server, effectively exfiltrating the leaked memory.

Impact

An attacker with access to the model upload interface can exploit this vulnerability to read from or write to heap memory. This may result in exposure of sensitive data, data exfiltration, and potentially full system compromise.

Solution

Unfortunately, we were unable to reach the vendor to coordinate this vulnerability, and a patch is not yet available to address this vulnerability. The underlying issue should be addressed by implementing proper bounds checking to ensure that tensor metadata is validated against the actual size of the provided data before any memory operations are performed.

As an interim mitigation, access to the model upload functionality should be restricted or disabled, particularly in environments exposed to untrusted users or networks. Deployments should be limited to local or otherwise trusted network environments where possible. If model uploads are required for operational reasons, only models from trusted and verifiable sources should be accepted, and appropriate validation controls should be applied to reduce risk.

Acknowledgements

Thanks to the reporter Jeremy Brown, who detected the vulnerability through AI-assisted vulnerability research. This document was written by Timur Snoke.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-5757
Date Public: 2026-04-22
Date First Published: 2026-04-22
Date Last Updated: 2026-04-22 13:09 UTC
Document Revision: 1

VU#890999: Radware Alteon has a reflected XSS vulnerability that can execute JavaScript in the host browser

Overview

Radware Alteon has a reflected Cross-Site Scripting (XSS) vulnerability in the parameter ReturnTo of the route /protected/login. This vulnerability allows an attacker to execute JavaScript in the host browser.

Description

CVE-2026-5754: Reflected Cross-Site Scripting (XSS) vulnerability in Radware Alteon 34.5.4.0 vADC load-balancer allows an attacker to inject malicious scripts into the website, potentially leading to unauthorized actions, data theft, or other malicious activities.

A reflected Cross-Site Scripting (XSS) vulnerability exists in the ReturnTo parameter of the /protected/login route in Radware Alteon version 34.5.4.0. The vulnerability arises from the lack of user input sanitization, allowing an attacker to inject malicious scripts. Specifically, when a user requests a resource that redirects to a Microsoft SAML login page, the load-balancer redirects the user to the login page with a ReturnTo parameter that fails to sanitize user input. An attacker can exploit this by injecting a malicious payload in the ReturnTo parameter, which will be executed in the victim's browser.

An example attack flow is below:

  1. Attacker creates link with XSS payload in ReturnTo parameter.
  2. Victim clicks malicious link, redirecting to login page.
  3. Load-balancer reflects malicious ReturnTo parameter, executing XSS payload.
  4. Attacker performs JavaScript code execution in the victim's browser.

Impact

The impact of this vulnerability is significant, as it allows an attacker to execute arbitrary JavaScript code in a victim’s browser. Doing so enables a range of harmful activities, including the following: stealing session cookies and sensitive data; performing unauthorized actions on behalf of the victim; tricking users into falling for phishing attacks; and damaging a website’s reputation and user trust.

Solution

Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. The vendor, Radware, has acknowledged the vulnerability in their customer portal and plans to patch it in the next version, 34.5.7.0. This version was expected to be released on March 31st, 2026, based upon the release notes, but it is unclear if this release occurred and included a fix. In the meantime, users are advised to take precautions to prevent exploitation, such as validating and encoding user input.

Acknowledgements

Thanks to the reporter, Loinaz Merino Cerrajeria, for bringing this vulnerability to our attention.This document was written by Timur Snoke.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

References

  • added apostrophe and "user"

Other Information

CVE IDs: CVE-2026-5754
Date Public: 2026-04-21
Date First Published: 2026-04-21
Date Last Updated: 2026-04-21 15:16 UTC
Document Revision: 1

VU#414811: Terrarium contains a vulnerability that allows arbitrary code execution

Overview

Terrarium is a sandbox-based code execution platform that enables users to run and execute code in a controlled environment, providing a secure way to test and validate code. However, a vulnerability has been discovered in Terrarium that allows arbitrary code execution with root privileges on the host Node.js process. This vulnerability is caused by a JavaScript prototype chain traversal in the Pyodide WebAssembly environment.

Description

The root cause of the vulnerability lies in the configuration of jsglobals objects in service.ts. Specifically, the mock document object is created using a standard JavaScript object literal, which inherits properties from Object.prototype. This inheritance chain allows sandbox code to traverse up to the function constructor, create a function that returns globalThis, and from there access Node.js internals, including require(). As a result, an attacker can escape the sandbox and execute arbitrary system commands as root within the container.

CVE-2026-5752
Sandbox Escape Vulnerability in Terrarium allows arbitrary code execution with root privileges on a host process via JavaScript prototype chain traversal.

Impact

Applications that use Terrarium for sandboxed code execution may be compromised, allowing an attacker to:

  • Execute arbitrary commands as root inside the container
  • Access and modify sensitive files, including /etc/passwd and environment variables
  • Reach other services on the container's network, including databases and internal APIs
  • Potentially escape the container and escalate privileges further

Mitigation

The vendor has published a patch as v1.0.1 of cohere-terrarium and this version has been identified as the final release. If you are unable to patch your implementation, several mitigation strategies can be employed to reduce the risk of exploitation. Users should consider implementing the following measures if upgrading is not an option:

  • Disable unnecessary features: Disable any features that allow users to submit code to the sandbox, if possible.
  • Implement network segmentation: Segment the network to limit the attack surface and prevent lateral movement.
  • Use a Web Application Firewall (WAF): Deploy a WAF to detect and block suspicious traffic, including attempts to exploit the vulnerability.
  • Monitor container activity: Regularly monitor container activity for signs of suspicious behavior.
  • Implement access controls: Limit access to the container and its resources to authorized personnel only.
  • Use a secure container orchestration tool: Utilize a secure container orchestration tool to manage and secure containers.
  • Regularly update and patch dependencies: Ensure that dependencies are up-to-date and patched.

Acknowledgments

The vulnerability was discovered by Jeremy Brown, who used AI-assisted vulnerability research to identify the issue. This document was written by Timur Snoke with assistance from AI.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-5752
Date Public: 2026-04-21
Date First Published: 2026-04-21
Date Last Updated: 2026-04-24 15:41 UTC
Document Revision: 3

VU#915947: SGLang is vulnerable to remote code execution when rendering chat templates from a model file

Overview

A remote code execution vulnerability has been discovered in the SGLang project, specifically in the reranking endpoint (/v1/rerank). A CVE has been assigned to track the vulnerability; CVE-2026-5760. An attacker can create a malicious model for SGLang to achieve RCE. Successful exploitation could allow arbitrary code execution in the context of the SGLang service, potentially leading to host compromise, lateral movement, data exfiltration, or denial-of-service (DoS) attacks. No response was obtained from the project maintainers during coordination.

Description

SGLang is an open-source framework for serving large language models (LLMs) and multimodal AI models, supporting models such as Qwen, DeepSeek, Mistral, and Skywork, and is compatible with OpenAI APIs. A vulnerability, tracked as CVE-2026-5760, has been discovered within the reranking endpoints. Using a cross-encoder model, the reranking endpoint reranks documents based on their relevance to a query.

An attacker exploits this vulnerability by creating a malicious GPT Generated Unified Format (GGUF) model file with a crafted tokenizer.chat_template parameter that contains a Jinja2 server-side template injection (SSTI) payload with a trigger phrase to activate the vulnerable code path. A tokenizer.chat_template is a metadata field that defines how text is structured before being processed. The victim then downloads and loads the model in SGLang, and when a request hits the /v1/rerank endpoint, the malicious template is rendered, executing the attacker's arbitrary Python code on the server. This sequence of events enables the attacker to achieve remote code execution (RCE) on the SGLang server.

The vulnerability arises from the use of jinja2.Environment() without sandboxing in the getjinjaenv() function. This function sets up the environment for rendering Jinja2 templates, but since it lacks proper sandboxing, it fails to restrict the execution of arbitrary Python code. Consequently, when the reranking endpoint is accessed and a malicious model file containing a crafted tokenizer.chattemplate is loaded, the model can execute arbitrary commands on the server.

Impact

An attacker can create a malicious model for SGLang to achieve RCE. Successful exploitation could allow arbitrary code execution in the context of the SGLang service, potentially leading to host compromise, lateral movement, data exfiltration, or denial-of-service (DoS) attacks. Deployments that expose the affected interface to untrusted networks are at the highest risk of exploitation.

Solution

To mitigate this vulnerability, it is recommended to use ImmutableSandboxedEnvironment instead of jinja2.Environment() to render the chat templates. This will prevent the execution of arbitrary Python code on the server. No response or patch was obtained during the coordination process.

Acknowledgements

Thanks to the reporter, Stuart Beck. This document was written by Christopher Cullen.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-5760
Date Public: 2026-04-20
Date First Published: 2026-04-20
Date Last Updated: 2026-04-27 18:55 UTC
Document Revision: 2

Threat landscape for industrial automation systems in Q4 2025

15 April 2026 at 14:30

Statistics across all threats

The percentage of ICS computers on which malicious objects were blocked has been decreasing since the beginning of 2024. In Q4 2025, it was 19.7%. Over the past three years, the percentage has decreased by 1.36 times, and by 1.25 times since Q4 2023.

Percentage of ICS computers on which malicious objects were blocked, Q1 2023–Q4 2025

Percentage of ICS computers on which malicious objects were blocked, Q1 2023–Q4 2025

Regionally, in Q4 2025, the percentage of ICS computers on which malicious objects were blocked ranged from 8.5% in Northern Europe to 27.3% in Africa.

Regions ranked by percentage of ICS computers on which malicious objects were blocked

Regions ranked by percentage of ICS computers on which malicious objects were blocked

Four regions saw an increase in the percentage of ICS computers on which malicious objects were blocked. The most notable increases occurred in Southern Europe and South Asia. In Q3 2025, East Asia experienced a sharp increase triggered by the local spread of malicious scripts, but the figure has since returned to normal.

Changes in percentage of ICS computers on which malicious objects were blocked, Q4 2025

Changes in percentage of ICS computers on which malicious objects were blocked, Q4 2025

Feature of the quarter: worms in email

In Q4 2025, the percentage of ICS computers on which wormsinemailattachments were blocked increasedinallregions of the world.

Many of the blocked threats were related to the worm Backdoor.MSIL.XWorm. This malware is designed to persist on the system and then remotely control it.

Interestingly, this threat was not detected on ICS computers in the previous quarter, yet it appeared in all regions in Q4 2025.

A study found that the active spread of Backdoor.MSIL.XWorm via phishing emails was likely linked to the use by hackers of another malware obfuscation technique that was actively used during massive phishing campaigns in Q4 2025. These campaigns have been known since 2024 as β€œCurriculum-vitae-catalina”.

The attackers distributed phishing emails to HR managers, recruiters, and employees responsible for hiring. The messages were disguised as responses from job applicants with subjects such as β€œResume” or β€œAttached Resume” and contained a malicious executable file under the guise of a curriculum vitae. Typically, the file was named Curriculum Vitae-Catalina.exe. When executed, it infected the system.

In Q4 2025, the threat spread across regions in two waves β€” one in October and another in November. Russia, Western Europe, South America, and North America (Canada) were attacked in October. A spike in Backdoor.MSIL.XWorm blocking was observed in other regions in November. The attack subsided in all regions in December.

The highest percentage of ICS computers on which Backdoor.MSIL.XWorm was blocked was observed in regions where threats from email clients had been historically blocked at high rates on ICS computers: Southern Europe, South America, and the Middle East.

At the same time, in Africa, where USB storage media are still actively used, the threat was also detected when removable devices were connected to ICS computers.

Selected industries

The biometrics sector has historically led the rankings of industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked.

These systems are characterized by accessibility to and from the internet, as well as minimal cybersecurity controls by the consumer organization.

Rankings of industries and OT infrastructure by percentage of ICS computers on which malicious objects were blocked

Rankings of industries and OT infrastructure by percentage of ICS computers on which malicious objects were blocked

In Q4 2025, the percentage of ICS computers on which malicious objects were blocked increased only in one sector: oil and gas. The corresponding figures increased in two regions: Russia, and Central Asia and the South Caucasus.

However, if we look at a broader time span, there is a downward trend in all the surveyed industries.

Percentage of ICS computers on which malicious objects were blocked in selected industries

Percentage of ICS computers on which malicious objects were blocked in selected industries

Diversity of detected malicious objects

In Q4 2025, Kaspersky protection solutions blocked malware from 10,142 different malware families of various categories on industrial automation systems.

Percentage of ICS computers on which the activity of malicious objects from various categories was blocked

Percentage of ICS computers on which the activity of malicious objects from various categories was blocked

In Q4 2025, there was an increase in the percentage of ICS computers on which worms, and miners in the form of executable files for Windows were blocked. These were the only categories that exhibited an increase.

Main threat sources

Depending on the threat detection and blocking scenario, it is not always possible to reliably identify the source. The circumstantial evidence for a specific source can be the blocked threat’s type (category).

The internet (visiting malicious or compromised internet resources; malicious content distributed via messengers; cloud data storage and processing services and CDNs), email clients (phishing emails), and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure.

In Q4 2025, the percentage of ICS computers on which malicious objects from various sources were blocked decreased. All sources except email clients saw their lowest levels in three years.

Percentage of ICS computers on which malicious objects from various sources were blocked

Percentage of ICS computers on which malicious objects from various sources were blocked

The same computer can be attacked by several categories of malware from the same source during a quarter. That computer is counted when calculating the percentage of attacked computers for each threat category, but is only counted once for the threat source (we count unique attacked computers). In addition, it is not always possible to accurately determine the initial infection attempt. Therefore, the total percentage of ICS computers on which various categories of threats from a certain source were blocked can exceed the percentage of computers affected by the source itself.

  • In Q4 2025, the percentage of ICS computers on which threats from the internet were blocked decreased to 7.67% and reached its lowest level since the beginning of 2023. The main categories of internet threats are malicious scripts and phishing pages, and denylisted internet resources. The percentage ranged from 3.96% in Northern Europe to 11.33% in South Asia.
  • The main categories of threats from email clients blocked on ICS computers were malicious scripts and phishing pages, spyware, and malicious documents. Most of the spyware detected in phishing emails was delivered as a password archive or a multi-layered script embedded in office document files. The percentage of ICS computers on which threats from email clients were blocked ranged from 0.64% in Northern Europe to 6.34% in Southern Europe.
  • The main categories of threats that were blocked when removable media was connected to ICS computers were worms, viruses, and spyware. The percentage of ICS computers on which threats from removable media were blocked ranged from 0.05% in Australia and New Zealand to 1.41% in Africa.
  • The main categories of threats that spread through network folders in Q4 2025 were viruses, AutoCAD malware, worms, and spyware. The percentage of ICS computers on which threats from network folders were blocked ranged from 0.01% in Northern Europe to 0.18% in East Asia.

Threat categories

Typical attacks blocked within an OT network are multi-step sequences of malicious activities, where each subsequent step of the attackers is aimed at increasing privileges and/or gaining access to other systems by exploiting the security problems of industrial enterprises, including OT infrastructures.

Malicious objects used for initial infection

In Q4 2025, the percentage of ICS computers on which denylisted internet resources were blocked decreased to 3.26%. This is the lowest quarterly figure since the beginning of 2022, and it has decreased by 1.8 times since Q2 2025.

Percentage of ICS computers on which denylisted internet resources were blocked, Q1 2023–Q4 2025

Percentage of ICS computers on which denylisted internet resources were blocked, Q1 2023–Q4 2025

Regionally, the percentage of ICS computers on which denylisted internet resources were blocked ranged from 1.74% in Northern Europe to 3.93% in Southeast Asia, which displaced Africa from first place. Russia rounded out the top three regions for this indicator.

The percentage of ICS computers on which malicious documents were blocked increased for three consecutive quarters. However, in Q4 2025 it decreased by 0.22 pp to 1.76%.

Percentage of ICS computers on which malicious documents were blocked, Q1 2023–Q4 2025

Percentage of ICS computers on which malicious documents were blocked, Q1 2023–Q4 2025

Regionally, the percentage ranged from 0.46% in Northern Europe to 3.82% in Southern Europe. In Q4 2025, the indicator increased in Eastern Europe, Russia, and Western Europe.

The percentage of ICS computers on which malicious scripts and phishing pages were blocked decreased to 6.58%. Despite the decline, this category led the rankings of threat categories in terms of the percentage of ICS computers on which they were blocked.

Percentage of ICS computers on which malicious scripts and phishing pages were blocked, Q1 2023–Q4 2025

Percentage of ICS computers on which malicious scripts and phishing pages were blocked, Q1 2023–Q4 2025

Regionally, the percentage ranged from 2.52% in Northern Europe to 10.50% in South Asia. The indicator increased in South Asia, South America, Southern Europe, and Africa. South Asia saw the most notable increase, at 3.47 pp.

Next-stage malware

Malicious objects used to initially infect computers deliver next-stage malware β€” spyware, ransomware, and miners β€” to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.

In Q4 2025, the percentage of ICS computers on which spyware, ransomware and web miners were blocked decreased. The rates were:

  • Spyware: 3.80% (down 0.24 pp). For the second quarter in a row, spyware took second place in the rankings of threat categories in terms of the percentage of ICS computers on which it was blocked.
  • Ransomware: 0.16% (down 0.01 pp).
  • Web miners: 0.24% (down 0.01 pp), this is the lowest level observed thus far in the period under review.

The percentage of ICS computers on which miners in the form of executable files for Windows were blocked increased to 0.60% (up 0.03 pp).

Self-propagating malware

Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics.

To spread across ICS networks, viruses and worms rely on removable media and network folders and are distributed in the form of infected files, such as archives with backups, office documents, pirated games and hacked applications. In rarer and more dangerous cases, web pages with network equipment settings, as well as files stored in internal document management systems, product lifecycle management (PLM) systems, resource management (ERP) systems and other web services are infected.

In Q4 2025, the percentage of ICS computers on which worms were blocked increased by 1.6 times to 1.60%. As mentioned above, this increase is related to a global phishing attack that spread the Backdoor.MSIL.XWorm backdoor worm across all regions of the world. The percentage increased in all regions. The biggest increase (up by 2.16 times) was in Southern Europe. The malware was primary distributed through email clients, and Southern Europe led the way in terms of the percentage of ICS computers on which threats from email clients were blocked.

The percentage of ICS computers on which viruses were blocked decreased to 1.33%.

AutoCAD malware

This category of malware can spread in a variety of ways, so it does not belong to a specific group.

After an increase in the previous quarter, the percentage of ICS computers on which AutoCAD malware was blocked decreased to 0.29% in Q4 2025.

For more information on industrial threats see the full version of the report.

Threat landscape for industrial automation systems in Q4 2025

15 April 2026 at 14:30

Statistics across all threats

The percentage of ICS computers on which malicious objects were blocked has been decreasing since the beginning of 2024. In Q4 2025, it was 19.7%. Over the past three years, the percentage has decreased by 1.36 times, and by 1.25 times since Q4 2023.

Percentage of ICS computers on which malicious objects were blocked, Q1 2023–Q4 2025

Percentage of ICS computers on which malicious objects were blocked, Q1 2023–Q4 2025

Regionally, in Q4 2025, the percentage of ICS computers on which malicious objects were blocked ranged from 8.5% in Northern Europe to 27.3% in Africa.

Regions ranked by percentage of ICS computers on which malicious objects were blocked

Regions ranked by percentage of ICS computers on which malicious objects were blocked

Four regions saw an increase in the percentage of ICS computers on which malicious objects were blocked. The most notable increases occurred in Southern Europe and South Asia. In Q3 2025, East Asia experienced a sharp increase triggered by the local spread of malicious scripts, but the figure has since returned to normal.

Changes in percentage of ICS computers on which malicious objects were blocked, Q4 2025

Changes in percentage of ICS computers on which malicious objects were blocked, Q4 2025

Feature of the quarter: worms in email

In Q4 2025, the percentage of ICS computers on which wormsinemailattachments were blocked increasedinallregions of the world.

Many of the blocked threats were related to the worm Backdoor.MSIL.XWorm. This malware is designed to persist on the system and then remotely control it.

Interestingly, this threat was not detected on ICS computers in the previous quarter, yet it appeared in all regions in Q4 2025.

A study found that the active spread of Backdoor.MSIL.XWorm via phishing emails was likely linked to the use by hackers of another malware obfuscation technique that was actively used during massive phishing campaigns in Q4 2025. These campaigns have been known since 2024 as β€œCurriculum-vitae-catalina”.

The attackers distributed phishing emails to HR managers, recruiters, and employees responsible for hiring. The messages were disguised as responses from job applicants with subjects such as β€œResume” or β€œAttached Resume” and contained a malicious executable file under the guise of a curriculum vitae. Typically, the file was named Curriculum Vitae-Catalina.exe. When executed, it infected the system.

In Q4 2025, the threat spread across regions in two waves β€” one in October and another in November. Russia, Western Europe, South America, and North America (Canada) were attacked in October. A spike in Backdoor.MSIL.XWorm blocking was observed in other regions in November. The attack subsided in all regions in December.

The highest percentage of ICS computers on which Backdoor.MSIL.XWorm was blocked was observed in regions where threats from email clients had been historically blocked at high rates on ICS computers: Southern Europe, South America, and the Middle East.

At the same time, in Africa, where USB storage media are still actively used, the threat was also detected when removable devices were connected to ICS computers.

Selected industries

The biometrics sector has historically led the rankings of industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked.

These systems are characterized by accessibility to and from the internet, as well as minimal cybersecurity controls by the consumer organization.

Rankings of industries and OT infrastructure by percentage of ICS computers on which malicious objects were blocked

Rankings of industries and OT infrastructure by percentage of ICS computers on which malicious objects were blocked

In Q4 2025, the percentage of ICS computers on which malicious objects were blocked increased only in one sector: oil and gas. The corresponding figures increased in two regions: Russia, and Central Asia and the South Caucasus.

However, if we look at a broader time span, there is a downward trend in all the surveyed industries.

Percentage of ICS computers on which malicious objects were blocked in selected industries

Percentage of ICS computers on which malicious objects were blocked in selected industries

Diversity of detected malicious objects

In Q4 2025, Kaspersky protection solutions blocked malware from 10,142 different malware families of various categories on industrial automation systems.

Percentage of ICS computers on which the activity of malicious objects from various categories was blocked

Percentage of ICS computers on which the activity of malicious objects from various categories was blocked

In Q4 2025, there was an increase in the percentage of ICS computers on which worms, and miners in the form of executable files for Windows were blocked. These were the only categories that exhibited an increase.

Main threat sources

Depending on the threat detection and blocking scenario, it is not always possible to reliably identify the source. The circumstantial evidence for a specific source can be the blocked threat’s type (category).

The internet (visiting malicious or compromised internet resources; malicious content distributed via messengers; cloud data storage and processing services and CDNs), email clients (phishing emails), and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure.

In Q4 2025, the percentage of ICS computers on which malicious objects from various sources were blocked decreased. All sources except email clients saw their lowest levels in three years.

Percentage of ICS computers on which malicious objects from various sources were blocked

Percentage of ICS computers on which malicious objects from various sources were blocked

The same computer can be attacked by several categories of malware from the same source during a quarter. That computer is counted when calculating the percentage of attacked computers for each threat category, but is only counted once for the threat source (we count unique attacked computers). In addition, it is not always possible to accurately determine the initial infection attempt. Therefore, the total percentage of ICS computers on which various categories of threats from a certain source were blocked can exceed the percentage of computers affected by the source itself.

  • In Q4 2025, the percentage of ICS computers on which threats from the internet were blocked decreased to 7.67% and reached its lowest level since the beginning of 2023. The main categories of internet threats are malicious scripts and phishing pages, and denylisted internet resources. The percentage ranged from 3.96% in Northern Europe to 11.33% in South Asia.
  • The main categories of threats from email clients blocked on ICS computers were malicious scripts and phishing pages, spyware, and malicious documents. Most of the spyware detected in phishing emails was delivered as a password archive or a multi-layered script embedded in office document files. The percentage of ICS computers on which threats from email clients were blocked ranged from 0.64% in Northern Europe to 6.34% in Southern Europe.
  • The main categories of threats that were blocked when removable media was connected to ICS computers were worms, viruses, and spyware. The percentage of ICS computers on which threats from removable media were blocked ranged from 0.05% in Australia and New Zealand to 1.41% in Africa.
  • The main categories of threats that spread through network folders in Q4 2025 were viruses, AutoCAD malware, worms, and spyware. The percentage of ICS computers on which threats from network folders were blocked ranged from 0.01% in Northern Europe to 0.18% in East Asia.

Threat categories

Typical attacks blocked within an OT network are multi-step sequences of malicious activities, where each subsequent step of the attackers is aimed at increasing privileges and/or gaining access to other systems by exploiting the security problems of industrial enterprises, including OT infrastructures.

Malicious objects used for initial infection

In Q4 2025, the percentage of ICS computers on which denylisted internet resources were blocked decreased to 3.26%. This is the lowest quarterly figure since the beginning of 2022, and it has decreased by 1.8 times since Q2 2025.

Percentage of ICS computers on which denylisted internet resources were blocked, Q1 2023–Q4 2025

Percentage of ICS computers on which denylisted internet resources were blocked, Q1 2023–Q4 2025

Regionally, the percentage of ICS computers on which denylisted internet resources were blocked ranged from 1.74% in Northern Europe to 3.93% in Southeast Asia, which displaced Africa from first place. Russia rounded out the top three regions for this indicator.

The percentage of ICS computers on which malicious documents were blocked increased for three consecutive quarters. However, in Q4 2025 it decreased by 0.22 pp to 1.76%.

Percentage of ICS computers on which malicious documents were blocked, Q1 2023–Q4 2025

Percentage of ICS computers on which malicious documents were blocked, Q1 2023–Q4 2025

Regionally, the percentage ranged from 0.46% in Northern Europe to 3.82% in Southern Europe. In Q4 2025, the indicator increased in Eastern Europe, Russia, and Western Europe.

The percentage of ICS computers on which malicious scripts and phishing pages were blocked decreased to 6.58%. Despite the decline, this category led the rankings of threat categories in terms of the percentage of ICS computers on which they were blocked.

Percentage of ICS computers on which malicious scripts and phishing pages were blocked, Q1 2023–Q4 2025

Percentage of ICS computers on which malicious scripts and phishing pages were blocked, Q1 2023–Q4 2025

Regionally, the percentage ranged from 2.52% in Northern Europe to 10.50% in South Asia. The indicator increased in South Asia, South America, Southern Europe, and Africa. South Asia saw the most notable increase, at 3.47 pp.

Next-stage malware

Malicious objects used to initially infect computers deliver next-stage malware β€” spyware, ransomware, and miners β€” to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.

In Q4 2025, the percentage of ICS computers on which spyware, ransomware and web miners were blocked decreased. The rates were:

  • Spyware: 3.80% (down 0.24 pp). For the second quarter in a row, spyware took second place in the rankings of threat categories in terms of the percentage of ICS computers on which it was blocked.
  • Ransomware: 0.16% (down 0.01 pp).
  • Web miners: 0.24% (down 0.01 pp), this is the lowest level observed thus far in the period under review.

The percentage of ICS computers on which miners in the form of executable files for Windows were blocked increased to 0.60% (up 0.03 pp).

Self-propagating malware

Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics.

To spread across ICS networks, viruses and worms rely on removable media and network folders and are distributed in the form of infected files, such as archives with backups, office documents, pirated games and hacked applications. In rarer and more dangerous cases, web pages with network equipment settings, as well as files stored in internal document management systems, product lifecycle management (PLM) systems, resource management (ERP) systems and other web services are infected.

In Q4 2025, the percentage of ICS computers on which worms were blocked increased by 1.6 times to 1.60%. As mentioned above, this increase is related to a global phishing attack that spread the Backdoor.MSIL.XWorm backdoor worm across all regions of the world. The percentage increased in all regions. The biggest increase (up by 2.16 times) was in Southern Europe. The malware was primary distributed through email clients, and Southern Europe led the way in terms of the percentage of ICS computers on which threats from email clients were blocked.

The percentage of ICS computers on which viruses were blocked decreased to 1.33%.

AutoCAD malware

This category of malware can spread in a variety of ways, so it does not belong to a specific group.

After an increase in the previous quarter, the percentage of ICS computers on which AutoCAD malware was blocked decreased to 0.29% in Q4 2025.

For more information on industrial threats see the full version of the report.

VU#536588: Multiple Heap Buffer Overflows in Orthanc DICOM Server

Overview

Multiple vulnerabilities have been identified in Orthanc DICOM Server version, 1.12.10 and earlier, that affect image decoding and HTTP request handling components. These vulnerabilities include heap buffer overflows, out-of-bounds reads, and resource exhaustion vulnerabilities that may allow attackers to crash the server, leak memory contents, or potentially execute arbitrary code.

Description

Orthanc is an open-source lightweight Digital Imaging and Communications in Medicine (DICOM) server used to store, process, and retrieve medical imaging data in healthcare environments. The following nine vulnerabilities identified in Orthanc primarily stem from unsafe arithmetic operations, missing bounds checks, and insufficient validation of attacker-controlled metadata in DICOM files and HTTP requests.

CVE-2026-5437 An out-of-bounds read vulnerability exists in DicomStreamReader during DICOM meta-header parsing. When processing malformed metadata structures, the parser may read beyond the bounds of the allocated metadata buffer. Although this issue does not typically crash the server or expose data directly to the attacker, it reflects insufficient input validation in the parsing logic.

CVE-2026-5438 A gzip decompression bomb vulnerability exists when Orthanc processes an HTTP request with Content-Encoding: gzip. The server does not enforce limits on decompressed size and allocates memory based on attacker-controlled compression metadata. A specially crafted gzip payload can trigger excessive memory allocation and exhaust system memory.

CVE-2026-5439 A memory exhaustion vulnerability exists in ZIP archive processing. Orthanc automatically extracts ZIP archives uploaded to certain endpoints and trusts metadata fields describing the uncompressed size of archived files. An attacker can craft a small ZIP archive containing a forged size value, causing the server to allocate extremely large buffers during extraction.

CVE-2026-5440 A memory exhaustion vulnerability exists in the HTTP server due to unbounded use of the Content-Length header. The server allocates memory directly based on the attacker-supplied header value without enforcing an upper limit. A crafted HTTP request containing an extremely large Content-Length value, such as approximately 4 GB, can trigger excessive memory allocation and server termination, even without sending a request body.

CVE-2026-5441 An out-of-bounds read vulnerability exists in the DecodePsmctRle1 function of DicomImageDecoder.cpp. The PMSCT_RLE1 decompression routine, which decodes the proprietary Philips Compression format, does not properly validate escape markers placed near the end of the compressed data stream. A crafted sequence at the end of the buffer can cause the decoder to read beyond the allocated memory region and leak heap data into the rendered image output.

CVE-2026-5442 A heap buffer overflow vulnerability exists in the DICOM image decoder. Dimension fields are encoded using Value Representation (VR) Unsigned Long (UL), instead of the expected VR Unsigned Short (US), which allows extremely large dimensions to be processed. This causes an integer overflow during frame size calculation and results in out-of-bounds memory access during image decoding.

CVE-2026-5443 A heap buffer overflow vulnerability exists during the decoding of PALETTE COLOR DICOM images. Pixel length validation uses 32-bit multiplication for width and height calculations. If these values overflow, the validation check incorrectly succeeds, allowing the decoder to read and write to memory beyond allocated buffers.

CVE-2026-5444 A heap buffer overflow vulnerability exists in the PAM ( https://netpbm.sourceforge.net/doc/pam.html) image parsing logic. When Orthanc processes a crafted PAM image embedded in a DICOM file, image dimensions are multiplied using 32-bit unsigned arithmetic. Specially chosen values can cause an integer overflow during buffer size calculation, resulting in the allocation of a small buffer followed by a much larger write operation during pixel processing.

CVE-2026-5445 An out-of-bounds read vulnerability exists in the DecodeLookupTable function within DicomImageDecoder.cpp. The lookup-table decoding logic used for PALETTE COLOR images does not validate pixel indices against the lookup table size. Crafted images containing indices larger than the palette size cause the decoder to read beyond allocated lookup table memory and expose heap contents in the output image.

Impact

The vulnerabilities in Orthan DICOM Server 1.20.10 allow attackers to trigger heap memory corruption, out-of-bounds read, information disclosure, and denial-of-service conditions through crafted DICOM files and HTTP requests. The most severe issues are heap-based buffer overflows in image parsing and decoding logic, which can crash the Orthanc process and may, under certain conditions, provide a pathway to remote code execution (RCE). Several additional flaws permit out-of-bounds reads that can expose heap-resident data, including allocator metadata, internal identifiers, points, and portions of adjacent DICOM content through rendered image output.
In addition, multiple vulnerabilities allow resource exhaustion by causing Orthanc to allocate excessive amounts of memory based on attacker-controlled metadata such as Content-Length, ZIP archive size fields, and gzip decompression size values. These conditions can reliably result in process termination and denial of service, often with only a small, crafted payload. Some of the affected code paths may also allow malicious DICOM content to be stored and later re-triggered during normal processing, increasing the persistence and operational impact of exploitation.

Solution

Orthanc has released version 1.12.11 to address these vulnerabilities, and users are strongly encouraged to upgrade as soon as possible. Administrators should review deployment configurations to limit exposure of upload and image processing functionality to trusted users and networks wherever possible. Refer to Orthanc documentation and release notes for patching and deployment guidance.

Acknowledgements

Thanks to Dr. Simon Weber and Volker SchΓΆnefeld of Machine Spirits UG (https://machinespirits.com) for the disclosure of these vulnerabilities. This document was written by Michael Bragg.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

References

  • Heap Buffer Overflow in PAM Image Buffer Allocation: https://www.machinespirits.com/advisory/b7ced5/
  • Heap Buffer Overflow in DICOM Image Decoder via VR UL Dimensions: https://www.machinespirits.com/advisory/615070/
  • Heap Buffer Overflow in DICOM Image Decoder (Palette Color Decode): https://www.machinespirits.com/advisory/553dfa/
  • Out-of-Bounds Read in DicomImageDecoder (PMSCT_RLE1 Decompression): https://www.machinespirits.com/advisory/4bcfdc/
  • Out-of-Bounds Read in DicomImageDecoder (DecodeLookupTable): https://www.machinespirits.com/advisory/33488c/
  • Memory Exhaustion via Unbounded Content-Length: https://www.machinespirits.com/advisory/1f0f72/
  • Memory Exhaustion via Forged ZIP Metadata: https://www.machinespirits.com/advisory/735e61/
  • Gzip Decompression Bomb via Content-Encoding Header: https://www.machinespirits.com/advisory/faca4b/
  • Out-of-Bounds Read in DicomStreamReader: https://www.machinespirits.com/advisory/126f96/

Other Information

CVE IDs: CVE-2026-5439 CVE-2026-5437 CVE-2026-5438 CVE-2026-5440 CVE-2026-5442 CVE-2026-5443 CVE-2026-5445 CVE-2026-5444 CVE-2026-5441
Date Public: 2026-04-09
Date First Published: 2026-04-09
Date Last Updated: 2026-04-09 14:44 UTC
Document Revision: 2

VU#951662: MuPDF by Artifex contains integer overflow vulnerability.

Overview

Artifex's MuPDF contains an integer overflow vulnerability, CVE-2026-3308, in versions up to and including 1.27.0. Using a specially crafted PDF, an attacker can trigger an integer overflow resulting in out-of-bounds heap writes. This heap corruption typically causes the application to crash, but in some cases could be exploited to enable arbitrary code execution.

Description

Artifex MuPDF is a lightweight framework for viewing and converting PDF, XPS, and e-book files. A vulnerability exists in pdf_load_image_imp, which is responsible for preparing image data for decoding.

The function processes image parameters including w (width), h (height), and bpc (bits per component), which are used to determine the amount of memory allocated during image decoding. The current implementation validates these parameters against SIZE_MAX rather than INT_MAX, but because stride calculations use integer-sized values, this check does not sufficiently protect against integer overflow when exceedingly large values are supplied.

When the overflow occurs, the resulting corrupted values are passed into the fz_unpack_stream function, which expands packed image samples into a destination buffer during image decoding. Because this too-small overflow value is used to calculate the size of the destination buffer, not enough memory is allocated for the actual size of the image. This causes fz_unpack_stream to write beyond the bounds of the allocated heap buffer, resulting in a heap out-of-bounds write.

Impact

Successful exploitation results in a heap out-of-bounds write during PDF image decoding. This condition may cause application crashes and memory corruption, or could potentially allow arbitrary code execution within the context of the application rendering the PDF.
Since this vulnerability is triggered during standard PDF parsing operations, any system that automatically processes or renders untrusted PDF files using MuPDF may be affected.

Solution

Unfortunately, the vendor was unreachable to coordinate this vulnerability. Until a complete fix is available, users should avoid processing untrusted PDF files with affected MuPDF-based applications where possible. Applications that rely on MuPDF should isolate document rendering in a sandboxed or low-privilege process and disable automatic rendering or conversion of untrusted files if feasible. A Pull Request (PR) was with the fix is available at: https://github.com/ArtifexSoftware/mupdf/pull/87

Acknowledgements

Thanks toYarden Porat from Cyata for reporting this vulnerability. This document was written by Michael Bragg.

CVE-2026-3308
An integer overflow vulnerability in 'pdf-image.c' in Artifex's MuPDF version 1.27.0 allows an attacker to maliciously craft a PDF that can trigger an integer overflow within the 'pdf_load_image_imp' function. This allows a heap out-of-bounds write that could be exploited for arbitrary code execution.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-3308
Date Public: 2026-04-02
Date First Published: 2026-04-02
Date Last Updated: 2026-04-02 17:23 UTC
Document Revision: 1

VU#655822: Kyverno is vulnerable to server-side request forgery (SSRF)

Overview

Kyverno, versions 1.16.0 to present, contains an SSRF vulnerability in its CEL-based HTTP functions, which lack URL validation or namespace scoping and allow namespaced policies to trigger arbitrary internal HTTP requests. An attacker with only namespace-level permissions can exploit this to access sensitive internal services via the highly privileged Kyverno admission controller.

Description

Kyverno is an open-source, Kubernetes-native policy engine that functions as a dynamic admission controller for the Kubernetes API. It is designed to manage the lifecycle of cluster resources by validating, mutating, and generating configurations based on YAML-defined policies. Within a security context, the engine is frequently utilized to enforce Pod Security Standards, verify image signatures via Cosign, and audit resource configurations for compliance. Because Kyverno operates with high-level permissions to intercept and modify API requests, it represents a critical component of the cluster's security posture and trust boundary.

A server-side request forgery vulnerability exists in Kyverno’s CEL-based HTTP functions (Get and Post) used by namespaced policy types in the policies.kyverno.io API group. Unlike Kyverno’s resource library, which enforces namespace boundaries, the HTTP library at pkg/cel/libs/http/http.go performs no URL validation or scoping; i.e., there are no blocklists, namespace restrictions, or destination checks. As a result, these policies can issue arbitrary HTTP requests from the Kyverno admission controller pod.

Impact

An authenticated attacker with only namespace-scoped permissions can create a malicious namespaced policy that sends an internal http.Get() request, captures the response in a CEL variable, and exfiltrates it via the policy’s messageExpression field returned in the admission denial. Because requests originate from the Kyverno admission controller, which often has privileged network reachability across internal cluster services and cloud metadata APIs, this enables cross-namespace data access and potential exposure of sensitive metadata or service responses, effectively breaking Kyverno’s intended security boundaries through SSRF.

Solution

Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Since a patch is unavailable, we can only offer mitigation strategies.

Mitigation should include implementing strict URL validation and destination controls within Kyverno’s CEL HTTP library to ensure parity with the namespace-scoped restrictions enforced by the resource library. Recommended safeguards include blocking access to link-local and cloud metadata address ranges, limiting outbound requests to approved in-cluster services, and providing administrators with configurable allowlists. Additionally, applying default deny network policies to the Kyverno admission controller pod can reduce residual risk by preventing unauthorized egress in the event of future validation gaps.

Acknowledgements

Thanks to Igor Stepansky from Orca Security Research Pod for responsibly disclosing this vulnerability. This document was written by Dr. Elke Drennan, CISSP.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-4789
Date Public: 2026-03-30
Date First Published: 2026-03-30
Date Last Updated: 2026-03-30 18:19 UTC
Document Revision: 3

VU#221883: CrewAI contains multiple vulnerabilities including SSRF, RCE and local file read

Overview

Four vulnerabilities have been identified in CrewAI, including remote code execution (RCE), arbitrary local file read, and server-side request forgery (SSRF). CVE-2026-2275 is directly caused by the Code Interpreter Tool. The other three vulnerabilities result from improper default configuration settings within the main CrewAI agent and associated Docker images. An attacker who can interact with a CrewAI agent that has the Code Interpreter Tool enabled may exploit these issues through prompt injection, ultimately chaining the vulnerabilities together. The vendor has provided a statement addressing some, but not all, of the reported vulnerabilities.

Description

CrewAI is a tool for building and orchestrating multi-agent AI systems. These agents are intended to work together to complete tasks, and developers define those tasks and workflows. CrewAI supports various tools, including one called the "Code Interpreter Tool", intended for execution of Python code within a secure Docker container.

CVE-2026-2275 origintates from the Code Interpreter tool itself. The remaining vulnerabilities stem from insecure fallback behaviors and configuration issues in the CrewAI agent and Docker environment. Exploitation of CVE-2026-2275 may enable attackers to trigger the additional vulnerabilities.

The vulnerabilities are listed below:

CVE-2026-2275
The CrewAI CodeInterpreter tool falls back to SandboxPython when it cannot reach Docker, which can enable code execution through arbitrary C function calls. This vulnerability can be triggered if: allow_code_execution=True is enabled in the agent configuration, or if the Code Interpreter Tool is manually added to the agent by the developer.

CVE-2026-2286
CrewAI contains a server-side request forgery (SSRF) vulnerability that enables content acquisition from internal and cloud services, facilitated by the RAG search tools not properly validating URLs provided at runtime.

CVE-2026-2287
CrewAI does not properly check that Docker is still running during runtime, and will fall back to a sandbox setting that allows for RCE exploitation.

CVE-2026-2285
CrewAI contains a arbitrary local file read vulnerability in the JSON loader tool that reads files without path validation, enabling access to files on the server.

Impact

An attacker with the ability to influence a CrewAI agent using the Code Interpreter Tool through either direct or indirect prompt injection can use the four vulnerabilities discovered to perform arbitrary file read, RCE, and server side request forgery. The results of the attacks can vary, as the attacker will achieve sandbox bypass and RCE/file read if the host machine is using Docker, or full RCE if the host machine is in configuration mode or unsafe mode. An attacker can use the arbitrary file read and SSRF vulnerabilities to perform credential theft, or the RCE vulnerabilities to perform further leveraging of the compromised device.

Solution

During coordinated disclosure, the vendor provided a statement addressing CVE-2026-2275 and CVE-2026-2287.

The vendor has indicated plans to take the following actions to improve security of CrewAI framework:

  • Add ctypes and related modules to BLOCKED_MODULES in an upcoming release
  • Evaluate configuration changes to fail closed rather than fall back to sandbox mode
  • Provide clearer runtime warnings when sandbox mode is active
  • Improve security-related documentation

At the time of writing, no complete patch is available for all disclosed vulnerabilities. Until fixes are released, users should:

  • Remove or restrict or disable the Code Interpreter Tool wherever possible
  • Remove (or avoid) enabling allow_code_execution=True setting unless absolutely necessary
  • Limit the agent exposure to untrusted input or santiize input as appropriate
  • Monitor Docker availability and prevent fallback to insecure sandbox modes

Acknowledgements

Thanks to the reporter, Yarden Porat of Cyata. This document was written by Christopher Cullen.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-2275 CVE-2026-2286 CVE-2026-2287 CVE-2026-2285
Date Public: 2026-03-26
Date First Published: 2026-03-30
Date Last Updated: 2026-05-20 18:28 UTC
Document Revision: 3

VU#330121: IDrive for Windows contains local privilege escalation vulnerability

Overview

The IDrive Cloud Backup Client for Windows, versions 7.0.0.63 and earlier, contains a privilege escalation vulnerability that allows any authenticated user to run arbitrary executables with NT AUTHORITY\SYSTEM permissions.

Description

IDrive is a cloud backup service that allows users to encrypt, sync, and store data from multiple devices such as PCs, Macs, iPhones, and Androids in one cloud-based account. IDrive provides a Windows client for both desktop and server editions, which acts as both a thick client and a thin client with a web interface to manage cloud backups.

CVE-2026-1995 The IDrive Windows client utility id_service.exe runs as a process with elevated SYSTEM privileges and regularly reads from several files located under C:\ProgramData\IDrive. The UTF16-LE encoded contents of these files are used by the service as arguments for starting processes. Because of weak permission configurations, these files can be edited by any standard user logged into the system. An authenticated, low-privilege attacker can overwrite or add a new file that specifies a path to an arbitrary script or .exe, which will then be executed by the id_service.exe process with SYSTEM privileges.

Impact

This vulnerability enables an authenticated local user, or any user with access to the affected directory, to execute arbitrary code as SYSTEM on the target Windows device. A local attacker could exploit this vulnerability to escalate privileges and gain full control over the target machine, potentially enabling data theft, system modification, or arbitrary script execution.

Solution

IDrive has reported that a patch for this vulnerability is currently in development. Users should monitor IDrive releases and update their software to the latest version as soon as it becomes available. In the meantime, users are advised to restrict write permissions for the affected directory and employ additional controls such as EDR monitoring and Group Policies to detect and prevent unauthorized file modifications.

Acknowledgements

Thanks to Matthew Owens and FRSecure for discovering and reporting this vulnerability. This document was written by Molly Jaconski.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-1995
Date Public: 2026-03-24
Date First Published: 2026-03-24
Date Last Updated: 2026-03-24 20:27 UTC
Document Revision: 2

VU#577436: Hard coded credentials vulnerability in GoHarbor's Harbor

Overview

GoHarbor's Harbor default admin password presents a security risk because it does not require change upon initial deployment.

Description

GoHarbor's Harbor is an open-source OCI-compliant container registry project that stores, signs, and manages container images. Harbor initializes with a default administrator account (admin) and password (Harbor12345), configured through the harbor_admin_password parameter in the harbor.yml.
While operators are expected to change these credentials during or after deployment, Harbor does not enforce a password change during setup or upon first login. If the default credentials remain unchanged, a remote attacker can authenticate using the publicly known password to gain full administrative access.

Impact

An attacker who gains administrative access can fully compromise the Harbor registry and all managed artifacts. This includes the ability to overwrite or inject malicious container images, enabling supply-chain attacks that may lead to remote code execution in downstream continuous integration and continuous development (CI/CD) pipelines and Kubernetes environments. The attacker can establish persistent access by creating new users, robot accounts, or API tokens, and can weaken or disable security controls such as vulnerability scanning, signature enforcement, and role-based access controls.
Additionally, sensitive images can be exfiltrated by configuring replication to external registries or downloading artifacts directly. Administrative privileges also allow destructive actions such as deleting repositories or corrupting artifacts, resulting in service disruption and loss of system integrity.

Solution

Operators should change the default administrative password either before or immediately after deployment. This can be done through the Harbor web interface or by specifying a unique value for harbor_admin_password in harbor.yml during installation.
A fix has been proposed to address the hardcoded default password by removing or randomizing default credentials during installation. See the Harbor pull request:
https://github.com/goharbor/harbor/pull/19188https://github.com/goharbor/harbor/pull/19188

Acknowledgements

Thanks to notnotnotveg (notnotnotveg@gmail.com) who reported this vulnerability. This document was written by Michael Bragg.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-4404
Date Public: 2026-03-24
Date First Published: 2026-03-24
Date Last Updated: 2026-03-24 14:11 UTC
Document Revision: 1

VU#624941: LibreChat RAG API contains a log-injection vulnerability

Overview

A log-injection vulnerability in the LibreChat RAG API, version 0.7.0, is caused by improper sanitization of user-supplied input written to system logs. An authenticated attacker can forge or manipulate log entries by inserting CRLF characters, compromising the integrity of audit records. This flaw may further enable downstream attacks if the tampered logs are processed or displayed by insecure log-management tools.

Description

LibreChat’s retrieval-augmented generation (RAG) application programming interface (API) is a specialized, asynchronous backend service developed with Python FastAPI and LangChain that facilitates document-based RAG through a file-level, ID-based indexing system. It operates by extracting and chunking text from user-uploaded files, generating high-dimensional embeddings via providers like OpenAI or local Ollama instances, and storing them in a PostgreSQL database equipped with the pgvector extension for efficient semantic search.

A log-injection vulnerability occurs when an application fails to properly sanitize or validate untrusted user input before including it in system log files, allowing an attacker to manipulate the integrity of the audit trail. By inserting line-feed or carriage-return (CRLF) characters in a POST request, specifically in the file_id parameter of the form data, an authenticated attacker can forge fake log entries.

Impact

By exploiting this vulnerability, an authenticated attacker can obfuscate malicious activity, misdirect forensic investigations, or impersonate other users. Furthermore, if the logs are later viewed through a web-based administrative console or an unsecure log-management tool, this vulnerability can escalate into secondary attacks such as cross-site scripting (XSS) or remote command execution.

Solution

Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Since a patch is unavailable, we can only offer mitigation strategies.
The following workarounds can help mitigate this vulnerability's impact on the targeted environment:

  • Sanitize input logs with a filter in the RAG ingest to prevent malicious data.
  • Disable the pgvector extension in PostgreSQL, if not in use.
  • Validate RAG output before passing it to other tools to prevent relaying of data that could lead to indirect prompt injection.

These recommendations are not mutually exclusive and can be implemented in combination to provide layered protection. By taking these steps, organizations can reduce their risk exposure until the vendor addresses the underlying vulnerabilities.

Acknowledgements

Thanks to Caio Bittencourt for coordinating the disclosure of this vulnerability. This document was written by Dr. Elke Drennan, CISSP.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-4276
Date Public: 2026-03-16
Date First Published: 2026-03-16
Date Last Updated: 2026-03-16 15:30 UTC
Document Revision: 1
❌