Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#44706 closed defect (bug) (duplicate)

Latest 4.9.7 wp_delete_attachment() security patch breaks deletion on 3rd party storage

Reported by: l3rady's profile l3rady Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9.7
Component: Filesystem API Keywords:
Focuses: Cc:

Description

We use AWS S3 to offload and store uploads on.

Previously we would hook into the wp_delete_file filter see what files need deleting and then delete the files from the S3 bucket.

The new security patch checks if the files exist on the local filesystem first and are in the right directory before even attempting to delete the files and subsequently firing the wp_delete_file filter. As our files are on a remote filesystem and not local, WordPress cannot see them locally and then doesn't attempt to delete the files. WordPress happily removes the record from the database but then leaves the files on S3.

The way it has been patched means that now we have to hook delete_attachment instead and reimplement a lot of code WordPress already has due to a lack of filters and actions around this patch.

would it be possible to put in a filter around the check for file existence so we can override the result by checking S3 if the file is there and then feeding that back to WordPress to allow the delete to happen?

Change History (6)

#1 @swissspidy
6 years ago

See also #39476.

#2 @SergeyBiryukov
6 years ago

  • Milestone changed from Awaiting Review to 4.9.9

#3 @l3rady
6 years ago

See also #44563

#4 @dibbyo456
6 years ago

DigitalOcean Spaces Sync also suffering from the same issue when "only keep in DOS" is used.

https://wordpress.org/support/topic/not-deleting-from-spaces-when-deleted-from-media-libray/

#5 @pento
6 years ago

  • Milestone changed from 4.9.9 to 5.0.1

#6 @pento
6 years ago

  • Milestone 5.0.1 deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #44563.

Note: See TracTickets for help on using tickets.