Media Uploader: Incorrect fallback error message when filename contains special characters (apostrophes)

[sflwa]

Description

When uploading a file with an apostrophe in the filename (e.g., "Men's Club.png"), the WordPress media uploader fails and returns a highly misleading error message:

"The server cannot process the image... Uploading a smaller image may help. Suggested maximum size is 2560 pixels."

In reality, the image dimensions are well below the 2560px threshold. The failure is caused by the apostrophe, but the UI defaults to the "Big Image" fallback error.

Steps to Reproduce

1. Prepare an image under 1000px wide, but name it with an apostrophe: test'image.jpg.
2. Upload via the Media Library (async uploader).
3. Observe the error message regarding the 2560px limit.

Expected Result

The error should accurately reflect a filename/sanitization issue, or WordPress should sanitize the filename before the upload attempt.

Actual Result

The user is told the image is too large, leading to unnecessary troubleshooting of image dimensions.

Context & Previous Tickets

While previous tickets such as #22694 and #41693 addressed the server-side failure of apostrophes, this ticket is a UI/UX defect report. This specific misleading error message is tied to the big_image_size_threshold logic introduced in WP 5.3, which didn't exist when the older tickets were triaged.

[hbhalodia]

Hi @sflwa, Thanks for the issue.

I have tried to reproduce the issue with WordPress version 6.9.1 and no plugins enabled. I am successfully able to upload the media with apostrophe. Can you please check if there are any plugins which would be interfering the behavior?

Below is the demo screencast for the same.

​https://app.godam.io/web/video/fb47i13930

Let me know if there is any other steps to reproduce the same?

Thanks,

[sflwa]

@hbhalodia Thank you for getting back to me. I just tested this on SiteGround (my secondary host) with nothing installed and it worked as you mentioned.

I then tested it on LiquidWeb/Nexcess (primary host) it flagged with the error as shown.

I also tested on a 3rd host and it worked.

I will reach out to LiquidWeb Support to see if they can help find the issue. I will report back here on what I find out.

[sflwa]

@hbhalodia -

Upon checking with LiquidWeb they identified that the file triggered a ModSecurity block and I guess based on how it failed it caused the server timeout error.

I guess my follow-up question to the ticket / WP is.... Is there a way to detect how/what fail happened and adjust the error message.

At least with a PDF you get

Unexpected response from the server. The file may have been uploaded successfully. Check in the Media Library or reload the page.

[hbhalodia]

Hey @sflwa, Thanks for the update.

Could you please provide the exact file that you are trying to upload? I can check on my end and will verify the exact cause if that is the case happening.

Thanks

[sflwa]

Screen Capture - PNG of Comment

[sflwa]

Screen Capture - PDF of comment

[sflwa]

@hbhalodia — I’ve uploaded a PDF and a PNG for testing. Following up on this, I’ve coordinated with LiquidWeb, and they provided the Apache/ModSecurity logs below.

While this appears to be an environment-specific interaction, it highlights a significant "silent failure" in how WordPress handles server-side interceptions. When ModSecurity triggers a 403 on async-upload.php, the UI doesn't provide enough context for a developer to differentiate between a core bug, a plugin conflict, or a server-level security block.

I believe Core would benefit from more robust error detection or descriptive reporting for these types of edge cases. It would prevent developers from chasing logic bugs when the issue is actually a resource-level denial.

Server Logs:

[Wed Feb 11 20:19:05 2026] [mime_magic:error] [pid 1238722:tid 140528628782656] [client #.#.#.#:0] AH01512: mod_mime_magic: can't read `/home/path/html/wp-admin/async-upload.php', referer https://domain/wp-admin/upload.php

[Wed Feb 11 20:19:05 2026] [-:error] [pid 1238722:tid 140528628782656] [client #.#.#.#:0] [client #.#.#.#] ModSecurity: Access denied with code 403 (phase 2). String match "on" at TX:anomaly_score_blocking. [file "/etc/httpd/modsecurity.d/modsecurity_crs_49_inbound_blocking.conf"] [line "54"] [id "981176"] [msg "Anomaly Score Summary (General: 9/5, Nexcess_Custom: 0/5, SQLi=0/15, XSS=0/30)"] [severity "CRITICAL"] [hostname "HOST"] [uri "/wp-admin/async-upload.php"] [unique_id "aYzkOdK2rNouI2UOnld2YgAAAIY"], referer https://domain/wp-admin/upload.php

[sflwa]

Just providing an update from LiquidWeb - So I'll have to wait and see if they can adjust it based on their system, if not as I mentioned if core can provide different messages based on the server response vs the generic error message I think that would be great.

The filename sanitization has been implemented for security purposes.
Since allowing special characters in uploaded file names would require a platform-wide change, our Operations team is currently reviewing and testing the existing configuration to assess the feasibility of permitting such uploads.
We will provide you with further details as soon as we receive an update from the team.