PHP2Shell and WordPress Upload Errors
WordPress images suddenly will not upload? Seeing a 403 error, a spinning form, or “The server cannot process the image”? During the October 2026 PHP security emergency, those symptoms can be the side effect of a hosting provider restricting risky requests. They need investigation, but they do not automatically mean your website has been hacked.
At Grover Web Design, our response began before the emergency patch was available. By 3:28 a.m. Eastern on October 21, we had temporary upload restrictions in place and had notified a client about what to expect. That was more than six hours before the scheduled 10 a.m. PHP security release.
Here is what happened, why some WordPress features stopped working, and what business owners should ask their hosting provider to do next.
What PHP2Shell means for your WordPress website
PHP is part of the server software that runs WordPress. On October 21, 2026, the PHP team released emergency updates addressing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, widely called PHP2Shell. Both were rated 9.2 under CVSS v4.0.
These flaws can allow an attacker to execute code without logging in. PHP’s advisory identifies installations serving web requests as at risk, including PHP-FPM, Apache mod_php, and other common configurations. Exploitability varies by environment. See the official PHP security advisory.
This became an international operational issue. Reuters reported precautionary website shutdowns affecting government and other organizations. Cloudflare also announced protections for the vulnerabilities. Businesses of every size had reason to ask who was managing their underlying server software.
Why updating WordPress alone does not fix this issue
The vulnerability is in PHP itself. Updating a WordPress plugin or theme does not replace that server runtime.
PHP’s out-of-memory vulnerability advisory describes a demonstrated Apache mod_php attack that can occur before application code begins. That helps explain why a WordPress login screen, an absent upload form, or a plugin-level check cannot be treated as a complete defense.
The second advisory concerns stale internal state that can persist between requests handled by the same worker. Its attack paths extend beyond a simple “bad upload” explanation. Blocking uploads was an early exposure-reduction step; it was never a substitute for installing the fixes.
How GWD responded before the patch was available
Our internal chat shows Arif identifying the emerging PHP risk overnight, alerting the team, and deploying a temporary restriction on multipart uploads. These are requests commonly used to send files from a browser to a server.
By 3:28 a.m. Eastern, his client notice explained the protection, the features it could interrupt, and the plan to apply the PHP update and test uploads. We also offered a way for that client to send urgent files to our team for help.
As the morning continued, Donny, Arif, and Shakeel worked through reports involving publishing, media uploads, and portal access. In one portal, Arif identified a login form using multipart requests even though it did not need to upload a file. He changed that form to a standard submission so the upload restriction would no longer block login.
That is the practical value of active website management: understanding the security issue, communicating the tradeoffs, and tracing the effect on the tools a business actually uses.
Our morning response also included tracking the official PHP release and the corresponding Docker image work. The Docker PHP security-update pull request explains that merging source changes is followed by additional publication and build steps. A patch announcement and a patched running website are separate milestones.
October 21 response update: During our morning response, we were tracking patched container availability and handling affected workflows. Existing GWD clients can contact us for the current patch and testing status of their specific site.
October 22 deployment update: GWD has confirmed that all sites in our hosting cluster are patched. This deployment update is separate from the initial response timeline above. It does not certify that every site’s business workflows have completed testing; contact us for the upload, form, login, and checkout testing status of your specific site.
Why WordPress uploads and forms may stop working
We received reports of image-upload errors, publishing failures, and forms that appeared to keep loading. A broad multipart restriction can affect more than the Media Library because some ordinary forms use the same request format.
One image-upload report included the message “The server cannot process the image.” The user had already tried smaller images, different filenames, JPEG instead of PNG, and multiple browsers. When the request is blocked at the server, those changes may not address the cause.
- Media uploads fail: Ask whether an emergency upload restriction is active before repeatedly resizing or converting the file.
- A form or portal login hangs: Have the developer check the failed request and server logs, including whether the form uses multipart submission.
- Publishing or saving fails: Record the exact error and action. Different editors and integrations can behave differently under the same server rule.
- The public site still loads: Test the business workflows too. A working homepage does not prove that uploads, forms, or checkout work.
These symptoms have other possible causes. Timing alone does not establish PHP2Shell as the explanation for a particular error, and a protective block is not evidence of a successful intrusion.
Which PHP versions contain the security fixes
The PHP project released these fixes on October 21:
| PHP branch | Security release |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
Confirm the applicable fixed release or a documented vendor backport with your host. PHP 8.1 and older no longer receive official project releases; vendor support or a supported-version upgrade needs to be addressed separately. The PHP team states that configuration mitigations do not fully resolve these vulnerabilities.
What to ask your hosting provider today
Send your provider your website address, the time the problem began, and the exact error. Then ask:
- Is the PHP runtime serving this website patched for both CVEs? Request the running version or the vendor advisory identifying the backported fix.
- Are temporary restrictions affecting my site? Ask which features are affected and who will verify them before restrictions are removed.
- Have the updated services actually been deployed? For containers, ask for confirmation of the running image and restarted or replaced workers, rather than only an image download.
- Have my important workflows been tested? Include image uploads, editor saves, lead forms, customer logins, and checkout where applicable.
- Is there evidence of compromise? If suspicious activity exists, ask for log preservation and an investigation. Restoring functionality alone does not answer that question.
Do not disable security controls or restore an older PHP version simply to make an error disappear. Have the hosting and development teams agree on a path that addresses both the vulnerability and the affected workflow.
What proactive WordPress management looks like
Our response started with an overnight technical alert and moved into client communication and targeted troubleshooting. The timestamps make that tangible. We were already taking action while the official release was still pending.
GWD’s website maintenance and support brings hosting, development, updates, and troubleshooting into the same conversation. That matters when a problem crosses the boundary between a server setting and a custom business application.
Use our WordPress security and emergency response guide to assign responsibilities and plan the next response. Once the immediate issue is addressed, the Grover Performance Index can support a separate review of website performance. A performance score does not verify that a security patch is installed.
Frequently asked questions
No. An upload error can come from a protective rule, a resource limit, or another server problem. Have your host identify the cause and review relevant logs.
The PHP update normally belongs to the hosting environment. A developer may also need to repair affected forms or integrations and test the website afterward.
If your host confirms an upload block is active, smaller files may still be blocked. Ask for the site’s status and an approved way to handle urgent content.
Yes. Contact us with your website address and the problem you are seeing. We can assess the work needed, coordinate with your provider, and discuss ongoing management.
Need help with PHP or WordPress errors
If uploads are failing, a customer portal is stuck, or your host has not explained its PHP2Shell response, contact Grover Web Design for a website review. Tell us your URL, current host, and the features affected. Do not include passwords in the inquiry.
We work with businesses across the United States. We can help you understand what needs fixing and put a clear plan around it.
Talk with Donny about PHP and WordPress errors.
GWD can review your hosting status, troubleshoot affected uploads and forms, and coordinate the testing your business workflows need.
We can’t solve your problem if you don’t tell us about it!