PHP2Shell / A clearer plan for your website
PHP2Shell.Know what’s
under your
website.
A working website can still have an unanswered security question.
PHP2Shell exposed flaws in software that runs behind many websites. Start with the facts about your own setup, a named person responsible for updates, and evidence that the fix is actually running.
- 01 / Website & pluginsWho updates the site?
- 02 / PHP runtimeIs the patched build running?
- 03 / Hosting & recoveryWho owns the next step?
An owner’s guide to scope, evidence and next steps. This page does not scan your website.
01 / Get the whole picture
Look past the
update button.
PHP is software that helps a website build pages and process requests behind the scenes. It can be part of WordPress, another content system, or a custom application. Its updates may belong to your host rather than the person editing your pages.
“WordPress is up to date”
doesn’t answer
“Is our PHP patched?”
Under affected conditions, the PHP2Shell flaws can let an attacker run code on the server without signing in. Depending on the website’s permissions, that could mean altered pages, exposed information or disrupted service. It does not mean every PHP website has been compromised.
A useful review separates three questions: Does this environment use affected software? Has the provider applied the relevant fix? Is there any evidence of earlier compromise? A patch answers only part of that story.
Our PHP2Shell blog guide explains the news and immediate owner actions. This resource goes deeper into the review itself: what to include, what evidence to request, and how to make sensible decisions afterward.
Your actual website stack
Identify the content system, web-serving PHP runtime, host, connected services and who maintains each one. Include staging sites, subdomains and forgotten test installations. A command-line PHP version may differ from the one serving visitors.
Proof of the patch
Ask for the installed package or vendor build, the relevant security notice and confirmation that serving processes were restarted where needed. Some vendors backport fixes while keeping an older-looking version banner. A screenshot of a version number alone may be inconclusive.
Recovery and business functions
Check who can restore a backup, what it covers and when restoration was last tested. After an update, verify the features customers depend on: forms, bookings, checkout or account access, as applicable. Coordinate safe tests with the owner of each system.
Ownership after the headline
Document who approves updates, who applies them and how completion is confirmed. Include administrative access, supported dependencies and a recovery contact. A one-time fix should lead to clear ongoing responsibility, not another unknown.
02 / A practical sequence
From a question
to an answer.
Keep immediate patching separate from long-term platform decisions. If you engage SDM, agree on access, scope, deliverables and price before any work begins.
- Identify
Map the setup
Start with the site, its hosting account and the people responsible. List the environments and integrations in scope. Unknowns stay visible instead of being treated as a pass.
Useful outputA stack and ownership inventory - Confirm
Verify the evidence
Compare the web-serving runtime and vendor package against the advisories. Request hosting confirmation. Review the separate October 23 issue as its own item, with its own applicability and mitigation.
Useful outputPatch evidence and unresolved questions - Prioritize
Address what matters
Coordinate necessary updates with the responsible host or developer. Confirm backup and recovery options first, then check essential customer journeys. Suspected compromise calls for evidence preservation and qualified incident response.
Useful outputAn agreed action list and validation record - Assign
Make upkeep explicit
Record a named owner and follow-up date for remaining actions. Consider changes to the stack only after the immediate issue is handled. Every proposed platform still needs a maintenance and recovery plan.
Useful outputResponsibilities and next steps in writing
These are suggested review outputs to agree in scope. They are not a promise of a completed audit, penetration test, incident-response service or an ongoing service level.
03 / Bring better questions
You don’t need to
be the developer.
You do need to know who can give you a clear answer. Use this checklist to prepare a conversation with your existing host, developer or SDM. Checking a box records your preparation, not your website’s security.
Kept in this page’s memory only. Nothing is sent or stored. Your answers do not change any website settings.
04 / Ask for something concrete
Confidence needs
a paper trail.
A reassuring answer is useful. A verifiable answer is better.
- “Everything is updated.”
- “Our firewall handles it.”
- “The version looks old, so we must be exposed.”
- “The site loads, so we’re fine.”
- The specific package or backport and the host’s patch confirmation.
- The patch status as well as any additional firewall protection.
- The vendor build and its security notice, checked together.
- Documented changes, essential-function checks and a recovery plan.
A web application firewall can provide another layer of protection. It does not replace the PHP fix. A patched runtime also cannot prove that no earlier breach occurred. Read Cloudflare’s guidance.
05 / Choose technology deliberately
Fix today’s issue.
Plan tomorrow’s site.
One advisory does not automatically mean you need a rebuild. It is a reason to examine whether your website’s complexity, ownership and upkeep still fit your business.
06 / Keep the details straight
Two dates.
Separate checks.
Share this reference with the person maintaining your hosting. Confirm current vendor guidance before applying changes.
Official PHP release noticeCVE-2026-109618 and CVE-2026-109619 were addressed in these releases. An equivalent documented vendor backport may also provide the fix.
| PHP branch | First fixed release |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
The software serving web requests is what matters. Do not assume PHP-FPM or another serving mode is automatically safe; applicability and exposure depend on the environment.
Straight answers / Before you decide
Less uncertainty.
Better questions.
Details about scope, platforms and practical next steps.
Is this a WordPress security review or a hosting review?
The useful scope crosses both. WordPress is the visible content system; PHP may be managed in the hosting environment. A review should identify who maintains each layer and verify applicable fixes. Custom PHP applications can share the same runtime risk. Agree which sites, environments and connected services are included.
Can you tell whether my site is affected just from its address?
A public URL alone may not reveal the actual runtime, vendor patch or configuration. This page does not test your site. Reliable confirmation may require information from the host or authorized access agreed in advance. Do not send passwords, hosting credentials, customer data or private logs through a general inquiry form.
Does updating plugins fix PHP2Shell?
Plugin and theme updates matter, but they do not replace updating affected PHP packages on the server. Ask your host to confirm the relevant patched package is actually serving the site. Also ask about the separate October 23 informational advisory; it is not the same as the October 21 fixes.
Our host shows an older version. Does that mean it is unpatched?
Not necessarily. A hosting vendor may backport a security fix while retaining an older version label. Ask for the exact package or build, its security notice and confirmation it is running. Conversely, an updated dashboard alone does not prove that every environment and serving process received the fix.
Do we have to leave WordPress?
Not simply because of this advisory. Address immediate exposure first. A platform decision should consider the business’s needs, supported software, unnecessary complexity and who owns maintenance. Custom PHP is not immune to PHP flaws, and a non-PHP site still has other security responsibilities.
What should we expect from a scoped review?
Agree on outputs before work starts. Useful examples include a stack and ownership inventory, patch evidence, unresolved questions, prioritized actions and a validation record. Price, access, timeline and ongoing support are separate agreements. A review is not automatically a penetration test or a guarantee that a site has never been compromised.
What if we suspect an existing breach?
Contact your host and a qualified incident-response provider promptly. Preserve logs and other evidence and coordinate containment and recovery with the responsible specialists. Applying a patch or rebuilding a website does not, by itself, establish that earlier access has been removed or that data was unaffected.
What can I prepare before talking to SDM?
Bring your public site address, host name if known, who currently maintains it and any non-sensitive update confirmation from your provider. Note the forms, bookings, payment flows or other functions that matter to customers. Keep passwords and private customer information out of the initial conversation. SDM’s existing contact page is linked below.
The people behind the work
Technical thinking.
Business perspective.
Mathew Torres is the CTO of Strategic Digital Media. His background includes earning CompTIA Security+ certification and working in a military Cyber Defense Operations Center. That background informs a practical focus on software choices, ownership and upkeep.
Meet the SDM teamStart with the right question
Who’s looking
after your stack?
If you’re unsure who maintains your website’s PHP and hosting, ask Strategic Digital Media about reviewing your stack and maintenance plan. We can discuss what needs checking and agree on a scope before work begins.
Discuss a website reviewUses SDM’s existing contact page. No automatic scan, submission or commitment.
Think your site has already been compromised? Contact your host and a qualified incident-response provider promptly. Preserve logs and evidence; do not rely on a website rebuild or a patch alone as proof of recovery.
Read the original guidance
Sources & context.
Last checked October 24, 2026. Security guidance can change. Confirm the latest information with your provider.
Read our PHP2Shell news explainer- PHP: October 21 security releases
Original PHP2Shell fixes and version numbers.
- The PHP Foundation: security release context
Why the PHP runtime needs attention.
- PHP: October 23 informational advisory
The separate session upload-progress issue.
- WordPress: Site Health screen
Where owners can find server information.
- Cloudflare: PHP vulnerabilities and WAF protection
Additional protection does not replace patching.
- CISA: response and recovery guidance
Preserving evidence and planning recovery.