Uploaded files with quote marks in the filename are undisplayable in MS

[simonwheatley]

If you upload a file with quote marks in the filename, e.g. "Test".jpg, WordPress records the filename as %22test%22.jpg but the file is called "Test".jpg (on 'nix-like systems anyway) so is undisplayable.

I'm unsure about the implications (security and otherwise) of my suggested patch (attached), so please give feedback. (I guess the other approach would be to retain the url-encoded characters and ensure that the file is named with the URL encoded version of the filename.)

[simonwheatley]

URLDecode characters before saving to WP meta data

[mdawaffe]

sanitize_file_name() should be stripping quote marks, and works for me.

Please reopen with more details. What browser, what OS, what server OS, PHP version, etc.?

[mdawaffe]

markjaquith just repro'd. Flash uploader works fine, the browser uploader does not.

[mdawaffe]

This looks like a WebKit bug that we can't work around.

I have a file named z"d%22e.jpg.

Uploading from FF:

-----------------------------178448449274243042114807987
Content-Disposition: form-data; name="async-upload"; filename="z"d%22e.jpg"
Content-Type: image/jpeg

Uploading from Chrome:

------WebKitFormBoundaryAUCJ2qQRMOXB3IQL
Content-Disposition: form-data; name="async-upload"; filename="z%22d%22e.jpg"
Content-Type: image/jpeg

Chrome is clearly doing things wrong. FF works, but I would have thought the double quote should have been slashed.

[mdawaffe]

PoC

[mdawaffe]

16191.diff is a Proof of Concept workaround for filenames with double quotes in them.

1. Populate POST variable via JS with file's real name.
2. Use wp_handle_upload_prefilter to fix the $_FILES item.

[mdawaffe]

Cleanup, Docs

[iseulde]

This is still an issue after 3.5, image is now saved as %22Test%22.jpg, but is not found when trying to access is. Maybe remove the double quotes just like single quotes are removed (Test.jpg)?
See #22694.

[mordauk]

16226.patch on 16226 may resolve this.

[desrosj]

#16226 was fixed in 4.4. Can someone test this to see if the behavior still persists?

[donmhico]

This is my first time to be involved so please be patient and guide me through. @desrosj

I wasn't able to replicate the problem but I noticed something when testing on different browsers.

I'm on macOS Mojave (10.14.5)

What I did: Uploaded an image with the name "512x512_RED."png via the Media Uploader and inside Gutenberg editor.

Browser: Google Chrome
Results:
File was uploaded with filename - 22512x512_RED.22png.png
Post title - 512x512_RED.png
post_meta_key (_wp_attached_file) - 22512x512_RED.22png.png
Renders properly inside a post.

Browser: Firefox
Results:
File was uploaded with filename - 512x512_RED.png.png
Post title - "512x512_RED."png
post_meta_key (_wp_attached_file) - 512x512_RED.png.png
Renders properly inside a post.

Browser: Microsoft Edge (Dev build for Mac)
Results:
File was uploaded with filename - 22512x512_RED.22png-2.png
Post title - 512x512_RED.png
post_meta_key (_wp_attached_file) - 22512x512_RED.22png-2.png
Renders properly inside a post.

Browser: Safari
Results:
File was uploaded with filename - 22512x512_RED.22png-4.png
Post title - 512x512_RED.png
post_meta_key (_wp_attached_file) - 22512x512_RED.22png-4.png
Renders properly inside a post.

How it saves in Firefox is different than the rest of the browsers. I'm not sure if it's something critical. But nonetheless, the image with double quotes in filename displays properly.

[sncoker]

At #WCUS Contributor Day. I can confirm @donmhico's observations.

The patch does not apply cleanly to the trunk.

Operating System: Mac OS Mojave

Browser: Firefox
Post Title: top_”bg_header”
Filename: top_bg_header.jpg
Image renders correctly on the attachment page.

Browser: Chrome
Post Title: top_bg_header
Filename: top_bg_header.jpg
Image renders correctly on the attachment page.

Browser: Safari
Post Title: top_bg_header
Filename: top_22bg_header22.jpg
Image renders correctly on the attachment page.

[SirLouen]

According to the last reports, it seems that this is not reproducible. I will issue a close for a worksforme

Also patches are not applying

I will leave it if anyone wants to issue a last reproduction test and see if definitely not reproducible any more and close this report.

[jonsurrell]

As of 6.9.4, the original issue seems to be fixed.

Uploading a file like "css".png results in a filename like 22css22.png on the server and a matching URL. The file remains accessible.

There does seem to be a related issue described in #comment:9. "css".png becoming 22css22.png does not seem correct or desirable. I would expect a result like css.png or a similar name on the server.

The main issue is fixed and this ticket can likely be closed since doesn't seem to have been an issue since WordPress 4.4. However, it would be nice to open a ticket for the remaining filename issue.

[sgastard]

Fix quote in file name

[binsaifullah]

Reproduction Report

I tested this on trunk (7.2-alpha) to follow up on comment:10 and comment:11.

Environment

• WordPress: 7.2-alpha (trunk)
• PHP: 8.3 (Playground-based local server)
• Browser: Chrome
• OS: macOS

Results: the original bug is fixed

Chrome sends " as %22 in the multipart filename. I uploaded through both the media library (async-upload.php) and the REST API (POST /wp/v2/media, the block editor path):

File	Path	Saved file	Title	URL
"css".png	REST	22css22.png	%22css%22	200 ✅
"css".png	async-upload	22css22-1.png	css	200 ✅
quote"in"middle.png	REST	quote22in22middle.png	quote%22in%22middle	200 ✅
it's.png (control)	both	its.png	it's	200 ✅

Every file is stored and displays correctly, so the bug described in this ticket no longer reproduces. It was fixed by #16226 in 4.4, and Tests_Formatting_SanitizeFileName::test_replaces_percent_sign() (@ticket 16226) now covers it.

About patch-16191.diff

Adding urldecode() at the top of sanitize_file_name() changes the result for every filename, not only uploads, and it fails 3 of the 20 existing tests in tests/phpunit/tests/formatting/sanitizeFileName.php:

• test_replaces_percent_sign: the test asserts a%22b.jpg → a22b.jpg, which is the intended #16226 behavior.
• test_replaces_spaces: urldecode() turns + into a space, so plus+space.jpg → plus-space.jpg instead of plusspace.jpg. Likewise c++.pdf → c-.pdf instead of c.pdf.
• test_removes_special_chars.

rawurldecode() avoids the + problem but still fails 2 of those tests. Either way it's a behavior change that should be decided deliberately, not a refresh of this patch.

Where the remaining issues are tracked

1. Filenames: "css".png is saved as 22css22.png. This is already tracked in #66125, which was opened after comment:11.
2. REST uploads keep the encoded name in the title (%22css%22). The REST attachments controller builds the default title from the raw $files['file']['name'] and doesn't use sanitize_text_field() as media_handle_upload() does. I opened #66226 for this, with a fix and unit tests in ​PR 13888.
3. Side note: in sanitize_file_name(), % is removed as a special character *before* str_replace( array( '%20', '+' ), '-', ... ) runs, so the %20 part of that line can never match (my%20file.jpg becomes my20file.jpg). This looks related to #50855.

Since the original issue here is fixed, I agree with closing this ticket (worksforme or duplicate of #16226). The remaining work can continue in #66125 and #66226.