In SFTP Gateway version 3, there is a critical bug and security issue where one SFTP user can (on rare occasion) see the files of another SFTP user.
This bug applies to SFTP Gateway versions
3.3.1. The fix for this bug was released in version
We recommend all customers running version 3 to upgrade to
3.3.2. This can be accomplished quickly using the in-place upgrade script, specifically migrating to
How to spot the bug
You may receive a report from an SFTP user that they briefly saw files they didn't recognize in their SFTP client. Or, you might have an SFTP user that automates the upload of many files, and some of those files have mysteriously spilled over into other users' Home Directories.
In SFTP Gateway version 3, there is a bug where one SFTP user can sometimes see the files of another. This issue is both intermittent and infrequent, so it might not happen when trying to reproduce it manually.
When SFTP user A logs in, he normally sees files in his Home Directory. But under rare circumstances, he will see a different Home Directory belonging to SFTP user B.
This bug is short-lived, because SFTP software clients tend to close their connections when idle. So SFTP user A will likely go back to seeing his own files when refreshing the SFTP client after some time elapses.
What causes the issue
There's a bug in our underlying Java code where the file permission policy references the file system. This can result in one SFTP user logging in, and inheriting some other user's file system.
This issue seems to happen when two SFTP sessions are instantiated at the same moment. This may explain why the issue happens infrequently, but tends to be reported by customers with SFTP clients automating file uploads.
In order to reproduce the issue reliably, this involves automating two SFTP clients that repeatedly connect simultaneously. And even then, it takes multiple attempts to trigger the issue.
How to fix the issue
This bug is fixed in the latest version of SFTP Gateway, version
If you are on version 3.x, you should upgrade to version
3.3.2. We recommend using our migration process, which is covered in this article.
Most customers prefer an in-place upgrade. To make things slightly easier, we have written an in-place upgrade script, specifically for migrating to