Blog

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.

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

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 AUTHORITYSYSTEM 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:ProgramDataIDrive. 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.

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.

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.

Overview
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.
Description
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.
Impact
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.
Solution
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.
Acknowledgements
Thanks to Maor Caplan from Alma Security for reporting this vulnerability. This document was written by Michael Bragg.

Overview
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.
Description
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.
Impact
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.
Solution
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.
Acknowledgements
Thanks to the reporter, Igor Stepansky. Thank you to Gregory Bowers for additional research assistance during coordination.This document was written by Christopher Cullen.

Overview
Malformed ZIP headers can be used to obfuscate malicious content in ZIP files from antivirus detection tools. Despite the presence of malformed headers, custom extraction software can decompress the ZIP archive, allowing potentially malicious payloads to be recovered after successful antivirus evasion.
After a review of the researcher’s published PoC and further analysis of the case, we have determined that this issue does not meet the necessary criteria to be considered a vulnerability. The originally reported behavior was based on a misunderstanding of native archive-handling capabilities in common operating systems such as Windows and Linux. It was initially believed that native extraction tools could successfully decompress ZIP files with malformed headers, while EDRs and antivirus security tools would fail. After additional testing, we have determined that extraction is not possible through standard archiving tools, and recovering the payload would instead require a custom loader. Accordingly, this technique can be more accurately described as an obfuscation method, as it does not meaningfully violate any implicit or explicit security boundaries.
Description
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 header 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 an 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 but requires unique unpacking tools to enable any abuse or misuse.
Impact
This ZIP header obfuscation method requires custom tooling to fully recover the concealed malicious content. The impact of this obfuscation technique is limited to systems where other security policies (e.g., running arbitrary unzipping tools) may need to be bypassed to enable such an attack.
Solution
Antivirus and EDR vendors should consider alerting on such behavior to ensure their customers are aware of malformed headers in zip content. Users should not use third-party tools or custom unzip capabilities to allow malicious content to be installed on their systems.
Acknowledgements
Thanks to the reporter, Christopher Aziz. This document was written by Laurie Tyzenhaus.

Overview
The Rakuten Viber messaging app for Android V25.7.2.0g and Windows V25.6.0.0-V25.8.1.0, has a flaw in its TLS handshake implementation when using the Cloak proxy configuration. This flaw allows for easy identification of proxy usage, potentially compromising user anonymity.
Description
Rakuten Viber can be configured to use a proxy server. Multiple proxy configurations, including Cloak, are supported. Rakuten Viber in Android V25.7.2.0g and Windows V25.6.0.0–V25.8.1.0 exhibits a flaw in the TLS handshake implementation for Cloak mode. Cloak mode is designed to hide the fact that a proxy or VPN is in use.
However, the Cloak proxy mode has a rigid and easily identified fingerprint, making it trivially identifiable by Deep Packet Inspection (DPI) systems. This allows networks to block Viber traffic, undermining the app’s ability to circumvent censorship and potentially leading to denial of service in certain cases.
Impact
The Cloak-mode proxy traffic fails to hide the use of a proxy. The outgoing data is easily identifiable due to the rigid fingerprint and no longer appears to be normal browser TLS behavior. The user has no indication the proxy is not protecting their data.
Solution
Windows users should upgrade to V27.3.0.0 or later, and Android users should upgrade to V27.2.0.0g or later.
For continued support, Windows users can implement automatic updates for Viber.
Acknowledgements
Thanks to the reporter Oleksii Gaienko, an independent security researcher. This document was written by Laurie Tyzenhaus.