Filament EUVD-2026-38394

The Filament panel must be accessible over the network without authentication - the standard deployment topology for a Filament login page. No special configuration is required beyond a default Filament installation; the vulnerability exists in the default state across all affected versions. Exploitation is limited to writing files to temporary storage only - attackers cannot control final file paths, read existing data, or achieve code execution through this vector alone. The attack is further constrained by any reverse-proxy-level request size limits or rate limiting the operator has configured, and by the application's underlying filesystem or object storage quota. Exploitation requires no authentication (PR:N confirmed by CVSS vector) and no user interaction.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L yields a base score of 6.5, accurately reflecting a low-complexity, network-accessible, unauthenticated attack with limited impact: no confidentiality breach, low integrity impact (arbitrary writes to temp storage), and low availability impact (disk exhaustion). There is no CISA KEV listing and no public proof-of-concept exploit identified at time of analysis, placing this at lower operational urgency than the CVSS score alone might suggest. The primary real-world risk is a denial-of-service via disk exhaustion or a financial impact via inflated cloud storage billing - neither of which results in data exfiltration or code execution. The attack is trivially automatable (AV:N/AC:L/PR:N) meaning any internet-facing Filament panel is a viable target for opportunistic storage exhaustion attacks. Defenders with rate-limiting or upload-size restrictions at the reverse proxy or WAF layer have meaningful compensating controls, reducing practical risk further for well-hardened deployments.

An unauthenticated attacker scripting repeated multipart POST requests to the Filament panel's login endpoint (or any other publicly accessible schema endpoint) can write arbitrarily large files into the application's configured temporary storage directory. By automating this at volume, the attacker can exhaust available disk space on the server, causing application outages, or accumulate significant charges on cloud object storage bills. No public proof-of-concept has been identified at time of analysis, but the attack requires no specialized tooling beyond a standard HTTP client capable of multipart uploads.