vsftpd CVE-2026-119567

Exploitation requires that the vsftpd server be explicitly configured with cmds_denied (or an equivalent cmds_allowed restriction) that blocks commands such as RMD, MKD, CWD, PWD, or CDUP - without such a command-filtering configuration there is nothing to bypass. The attacker must hold valid FTP credentials (PR:L, authenticated per the provided vector). Limiting factors: it is useless against default installations that do not use cmds_denied, it only grants the specific operations the admin tried to block (here primarily integrity impact such as directory deletion/creation), and it affects only vsftpd through 3.0.5.

This is a low-severity, low-priority issue rather than a high-CVSS-but-low-real-risk case: the CVSS 4.0 base score is only 2.3, and the signals are internally consistent. The vector (CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N) requires an already-authenticated low-privilege FTP user (PR:L), a non-default attack requirement/configuration (AT:P/AC:H), and yields only limited integrity impact (VI:L) with no confidentiality or availability loss. The vuln.today decision label is 'monitor', which aligns with the low score. This is NOT in CISA KEV (status: no active exploitation confirmed), so exploitation status is 'no public exploit identified at time of analysis', though research references from abraxaslabs and VulnCheck describe the bypass technique in detail - a public technical write-up exists but is not verified as working exploit code. EPSS score is NOT provided in the input, so probabilistic exploitation likelihood cannot be factored in and should not be assumed. The SSVC-style signals (monitor, no KEV, authenticated and configuration-dependent) all point to low real-world urgency: this matters only to deployments that actively rely on vsftpd's cmds_denied/cmds_allowed command filtering as a security control.

On a vsftpd server (≤3.0.5) configured with cmds_denied to block directory operations such as RMD/MKD, an authenticated FTP user issues the RFC 775 X-prefixed alias XRMD instead of RMD. Because the cmds_denied check matches literal tokens, the alias is not recognized as a blocked command and the directory deletion proceeds, defeating the configured restriction. No public working exploit is identified, but the technique is documented in the referenced research.