If your website runs on PHP, ask your hosting provider to confirm that it has applied the PHP2Shell security fixes. Updating WordPress, WooCommerce or Moodle alone does not confirm that the PHP software underneath has been patched.
PHP2Shell is the name given to two critical vulnerabilities disclosed in October 2026. The immediate response is to check the server, apply the relevant PHP update, and verify that the site still works. You do not need to understand server programming to start that conversation.
This guide was checked against the primary advisories on 26 October 2026. It covers the two original vulnerabilities and a later PHP follow-up that your host should also review.
What is PHP2Shell in plain English?
Think of your website as three connected layers. WordPress or Moodle is the application. Plugins and themes add features. PHP is the engine that runs the application on the server.
PHP2Shell affects that engine. Researchers reported ways for someone without a login to run code on an affected server or expose information in its memory. Their demonstrations included WordPress, Drupal and Joomla; the problem is not limited to those platforms. See the researchers' PHP2Shell explanation.
The two official identifiers are:
- CVE-2026-109618: a problem with how PHP handles running out of memory. In affected circumstances, its cleanup can use invalid data. The PHP security advisory explains the conditions and fix.
- CVE-2026-109619: information from one request can remain accessible after the memory belonging to it has been released. A later request can interact with that stale information. See the second PHP advisory.
You can have an updated website application and still need a server update. Equally, seeing “WordPress” or “Moodle” on a website does not establish that it is vulnerable. The installed PHP build, patches, configuration and running processes matter.
Does this affect WordPress, WooCommerce or Moodle?
For a WordPress website, check PHP with the host even if every plugin is current. A security plugin does not supply the PHP runtime update.
For a WooCommerce store, include checkout and payment integrations in the post-update checks. The practical concern is protecting the store while keeping orders, stock and customer communications working.
For a Moodle learning platform, involve whoever maintains the server. Moodle HQ's 22 October announcement described taking its own sites offline as a precaution, applying patches, and bringing them back. It urged self-hosted operators to arrange PHP patching immediately. That announcement does not establish the status of your school's separate installation.
At ValeoFX, our WordPress, WooCommerce and Moodle work involves the application and its hosting environment. Our Moodle production playbook explains why code, database, uploaded files and runtime need to stay aligned. That same discipline is useful during an urgent security update: make the server change, then test the tasks people rely on.
Which PHP versions contain the fixes?
The PHP project's advisories identify these first fixed upstream releases for the two original PHP2Shell CVEs:
| PHP branch | First fixed upstream release |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Check the official PHP release advisory and PHP changelog when making an update decision. Use a supported release compatible with your application.
A version number is only part of the evidence. Some hosting providers and Linux vendors backport security fixes: they add a patch to an older package without adopting the newest upstream version number. Red Hat explains why simple version comparisons can produce false alarms. Ask for the exact installed package and the vendor notice covering both CVEs.
PHP 8.1 and older no longer receive normal updates from the PHP project. Its advisory points operators to supported releases or documented vendor backports. Do not assume that an old branch is covered because your hosting account says “managed.”
The 23 October follow-up also matters
PHP subsequently published an informational advisory about session upload progress, referencing CVE-2026-115560. It describes a separate, unusual risk involving applications that switch session serialization settings at runtime.
PHP recommends disabling session.upload_progress.enabled until the next regular bugfix release; applications that never make that runtime switch can keep it enabled. Ask your administrator to review the advisory and apply the guidance appropriate to your setup. Meeting the table above is not a blanket certificate that every PHP security issue is resolved.
Check what you know about your site's exposure
Use the tool below to organize the information you have before contacting your host. It gives guidance from your answers. It does not scan your website, detect its PHP version, test an exploit, or confirm a vendor backport.
Platform exposure guide
Could PHP2Shell affect your website?
Choose your platform for an immediate first step. No scan, exploit test, or automatic platform detection is performed.
You can also open the PHP2Shell checker on its own page.
An unknown PHP version is a reason to request evidence. It is not proof that someone has broken into your site. Even when your host confirms a patched package, verify that the updated software is running on every relevant server.
What to ask your hosting provider
Send this in a support ticket:
Please confirm whether the PHP runtime serving my website has been patched for CVE-2026-109618 and CVE-2026-109619. Please provide the active PHP version and full package/build identifier, the vendor advisory if fixes were backported, and confirmation that affected web processes were restarted. Please also review PHP's 23 October session upload progress advisory, CVE-2026-115560, and confirm the applicable action.
Include your domain and any separate learning portal or store subdomain. Use the provider's private support channel. Do not attach passwords, database credentials, student records or customer exports.
Ask for a response tied to your actual hosting environment. A general announcement that updates are available does not confirm that your website has received them.
A practical update and verification checklist
Use this as a working checklist with your host or developer:
- List the installations. Include the live website, staging sites, old subdomains and separate portals. Record who maintains each one.
- Check recovery options. Confirm that current backups cover the database and uploaded files, and that someone knows how to restore them. For Moodle, include
moodledata. - Apply the correct PHP packages. The administrator should match the update to the operating system and application requirements, including required PHP extensions.
- Restart and verify. The researchers' upgrade guidance calls for restarting affected web services and long-running PHP workers. Verify the runtime serving web traffic; a terminal version alone may describe a different installation.
- Test real user tasks. Check WordPress login, forms and uploads; WooCommerce cart, checkout and payment callbacks in a suitable test flow; Moodle student login, course access, submissions and scheduled tasks.
- Record the evidence. Keep the package identifier, patch notice, change time and test results in the maintenance record. Review errors and unexpected behavior after the update.
The Moodle operational checklist offers useful recovery and verification checks. A PHP patch does not require a hosting migration, but it deserves the same care around backups and student access.
Can a firewall or plugin replace the PHP update?
No. PHP's guidance says temporary controls reduce specific attack paths and do not provide complete protection. Have your administrator assess any interim measures while arranging the patch.
Avoid copying emergency server settings from a social post. Changes to memory handling or upload limits can affect stability, store imports and assignment submissions. A configuration change needs an owner, a reason and a check that normal work still succeeds.
Common questions
Has my website been hacked if it uses PHP?
Using PHP does not establish compromise. Patch status and evidence of unauthorized activity are separate questions. If you see suspicious files, accounts or changes, preserve the available logs and involve your host or incident responder.
Is updating WordPress or Moodle enough?
Confirm PHP separately. An application update can be worthwhile without replacing the server runtime. Request confirmation for the actual domain and hosting account.
Should I move away from WordPress or Moodle?
A platform migration is a separate business decision. Address the affected PHP runtime now. Rebuilding a website is not the immediate remedy for these vulnerabilities.
What if I need help getting a clear answer?
Start with your hosting provider using the question above. If you need help coordinating the update and checking your site's workflows, see our website maintenance support or WordPress and WooCommerce development services. Bring the host's response so the next step can be based on evidence.
