agent-zero CVE-2026-51852

Exploitation requires network reachability to the agent-zero file-browser functionality that invokes save_file_b64, which accepts a user-controlled destination path and base64 content without normalization or validation; an attacker supplies traversal sequences (e.g., ../) to write outside the intended directory. Realistic limiting factors: the instance must be network-exposed, and exploitation presupposes the file-browser/web UI is reachable - if the deployment places authentication in front of the UI (not confirmed from the data), an attacker would first need valid access, so the input's PR:N should be validated against the actual default auth posture of versions 1.7-1.10.

Signals are mixed and point to a moderate, not urgent, priority. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) describes a trivially reachable network attack with no authentication or user interaction, which would normally elevate priority. However, EPSS is low (0.33%, 24th percentile), there is no CISA KEV listing, and no SSVC decision data was provided, which together argue against widespread or automated exploitation today. There is also a material data conflict: the method named (save_file_b64) is a base64 file-WRITE primitive, so the real-world impact should be integrity/arbitrary-file-write, yet the input vector encodes C:H/I:N/A:N (confidentiality-only) - verify with the vendor/advisory, because a write-based traversal that is scored as read-only likely understates integrity impact and the eventual code-execution potential. A GitHub issue and a public gist are referenced, suggesting exploit or proof-of-concept detail is publicly circulating. Net: a genuine, easily-reachable flaw in the affected product, but low current exploitation pressure and a small deployment footprint keep it below top-tier priority - patch promptly but not as an emergency.

An attacker with network access to an exposed agent-zero instance sends a crafted request to the file-browser save_file_b64 endpoint containing a base64 payload and a path such as '../../..' to escape the intended upload directory, writing an attacker-controlled file to an arbitrary filesystem location. A referenced public gist appears to document the technique, lowering the barrier to reproduction. Depending on where the file lands (e.g., a startup script, config, or web-served path), this can escalate from file write to code execution.