SFTPGo CVE-2026-103028

Requires (1) a valid, authenticated SFTPGo account (PR:L) that has been granted the copy permission (PermCopy), and (2) a deployment that relies on file-pattern filters - denied_patterns or allowed_patterns - on that user, since the bug is that these filters were evaluated only on the copy destination and not the source. If no pattern filters are configured there is no confidentiality boundary to bypass. Exploitation is limited by the fact that home-directory boundaries, virtual-folder layout, per-directory permissions, access to other accounts, and administrative authorization all remain enforced, so an attacker can only expose pattern-restricted files that already lie within their own accessible filesystem scope; no anonymous/unauthenticated access is possible.

This is a genuine but modest-severity authorization flaw, not a high-priority emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N = 4.3 Medium) is internally consistent with the description: network-reachable, low-complexity, but requiring an existing authenticated account (PR:L) with the copy permission, and yielding only limited confidentiality impact (C:L) with no integrity or availability effect. All signals point the same way - this is a confidentiality-only privilege/filter-bypass usable by someone who already has a valid foothold. No EPSS score was provided in the input, and there is no CISA KEV listing and no public exploit code referenced, so there is no evidence of active or widespread exploitation. The primary caveat is that real-world risk is entirely conditional on configuration: the vulnerability only matters where administrators rely on denied_patterns/allowed_patterns file-pattern filters as a confidentiality control, and only an authorized user (not an anonymous remote attacker) can abuse it. Net: patch in the normal cycle; it is a legitimate access-control weakness but not a mass-exploitation threat.

An authenticated SFTPGo user who has been granted the copy permission but is denied access to certain files via denied_patterns (or restricted to allowed_patterns) issues a server-side copy of a restricted source file to a destination name that matches the allowed pattern. Because the pre-fix code only validated the destination path against the filters, the copy succeeds and the user then downloads the duplicate, reading contents they were never supposed to see; recursive directory copies can similarly reconstruct hidden/denied content under an allowed path. No public exploit code was identified at time of analysis.