CVE-2026-103028: SFTPGo source-side file-pattern filter bypass during copy operations
SFTPGo is an open source, event-driven file transfer solution. From 2.5.0 until 2.7.6, an authenticated user with copy permission can copy a source file denied by deniedpatterns or outside allowedpatterns to an allowed destination name because file-pattern filters are evaluated only on the destination. The user can then read the denied file contents. Recursive directory copies can reproduce restricted contents under an allowed path, and the hide policy is bypassed because files that appear missing to stat and directory listings can still be copied. Home-directory boundaries, virtual-folder layout, per-directory permissions, access to other accounts, and administrative authorization remain enforced. This issue is fixed in 2.7.6.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
SFTPGoto a version that resolves this vulnerability.Fixed in 2.7.6
Event History
Frequently Asked Questions
Which users and configurations are exposed?
The issue affects SFTPGo versions from 2.5.0 through 2.7.6 when a user has copy permission and source-side denied_patterns, allowed_patterns, or hide policy restrictions are relied upon to prevent access to file contents. The user must be able to copy the restricted source to a destination name that passes the pattern checks.
What data can an attacker access or copy?
An authenticated user can copy a source file that should be denied or outside allowed_patterns and then read its contents from the permitted destination. Recursive directory copies can reproduce restricted contents under an allowed path, including files hidden from stat operations and directory listings.
Does this allow access to other users' files or bypass directory isolation?
No. Home-directory boundaries, virtual-folder layout, per-directory permissions, access controls for other accounts, and administrative authorization remain enforced.
What is the remediation?
Upgrade to SFTPGo 2.7.6, which fixes the issue. Until upgrading, do not rely on file-pattern filters or hide policy alone to protect sensitive source files from users who have copy permission; restrict copy permission where feasible.
How can I determine whether a user may have exploited this issue?
Review whether affected users had copy permission and whether their accessible areas used denied_patterns, allowed_patterns, or hide policies to restrict source files. Look for copied files or recursively copied directories placed under destination paths permitted by those filters.