The vulnerabilities are considered significant because FatFs is integrated into the firmware powering a broad range of products, including security cameras, drones, industrial control systems, hardware cryptocurrency wallets, and devices running real-time operating systems (RTOS).
According to the researchers, attackers could exploit the flaws by introducing a specially crafted USB drive, SD card, or malicious firmware update file to vulnerable devices. On severely affected systems, successful exploitation could lead to memory corruption and arbitrary code execution.
runZero noted that many embedded devices do not implement the memory protection mechanisms commonly found in smartphones and desktop operating systems. As a result, "any physical access leads to a jailbreak." The researchers warned that devices such as public kiosks, security cameras with SD card slots, ATMs, and voting machines equipped with USB ports could potentially be compromised with only brief physical access.
The seven vulnerabilities stem from a similar root cause. When FatFs processes intentionally malformed storage media or firmware images, it improperly handles invalid data, creating opportunities for crashes, memory corruption, or data leakage. The vulnerabilities have received CVSS ratings ranging from Medium to High, with none classified as Critical.
The most severe issue, tracked as CVE-2026-6682 (CVSS 7.6), is an integer overflow affecting FAT32 volume mounting. Incorrect calculations can generate an inaccurate file size, which is later interpreted as a legitimate read length, potentially resulting in memory corruption and remote code execution.
The complete list of disclosed vulnerabilities includes:
runZero also highlighted challenges surrounding coordinated disclosure. The company said it repeatedly attempted to contact the FatFs maintainer and involved Japan's JPCERT/CC coordination center but did not receive a response.
As a result, the researchers stated that there are currently no upstream patches for the memory corruption vulnerabilities, no dedicated security advisory process, and no centralized mechanism for notifying the numerous vendors that bundle FatFs into their products. While upgrading to FatFs R0.16 mitigates the GPT partition issue, the remaining vulnerabilities require downstream vendors to develop and distribute their own fixes.
The vulnerabilities affect multiple software platforms and frameworks that incorporate FatFs, including Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and the SWUpdate firmware updater. This broad adoption extends the potential impact across consumer IoT devices, industrial equipment, drones, and cryptocurrency hardware wallets.
As of runZero's public disclosure on July 1, no known attacks exploiting these vulnerabilities had been reported. However, the researchers have released proof-of-concept disk images, a testing framework, and a functional QEMU-based exploit demonstration, making technical details publicly available.
For firmware developers, runZero recommends identifying any bundled FatFs implementations, reviewing wrapper code for unsafe filename and file-size handling, and preparing vendor-specific patches. Organizations operating affected devices are advised to treat USB ports, SD card slots, and firmware update channels as potential attack vectors by restricting physical access and applying firmware updates as they become available.
runZero revealed that it initially reviewed FatFs manually in 2017 but found few noteworthy issues. During a renewed assessment in March 2026, the researchers employed an AI-assisted workflow using Visual Studio Code, GitHub Copilot running in "auto" mode, and a series of simple prompts.
The AI-generated workflow created a fuzzer capable of feeding malformed inputs into the filesystem library, uncovering vulnerabilities that had been missed during the earlier manual review while also helping validate their exploitability.
The researchers compared this trend to other recent AI-assisted security discoveries, including Google's Big Sleep identifying an exploitable memory flaw in SQLite during late 2024 and an autonomous AI agent discovering 21 memory-safety vulnerabilities in FFmpeg last month.
runZero argued that the increasing accessibility of AI-powered security research means attackers can leverage similar techniques, making timely vulnerability disclosure and remediation increasingly important.
The company also warned that patch deployment across the embedded ecosystem is likely to take years rather than months. It cited the 2024 PixieFail vulnerabilities affecting EDK II firmware as an example of slow downstream remediation and suggested that FatFs faces an even greater challenge due to the absence of an active upstream security response.
Until upstream fixes become available and platform vendors release security updates, organizations should assume that many deployed embedded devices continue to process untrusted FAT and exFAT media using vulnerable code.
Organizations using Argo CD to automate application deployments on Kubernetes are being urged to review their network configurations after security researchers disclosed an unpatched vulnerability that could allow attackers to execute arbitrary code on the platform's repo-server component and ultimately seize control of an entire Kubernetes cluster.
The vulnerability was identified by French cybersecurity firm Synacktiv, which says the issue affects the repo-server, a core Argo CD service responsible for retrieving application source code from Git repositories and converting it into Kubernetes manifests before workloads are deployed. Because the repo-server sits at the center of the GitOps deployment process, compromising it gives an attacker an opportunity to interfere with how applications are delivered throughout the cluster.
According to the researchers, exploitation does not require authentication. An attacker only needs network access to the repo-server's internal gRPC service, which accepts requests from other Argo CD components but does not verify the identity of the caller. Once that communication channel becomes reachable, a specially crafted request can be used to trigger remote code execution on the vulnerable service.
Synacktiv reported the vulnerability to the Argo CD maintainers in January 2025 through a responsible disclosure process. However, roughly eighteen months later, the issue remains unresolved, with no official security patch or CVE identifier assigned. The researchers chose to disclose their findings publicly to give administrators time to strengthen their deployments while awaiting a permanent fix.
At the center of the attack is Argo CD's repo-server, which continuously retrieves application definitions stored in Git repositories and prepares them for deployment by generating Kubernetes manifests. These manifests describe the desired state of applications, including containers, services, networking, storage, and other deployment configurations that Kubernetes uses to build and manage workloads. Since every deployment passes through this component, gaining control of the repo-server can provide attackers with extensive influence over the software being deployed inside a cluster.
The vulnerability stems from an unauthenticated internal gRPC interface exposed by the repo-server. gRPC is a high-performance communication framework commonly used for communication between services inside distributed applications. In Argo CD's design, the interface is intended for trusted internal communication. However, Synacktiv found that the service performs no authentication checks, allowing any system capable of reaching the port to submit requests that the repo-server will process.
The researchers demonstrated the attack against Argo CD version 2.13.3. They noted that no patched release currently exists and did not publish a complete list of affected versions, leaving administrators without a definitive inventory of vulnerable deployments.
To achieve code execution, the attack abuses Kustomize, a Kubernetes configuration management tool that Argo CD relies on to generate deployment manifests. Kustomize can also invoke Helm, another widely used package manager for Kubernetes, through the "--helm-command" option that specifies which executable should be launched.
Instead of directing Kustomize to the legitimate Helm binary, Synacktiv discovered that an attacker can send a malicious GenerateManifest request instructing it to execute a script stored inside an attacker-controlled Git repository. When Kustomize begins processing the deployment, it unknowingly launches the attacker's script in place of Helm, providing arbitrary code execution within the repo-server environment.
Although the vulnerable interface is intended to remain internal, the researchers warn that internal services should not automatically be considered secure. Kubernetes clusters frequently host dozens or even hundreds of interconnected workloads, and a compromise affecting a single pod can become the starting point for lateral movement if internal communication is not properly restricted.
Argo CD includes Kubernetes NetworkPolicy resources designed to limit access to sensitive services such as the repo-server and Redis. However, Synacktiv found that these protections are disabled by default when Argo CD is deployed using its Helm chart because the "networkPolicy.create" option is set to "false". As a result, installations that rely on the default configuration may unintentionally leave the repo-server reachable from other workloads running inside the cluster.
In such environments, compromising a single pod may be enough for an attacker to contact the repo-server and exploit the vulnerability.
The researchers also demonstrated that remote code execution represents only the beginning of the attack chain. After obtaining execution on the repo-server, they extracted the Redis password stored in an environment variable, authenticated to Argo CD's Redis instance, and modified cached deployment information. When Argo CD later performed its routine synchronization with the Git repository, the poisoned cache caused the platform to deploy an attacker-controlled workload instead of the intended application.
According to Synacktiv, this technique effectively revives a previously addressed weakness tracked as CVE-2024-31989. That earlier vulnerability, discovered by Cycode, exposed Argo CD deployments where Redis lacked password protection, allowing any pod inside the cluster to manipulate deployment cache data. Although Argo CD later introduced Redis password protection to address that issue, the cache contents themselves remain unsigned. By stealing the Redis credentials through the newly disclosed repo-server vulnerability, attackers can once again tamper with deployment data and recreate a similar compromise path.
With no software update currently available, researchers recommend treating network segmentation as the primary line of defense. Administrators should enable Kubernetes NetworkPolicy rules to ensure that only legitimate Argo CD components can communicate with the repo-server and Redis services. Organizations deploying Argo CD through Helm should verify that these policies have been explicitly enabled rather than relying on the chart's default configuration.
Administrators can inspect active network policies by running:
"kubectl get networkpolicy -A"
A properly secured deployment should display dedicated network policies protecting each Argo CD component, including both the repo-server and Redis. Missing policies may indicate that sensitive internal services remain accessible to other workloads inside the cluster.
To help organizations evaluate their exposure, Synacktiv developed a proof-of-concept tool named argo-cdown, capable of automating the complete attack chain. The researchers have postponed its public release to provide defenders with additional time to secure vulnerable environments. The tool is expected to be published on GitHub later, allowing administrators to validate the effectiveness of their own security controls.
The newly disclosed vulnerability is the latest in a series of security issues affecting Argo CD's privileged position within Kubernetes environments. In September 2025, the project patched CVE-2025-55190 after researchers found that an API token with only basic read permissions could retrieve Git repository credentials associated with a project. Several months later, in May 2026, another flaw tracked as CVE-2026-42880 enabled read-only users to access plaintext Kubernetes secrets.
Taken together, these incidents point to a recurring challenge rather than isolated implementation flaws. Argo CD occupies one of the most privileged positions within Kubernetes deployments, maintaining access to source repositories, deployment pipelines, cluster resources, and sensitive credentials. As a result, weaknesses affecting its internal services can quickly become pathways to broader infrastructure compromise.
Until an official patch becomes available, organizations should assume that internal cluster traffic cannot always be trusted. Restricting communication between workloads, enabling Kubernetes NetworkPolicy protections, and limiting access to critical Argo CD services remain the most effective measures for reducing exposure to this newly disclosed attack technique.
Two independent cybersecurity studies published this week have uncovered serious security weaknesses in OpenClaw, a widely used self-hosted AI agent platform. The findings demonstrate how attackers can manipulate AI agents into executing malicious code or leaking sensitive information through seemingly harmless inputs.
Researchers from Imperva and Varonis approached the issue from different angles but reached a similar conclusion: AI agents that trust incoming data and possess broad system access can become powerful attack vectors when exploited.
Imperva researchers discovered that OpenClaw could be tricked into processing concealed instructions embedded within shared contacts, vCards, and location pins. These malicious commands were executed by the AI agent without any visible indication to the user.
The issue stemmed from how OpenClaw handled certain message objects before passing them to the large language model (LLM). While content fetched from the web was clearly marked as untrusted, information contained within contacts, vCards, and location labels was inserted directly into prompts without any trust boundary.
According to Imperva researcher Yohann Sillam, this allowed attackers to hide instructions inside fields such as contact names. Since angle brackets are permitted in contact names, the model could not reliably distinguish legitimate information from injected commands.
Only selected fields were transmitted to the model, making them attractive targets. In one example, a shared contact was serialized as <contact: name, number>, allowing attackers to insert malicious instructions within the name field itself. Because messaging apps truncate long contact names, victims often never saw the hidden payload.
The same attack method was also successful through WhatsApp-supported vCards and shared location labels.
During testing against Gemini 3.1 Pro's preview build, hidden instructions successfully convinced the AI agent to download and execute a script hosted on servers controlled by the researchers. Similar attempts using images with embedded instructions failed, likely because AI models have become more resistant to that well-known attack technique.
Imperva warned that OpenClaw's default memory functionality could amplify the threat. A single malicious piece of widely shared content could potentially affect multiple agents if adequate sandboxing protections were absent.
Following responsible disclosure, OpenClaw addressed the issue in version 2026.4.23. The update separates contact names, vCard information, and location labels from the main prompt and places them in an isolated untrusted metadata channel.
Researchers also noted that similar design patterns exist in several other personal AI assistant platforms, suggesting the issue extends beyond OpenClaw alone.
While Imperva focused on prompt injection, Varonis Threat Labs explored how AI agents respond to social engineering attacks.
Led by researcher Itay Yashar, the Varonis team created an OpenClaw-based agent called Pinchy and connected it to a Gmail inbox filled with realistic business communications and synthetic sensitive information. The researchers then tested the agent using four different phishing scenarios involving Google Gemini 3.1 Pro and OpenAI Codex GPT-5.4.
Varonis distinguishes traditional prompt injection from what it calls "agent phishing." Unlike hidden instructions embedded in content, agent phishing relies on convincing requests delivered through normal communication channels, exploiting the agent's willingness to act before verifying legitimacy.
The tests revealed significant weaknesses.
In one scenario, an email impersonating a team leader named Dan requested urgent staging access during a simulated production emergency. The message originated from an external Gmail account, yet the agent located and forwarded mock AWS IAM access keys, database connection credentials, and SSH details in plain text.
A second phishing attempt used a more routine business request, asking for a weekly customer export supposedly needed for a QBR presentation. The agent responded by sending a synthetic database containing information on 247 enterprise customers, including contact details and contract values.
Notably, these failures occurred despite the agent being configured with instructions to verify sender identities before responding. Researchers observed that urgency successfully bypassed safeguards in one case, while routine business language defeated them in another.
The agent demonstrated stronger performance against technically oriented threats. It interacted with a phishing page designed to steal gift-card credentials but ultimately withheld sensitive information and flagged suspicious behavior. A stricter configuration blocked the page entirely.
Similarly, when presented with a malicious OAuth consent screen disguised as a timesheet application, the agent examined the redirect destination, recognized warning signs, and refused access.
Researchers concluded that AI agents may outperform many users when identifying suspicious URLs and fraudulent login portals. However, they remain vulnerable to social manipulation that exploits helpfulness and trust.
Varonis also observed that OpenAI Codex GPT-5.4 behaved more cautiously than Gemini 3.1 Pro when interacting with external websites or transmitting data. Nevertheless, both models ultimately fell victim to the social-engineering scenarios.
Varonis linked both attack methods to what researcher Simon Willison describes as the "lethal trifecta": an AI system capable of accessing private data, consuming untrusted content, and transmitting information externally.
OpenClaw satisfies all three conditions, making both hidden prompt injections and phishing-based attacks highly effective.
Additional concerns emerged from a separate InfoSec Write-ups analysis. Researchers converted historical OpenClaw security advisories into static-analysis rules and uncovered five additional vulnerabilities affecting integrations with Slack, Discord, Matrix, Zalo, and Microsoft Teams.
Each flaw originated from the same design issue. Channel allowlists were validated using mutable display names rather than permanent identifiers. Attackers could therefore impersonate trusted users simply by changing their display names to match approved accounts.
OpenClaw has since patched these vulnerabilities.
The platform's extensive permissions—including access to files, shell environments, and more than twenty messaging services—have previously prompted warnings regarding prompt injection and data exfiltration risks.
The strongest criticism came from the Dutch data protection authority, the Autoriteit Persoonsgegevens, which advised users and organizations against deploying OpenClaw on systems containing sensitive information due to concerns over data breaches and account compromise.
Organizations using OpenClaw are advised to upgrade immediately to version 2026.4.23 or newer to mitigate the message-object vulnerability identified by Imperva.
However, researchers stress that software updates alone cannot solve the broader trust problem inherent in autonomous AI systems.
Varonis recommends four key safeguards:
Treat agent instruction files as strict, version-controlled policies rather than informal guidance.
Require approval before agents send messages to unfamiliar recipients, reducing the risk of automated phishing or data leakage.
Restrict access to connected systems based on the trustworthiness of the triggering source.
Require human review for high-risk actions such as credential sharing, financial transactions, or sensitive data transfers.
Both research teams ultimately advocate the same mindset. Varonis recommends treating AI agents as inexperienced employees with extensive system access but limited judgment, while Imperva describes them as authenticated executors that inherently trust incoming information.
Although vendors continue to introduce patches and protective controls, the fundamental challenge remains unresolved. AI agents derive their usefulness from acting on instructions, processing inputs, and helping users accomplish tasks. Those same characteristics also create opportunities for attackers, and the industry has yet to develop a universal solution.