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.