Biztonsági hírek

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

Unfortunately, we were unable to coordinate with the vendor to obtain a patch or fix for this vulnerability. In the meantime, several mitigation strategies can be employed to reduce the risk of exploitation. Users should consider implementing the following measures:

• 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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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 origintate 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.

CVE-2026-2275 can be triggered if 'allow_code_execution=True' is enabled in the agent settings or the tool is manually added to the agent by the creator.

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.

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

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

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.

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.

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.

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.

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

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

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.

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.

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

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

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.

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.

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.

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.

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

Version 1.6.1 of the Flash Payments package graphql-upload-minimal is vulnerable to prototype pollution. This vulnerability, located in the processRequest() function, allows an attacker to inject special property names into the operations.variables object and pollute global object prototypes, ultimately impacting the entire Node.js process.

graphql-upload-minimal is a lightweight Node.js middleware package that implements the GraphQL multipart request specification, enabling file uploads in GraphQL servers. It parses multipart/form-data requests and maps uploaded files into the GraphQL operations object, making them accessible to resolvers. The vulnerability exists in the processRequest() function, which handles multipart file upload requests. It processes a user-supplied map parameter that determines where uploaded files should be placed within the GraphQL operations.variables object.
The issue occurs because user-supplied property paths are not validated before being resolved and written into the target object. Special JavaScript property names such as __proto__, __constructor__, and prototype are not restricted, allowing crafted paths to traverse the prototype chain and modify Object.prototype. Because Object.prototype is the base prototype from which most JavaScript objects inherit, altering it results in global prototype pollution across the Node.js process. Once polluted, manipulated properties may be inherited by all subsequently created objects for the lifetime of the process.

Because Object.prototype is the foundational prototype for most JavaScript objects, modifying it can affect the behavior of all Node.js processes. Since the impact extends across the entire Node.js process and persists until the service is restarted, it can potentially result in logic corruption, denial of service, or unintended privilege escalation.

Users should upgrade to graphql-upload-minimal version 1.6.3 or later, which can be found at https://github.com/flash-oss/graphql-upload-minimal/tree/master . The patched release introduces safeguards to prevent unsafe prototype-chain property assignments during multipart file upload processing.

Thanks to Maor Caplan from Alma Security for reporting this vulnerability. This document was written by Michael Bragg.

Two unsafe pickle deserialization vulnerabilities have been discovered in the SGLang open-source project, one within the tool's multimodal generation module and another within the Encoder Parallel Disaggregation system. SGLang is a serving framework for large language models (LLMs) and multimodal models. These vulnerabilities, tracked as CVE-2026-3059 and CVE-2026-3060, allow an attacker to provide a malicious pickle file to a device using SGLang's multimodal generation system or the encoder parallel disaggregation system, enabling code execution. CVE-2026-3989 allows an attacker to provide a malicious pickle file that, when attempted to be replayed with the replay_request_dump.py script, will result in code execution. It is recommended that project maintainers avoid implementing Pickle functions due to the inherent security risks.

SGLang is a framework for serving various large language models (LLMs) and multimodal AI models, supporting models such as Qwen, DeepSeek, Mistral, and Skywork, and is compatible with OpenAI APIs. Two unsafe pickle deserialization vulnerabilities have been identified in the project, tracked as CVE-2026-3059 and CVE-2026-3060.

CVE-2026-3059 SGLangs multimodal generation module is vulnerable to unauthenticated remote code execution through the ZMQ broker, which deserializes untrusted data using pickle.loads() without authentication.

CVE-2026-3060 SGLangs encoder parallel disaggregation system is vulnerable to unauthenticated remote code execution through the disaggregation module, which deserializes untrusted data using pickle.loads() without authentication.

SGLang is vulnerable to CVE-2026-3059 when the multimodal generation system is enabled, and to CVE-2026-3060 when the encoder parallel disaggregation system is enabled. If either condition is met and an attacker knows the TCP port on which the ZMQ broker is listening and can send requests to the server, they can exploit the vulnerability by sending a malicious pickle file to the broker, which will then deserialize it.

CVE-2026-3989 SGLangs replay_request_dump.py contains an insecure pickle.load() without validation and proper deserialization. An attacker can take advantage of this by providing a malicious .pkl file, which will execute the attackers code on the device running the script.

The SGLang project's replay_request_dump.py script uses pickle.load() without trust validation, allowing for arbitrary code execution if an attacker can control the pickle file contents. This vulnerability has low applicability but high impact, and can be exploited if an attacker can provide a malicious pickle file or write to the crash dump directory, potentially through social engineering or by compromising a directory where crash dump information is automatically saved. The script, intended to replay crash dump information, poses a risk if an attacker can manipulate the input files or directories used by the script.

The use of Pickle is strongly discouraged due to its inherent security risks. Deserializing a pickle file with pickle.loads() can lead to Remote Code Execution (RCE) if an attacker can provide a malicious file. This is because the pickle file format stores not only data but also instructions on how to reconstruct the object, which are executed during deserialization. As a result, an attacker can potentially execute arbitrary Python code.

To mitigate these risks, projects should consider implementing safer serialization formats, such as JSON or XML, or using tools like msgpack to perform more data-driven serialization and deserialization instead of open-ended capabilities such as pickle. This can help prevent RCE attacks and ensure the secure exchange of data.

An attacker who can send crafted messages to the ZeroMQ interface may trigger unsafe pickle deserialization in SGLang when certain features are enabled, potentially leading to remote code execution. Additionally, an attacker who can provide a malicious pickle file in the context of a crash dump may also exploit CVE-2026-3989. 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.

Users of SGLang should restrict access to the service interfaces and ensure they are not exposed to untrusted networks. Proper network segmentation and access controls should be implemented to prevent unauthorized interaction with the ZeroMQ endpoints. During coordinated disclosure, no vendor statement was obtained. A proposed patch was submitted to the maintainers, but no response was received at the time of publication.

Thanks to the reporter, Igor Stepansky. This document was written by Christopher Cullen.

Malformed ZIP headers can cause antivirus and endpoint detection and response software (EDR) to produce false negatives. Despite the presence of malformed headers, some extraction software is still able to decompress the ZIP archive, allowing potentially malicious payloads to run upon file decompression.

ZIP archives contain metadata such as compression method, flags, and version information. Antivirus engines typically rely on this metadata to determine how to preprocess files before scanning. If an attacker modifies the compression method field, antivirus software may fail to properly decompress the file, and will therefore be unable to analyze the actual payload.

After antivirus evasion, the payload can be recovered by using a custom loader that ignores the declared Method field and instead decompresses embedded data directly. This allows the attacker to hide malicious content from antivirus engines while still being able to recover it programmatically.

Notably, standard extraction tools (e.g.: 7‑Zip, unzip, bsdtar, Python’s zipfile) trust the declared compression method and attempt decompression, but then fail with CRC or “unsupported method” errors. These tools do not extract the payload and do not expose the underlying data.

This vulnerability is similar to VU#968818, CVE-2004-0935.

A remote attacker may craft a ZIP archive with tampered metadata that prevents antivirus or EDR software from properly decompressing and inspecting its contents. The file can thereby evade full analysis, though many products will still flag it as corrupted. To execute malicious code, however, a user must extract or further process the archive. Standard extraction tools may or may not reveal the hidden payload. It is possible that a custom loader that ignores the declared compression method could recover and execute the concealed content.

Antivirus and EDR vendors should not rely solely on declared archive metadata to determine content handling. Scanners should have more aggressive detection modes to validate compression method fields against actual content characteristics, and flag inconsistencies for further inspection. Users are encouraged to contact their antivirus or EDR providers to identify whether they are vulnerable and obtain guidance on additional mitigation options.

Thanks to the reporter, Christopher Aziz. This document was written by Laurie Tyzenhaus.

An attacker can reliably identify and block Viber’s Cloak‑mode proxy traffic because the feature uses a static, easily fingerprinted TLS ClientHello, which could result in blocking and may result in denial of service.

Rakuten Viber's Proxy (Cloak mode) in Android v25.7.2.0g and Windows v25.6.0.0–v25.8.1.0 exhibits a flaw in its TLS handshake implementation. Cloak mode is designed to hide the fact that a proxy or VPN is in use. However, the Cloak proxy mode ClientHello fingerprint is rigid and lacks extension diversity, making it trivially identifiable by Deep Packet Inspection (DPI) systems. This undermines the effectiveness of domain fronting and enables network-level blocking of Viber traffic in restrictive environments. The issue compromises censorship circumvention capabilities and in specific instances, may result in denial of service.

The Cloak-mode proxy traffic fails to hide the use of a proxy. The outgoing data is easily identifiable due to the rigid finger print and no longer appears to be normal browser TLS behavior. The user has no indication the proxy is not protecting their data or

For continued support, implement automatic updates for Viber Windows clients. The current version is 27.3.0.0. The Android mobile version in version 27.2.0.0g.

Thanks to the reporter Oleksii Gaienko, an independent security researcher.This document was written by Laurie Tyzenhaus.

A command injection vulnerability was identified in the MS-Agent framework that can be triggered through unsanitized prompt-derived input. An attacker can craft untrusted input introduced via a chat prompt or other external content sources, resulting in arbitrary command execution on the target system(s) where the MS-Agent framework is deployed. No patch or vendor statement was obtained during the coordination process.

MS-Agent is a lightweight framework that enables agents to perform autonomous task execution and tool invocation. The MS-Agent framework includes several features, including a Shell tool that enables execution of commands on the target operating system to complete agentic actions.

A vulnerability has been identified that allows unsanitized input to be executed through the Shell tool. This occurs because the software does not sufficiently verify and sanitize content before execution. As a result, an attacker can leverage prompt injection techniques to influence the agent into executing unintended shell commands when interacting with attacker-controlled content.

The Shell tool relies on regular expression–based filtering in the check_safe() method, which is intended to restrict unsafe commands. The implemented default denylist can be bypassed, allowing crafted input to evade validation checks and reach the shell execution layer.

The vulnerability is tracked as:

CVE-2026-2256
Command injection vulnerability in ModelScope's ms-agent allows an attacker to execute arbitrary operating system commands through crafted prompt-derived input.

This vulnerability may be exploited when the agent is instructed to process or retrieve external content, such as analyzing code, summarizing documents, or performing other tasks that involve interacting with attacker-controlled data. If the retrieved or processed content contains malicious command sequences that bypass the check_safe() validation, the agent may forward those commands to the Shell tool for execution.

The use of a regular expression denylist in the check_safe() method is insufficient to prevent command injection. Denylist-based filtering is inherently fragile and can often be bypassed through encoding, command obfuscation, or alternative shell syntax. In this case, the filtering logic can be circumvented, enabling arbitrary command execution within the execution context of the agent process.

An attacker who successfully exploits this vulnerability may execute arbitrary operating system commands on the target with the privileges of the MS-Agent process. This may allow modification of system files, lateral movement within the environment, establishment of persistence mechanisms, or exfiltration of sensitive data accessible to the agent.

No statement was provided by the vendor during coordination efforts. Users should deploy MS-Agent only in environments where ingested content is trusted, validated, or sanitized. Agents with shell execution capabilities should be sandboxed or executed with least-privilege permissions. Additional mitigation strategies include replacing denylist-based filtering with strict allowlists and implementing stronger isolation boundaries for tool execution.

Thanks to the reporter, Itamar Yochpaz, for this report. Document written by Christopher Cullen.

A path traversal vulnerability leading to arbitrary file write exist in PyMuPDF version 1.26.5, within the ‘embedded_get’ function in ‘main.py’. This vulnerability is caused by improper handling of untrusted embedded file metadata, which is used directly as an output path, enabling attackers to write files to arbitrary locations on the local system.

PyMuPDF is a Python interface to the MuPDF document rendering engine, providing capabilities for parsing, rendering, searching, and modifying PDF documents. The ‘embedded_get’ function in PyMuPDF is responsible for opening the provided PDF along with fetching metadata, such as the file name, if using ‘args.output’ it specifies were the file will be written to on the local system. When ‘args.output’ is not provided, the ‘embedded_get’ function falls back to embedded-file metadata, and opens that value in write-binary mode. Since write-binary mode has no constrictions or safety checks it can write anywhere to the local system.
If the derived output path is not supplied by using ‘args.output’, a crafted PDF can be used to target a location on the local system by using the PDF’s name. When an extracted embedded file using ‘embedded_get’ without specified ‘args.output, the tool can write the extracted content outside the intended directory, potentially to paths on the local system.

Successful exploitation can result in arbitrary file writing to locations permitted by the executing user. If done under an account with elevated privileges, it may overwrite system files. This can lead to privilege escalation, service disruption, or security bypass. ### Overview A path traversal vulnerability leading to arbitrary file write exists in PyMuPDF version 1.26.5, within the embedded_get function in __main__.py. This vulnerability is caused by improper handling of untrusted embedded file metadata, which is used directly as an output path, enabling attackers to write files to arbitrary locations on the local system.

PyMuPDF is a Python interface to the MuPDF document rendering engine, providing capabilities for parsing, rendering, searching, and modifying PDF documents. The embedded_get function in PyMuPDF is responsible for opening the provided PDF along with fetching metadata, such as the file name. If using args.output, it specifies where the file will be written on the local system. When args.output is not provided, the embedded_get function falls back to embedded file metadata and opens that value in write-binary mode. Since write-binary mode has no constrictions nor safety checks, it can write to anywhere on the local system.
If the derived output path is not supplied with args.output, a crafted PDF can be used to target a location on the local system using the name of the PDF. When an embedded file is extracted using embedded_get without specified args.output, the tool can write the extracted content outside the intended directory, potentially to paths on the local system.

Successful exploitation can result in arbitrary file writing to locations permitted by the executing user. If done under an account with elevated privileges, it may overwrite system files. This can lead to privilege escalation, service disruption, or security bypass.

PyMuPDF has released version 1.26.7 to address this vulnerability. Affected users are encouraged to update as soon as possible.

Thanks to the reporter UKO. This document was written by Michael Bragg.

PyMuPDF has released version 1.26.7 to address this vulnerability. Affected users are encouraged to update as soon as possible.

Thanks to the reporter UKO. This document was written by Michael Bragg.

A prototype pollution vulnerability present in CASL Ability versions 2.4.0 through 6.7.4 is triggered through the rulesToFields() function in the extra module. The program’s library contains a method called setByPath() that does not properly sanitize property names, allowing attackers to add or modify properties on an object’s prototype.

The CASL library provides a robust suite for managing attribute-based access control across various components, services, and queries. Access control is defined with a set of rule conditions. The library provides a set of default values for these conditions.

In JavaScript libraries like CASL, prototypes are template objects that serve as blueprints and inform the properties of their child objects. By exploiting this prototype pollution vulnerability, an attacker can inject arbitrary properties into global object prototypes, thereby affecting all child objects that inherit from them. The issue arises from a flaw in the setByPath() function, a component of the rulesToFields() function in the extra module.

The setByPath() function is intended to safely update only permitted fields; however, it fails to properly sanitize path segments before using them as object property keys. Consequently, special property names such as prototype and constructor are accepted as valid keys, allowing an attacker to modify the properties of object prototypes and constructor classes. Furthermore, the _proto_ special property can be used to traverse the prototype chain and ultimately write to Object.prototype, the root prototype of all objects. By polluting Object.prototype, an attacker can add arbitrary properties to all objects and compromise the prototype chain throughout the Node.js process.

As Object.prototype is the root prototype that all JavaScript objects inherit from, changes to its properties can be significant, allowing an attacker to execute arbitrary code and potentially leading to a complete system compromise. Additionally, an attacker can bypass intended authorization logic, allowing unauthorized access to sensitive resources. Furthermore, changes to Object.prototype can cause unintended behavior in application code, leading to logic manipulation and potentially allowing an attacker to perform actions that would normally be restricted.

Manipulating properties in Object.prototype can also cause crashes or unexpected behavior if polluted properties do not match expected types in the application code, leading to a denial of service. Overall, the Object.prototype pollution vulnerability poses a significant risk to applications and systems. Because the vulnerability exists in the CASL library, which is used by multiple applications and services, a single exploit can have a ripple effect, compromising multiple systems and potentially leading to a widespread security breach.

Users of the library should upgrade to version 6.7.5 or later, found at https://github.com/stalniy/casl/tree/master/packages/casl-ability.

Thanks to Maor Caplan from the Alma Security for coordinating the disclosure of this vulnerability. This document was written by Ayushi Kriplani and Dr. E. Drennan, CISSP.

An out-of-bounds memory access vulnerability exists in the uncompressed decoder component of libheif. A maliciously crafted HEIF image can trigger a denial-of-service condition by causing the libheif library to crash or exhibit other unexpected behavior due to an out-of-bounds memory access.

libheif is an open-source library used for decoding and encoding modern image formats, including HEIF (High Efficiency Image File Format) and AVIF (AV1 Image File Format). These formats provide high compression efficiency and are widely used across mobile devices and online platforms.

libheif contains an out-of-bounds iterator access vulnerability in its uncompressed codec. The issue occurs when the decoder processes certain metadata structures within a HEIF file. Specifically, the decoder fails to adequately validate values read from an internal metadata box before performing iterator arithmetic on the underlying data buffer.

As a result, a malformed HEIF file can cause the decoder to read past the end of the input buffer and incorrectly interpret unrelated memory as valid metadata. This invalid memory access may lead to a segmentation fault during image decoding.

The CVE-2025-65586 captures this out-of-bounds checking flaw in libheif’s uncompressed codec that allows a maliciously crafted HEIF file to trigger an out-of-bounds read, resulting in a segmentation fault and denial of service when the file is parsed. The vulnerability was introduced in commit 6190b58f (October 3, 2024). Versions v1.19.0 through Versions 1.21.1 are affected by this vulnerbaility. The versions v1.17.6 and earlier are not affected. The issue was reported to the libheif project and has been fixed in commit f4d9157 (November 5, 2025) and then merged to the version release 1.21.0 at the end of 2025.

An attacker can exploit this vulnerability by supplying a maliciously crafted HEIF image, causing applications that use libheif to crash. Based on current analysis, exploitation is limited to denial-of-service conditions.

Potential impacts include

• Unexpected termination of applications that decode HEIF images
• Crashes in systems that automatically generate previews or thumbnails
• Disruption of services that process untrusted HEIF content (e.g., browsers, email clients, photo management tools)

There is no evidence at this time that this vulnerability can be used to achieve memory disclosure or arbitrary code execution.

The vulnerability was discovered through coverage-guided fuzzing using AddressSanitizer-instrumented builds of libheif. The issue was reproducible across standard Linux development environments.

Software vendors and developers using the libheif library are strongly encouraged to update to version 1.21.0 or later, which includes the fix for this vulnerability. End users should apply available software updates to ensure they are running a version of libheif that addresses this issue.

Thanks to the reporter Maor Caplan for identifying the vulnerability and to Dirk Farin for implementing the fix. This document was written by Timur Snoke.