- Package
- drupal/s3fs
- Fixed in
- 3.12.0
- Published
- Wed 28 Oct 2026, 17:33 Lisbon
In plain words
An attacker who can trigger multiple S3FS file operations in the same request could cause files to be uploaded with incorrect access permissions or corrupted through incorrect operation metadata. The flaw comes from upload context not being sufficiently isolated between separate operations.
Am I affected?
Look for drupal/s3fs and its version in composer.lock. The advisory lists 3.12.0 as fixed but gives no affected version range. Check whether an attacker can trigger multiple S3FS file operations in one request. Review s3fs.use_s3_for_private and s3fs.upload_as_private, and check whether the deployment uses hook_s3fs_stream_open_params_alter(), hook_s3fs_upload_params_alter(), hook_s3fs_copy_params_alter() or hook_s3fs_command_params_alter().
What to do
Check which version you have, then update to a fixed release for your branch (3.12.0):
composer show drupal/s3fs | grep versions
composer update drupal/s3fs
If your version constraint in composer.json keeps you below a fixed release, raise it first. Whether your configuration is affected, and the exact version ranges, are in the advisory itself.
If you cannot update yet
Some vectors are mitigated by leaving private:// takeover disabled with $settings['s3fs.use_s3_for_private'] = FALSE;, or enabling it only with $settings['s3fs.upload_as_private'] = TRUE;. Other vectors are mitigated if the deployment does not use any of the four hooks listed above. If both conditions have always been true, all currently known vectors are mitigated.
The advisory's description
S3 File System (s3fs) provides an additional file system to your Drupal site that stores files in Amazon's Simple Storage Service (S3) storage.
The module doesn't sufficiently isolate upload context between separate object(file) operations in the same request resulting in the potential for objects to be uploaded with incorrect access control list (ACL) entries or corruption through incorrect operation metadata.
This vulnerability is mitigated by the fact that an attacker must be able to trigger multiple file operations on S3FS.
Some vectors are mitigated by:
- Not enabling private:// takeover (
$settings['s3fs.use_s3_for_private'] = FALSE;) or only enabled with$settings['s3fs.upload_as_private'] = TRUE; - The deployment does not utilize
hook_s3fs_stream_open_params_alter(),hook_s3fs_upload_params_alter(),hook_s3fs_copy_params_alter(), orhook_s3fs_command_params_alter()
If both points above have always been true, all currently known vectors are mitigated.