{
  "claim": {
    "argus_claim_ref": null,
    "attacker_control": "authenticated FTP user controls RNFR and RNTO path arguments",
    "claimed_surface": "network_protocol",
    "expected_impact": "access_control_bypass_file_rename_and_retrieval",
    "finding_id": "CVE-2026-35025",
    "id": "CVE-2026-35025-proftpd-rnfr-acl-bypass",
    "required_entrypoint_detail": "ProFTPD FTP server handling RNFR/RNTO commands; authenticated FTP session; Directory ACL with DenyAll-protected path; DefaultRoot/chroot disabled for the vulnerable proof",
    "required_entrypoint_kind": "network_service",
    "submission_reason": "cve_advisory_runtime_network_claim",
    "trigger_class": "ftp_command_sequence",
    "upstream_verdicts": {
      "cve_org": "PUBLISHED 2026-06-24",
      "nvd": "Undergoing Analysis; CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"
    }
  },
  "latest_description": "ProFTPD through 1.3.9b and 1.3.10rc2 contains an access-control bypass in the FTP RNFR command handler. An authenticated FTP user can prefix paths with /proc/self/root so unresolved symlink components in dir_canonical_path() cause dir_check() lexical path comparisons to miss configured Directory blocks. The expected runtime proof is a real ProFTPD FTP server with a user, a DenyAll-protected directory, and an FTP client flow that shows direct access/rename is denied but RNFR using the /proc/self/root-prefixed path allows rename and subsequent retrieval of protected file contents. DefaultRoot/chroot configurations are documented as not affected and should not be used for the vulnerable proof environment.",
  "product": "ProFTPD",
  "severity": "high",
  "status": "open",
  "summary": "ProFTPD ACL bypass via /proc/self/root path prefix in RNFR",
  "ticket_id": "CVE-2026-35025"
}