Currently browsing: Security

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.

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.

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):

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.

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.

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.
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. This vulnerability is tracked as CVE-2026-5756.
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, and no patch is currently available. Organizations that are unable to update or modify the application 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.
Acknowledgments
Thanks to Caen Jones for responsibly disclosing this vulnerability.
Document prepared by Timur Snoke with the assistance of AI.

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.

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:

Attacker creates link with XSS payload in ReturnTo parameter.
Victim clicks malicious link, redirecting to login page.
Load-balancer reflects malicious ReturnTo parameter, executing XSS payload.
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.

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.

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.