PHP2Shell: How the Critical PHP Flaw Affects WordPress and Laravel Sites, and What to Do Now

In brief: On 21 October 2026 the PHP project released emergency security versions for two critical flaws that can allow remote code execution (RCE) without authentication: CVE-2026-109618 and CVE-2026-109619. The flaws are known as “PHP2Shell.” Every PHP installation that serves web requests (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed) is at risk; that means WordPress, Drupal, Joomla, Magento, Laravel and custom PHP applications can be affected depending on the PHP version they run. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. According to the PHP team the only complete fix is updating; temporary settings do not make a server safe. This article relies on sources published as of 23 October 2026; the situation is moving fast, so check the official sources below.

Last updated: 23 October 2026

What happened?

• 21 October 2026: The PHP project published a security advisory and fixed versions for two critical flaws and urged all users to update immediately (php.net announcement).
• The technical gist: after fatal errors such as out-of-memory (OOM), PHP can clean up a request's state incorrectly. This lets corrupted memory state be used by a later request and can open a path to code execution.
• Details leaked on 20 October, before the official release; according to security firm Patchstack, hosting providers reported active exploitation attempts. Amazon's threat intelligence team said attempts go back to 17 October (ABC News).
• Security firm Wiz published that it demonstrated unauthenticated code execution against current container images of WordPress, Drupal and Joomla (Wiz research).
• Some organisations took services offline as a precaution; reports mention Dutch government sites, some Japanese platforms and Moodle sites. The US National Security Agency (NSA) advised organisations using PHP to update immediately or take their systems offline until they could (TechCrunch).

Note: Sources credit different teams with finding the flaw (Wiz publishes its own research, while ABC names the US firm Calif). What they share is that AI models were used in the discovery; we cover what that means for businesses in a separate article.

Who is affected?

Because the problem is in PHP itself, it is independent of your application's code:

According to Patchstack's assessment the highest risk is in Apache mod_php setups, because in the demonstrated exploitation a single unauthenticated request is enough.

Which PHP versions are safe?

The PHP team also shared minimal source patches for 7.4, 8.0 and 8.1; but rather than compiling these yourself, moving to a supported version is healthier where possible.

7 steps to take today

1. Take inventory. List everywhere PHP runs: live sites, test/staging environments, Docker containers, old panels, forgotten sites an agency set up.
2. Find the version. On the server php -v; in your hosting panel, the PHP version screen. If unsure, ask the provider.
3. Update. Move to the fixed versions above or your provider's patched package. Try new versions in a test environment first; but don't postpone the update for days.
4. If you're on PHP 8.1 or older, ask your provider in writing about patch coverage; otherwise plan a move to 8.4 or 8.5.
5. If you're on shared hosting, ask your company in writing: “Have you applied the PHP2Shell patch, and which version are we on?”
6. If you can't update right away and the site is high-risk, put the site in maintenance mode or take it offline until you can. The PHP project shared some temporary settings for situations where updating isn't possible (e.g. session.upload_progress.enabled = 0 and certain memory/upload limit settings) but states clearly that they do not make the system safe. See the official announcement for details. Do not use RLIMIT_AS/RLIMIT_DATA for memory limiting; according to the announcement they can trigger the vulnerable allocation failure.
7. Stay away from unofficial “fix” plugins and copy-pasted snippets. Fake fixes circulate during incidents like this.

How do you know if you were attacked?

Warning signs recommended by Wiz and Patchstack:

• Unusual multipart (file upload) requests followed by memory-limit errors or repeated HTTP 500 responses
• Abnormally large or malformed PHPSESSID cookies
• Unexplained restarts of PHP worker processes

If you see these, assume compromise: rotate all secrets the server holds (database passwords, API keys, .env files, SMTP and payment provider keys) from a clean machine, review logs and consult a security specialist if needed. Wiz also showed that, even without code execution, the flaw can leak passwords, tokens and keys from process memory; so rotating secrets after patching is worth considering.

Is a WAF enough?

Cloudflare and other providers have released early rules; but these are extra protection, not a fix. In Patchstack's words the complete fix is only the update. A WAF rule may not catch not-yet-known variants of the flaw; Wiz also noted that other variants are likely.

What should you ask as a business owner?

Ask your software agency or hosting company in writing:

1. Which of our sites/applications use PHP, and in which version?
2. When will we move (or have we moved) to the fixed version?
3. Has monitoring and log review been done for this incident?
4. Will the secrets held on the server be rotated?
5. For urgent patches like this, is there a time commitment in your maintenance contract? We cover what maintenance and SLAs should include in our maintenance and support guide and general security measures in our security guide.

What do we do at Aktaş Digital?

Outdated components are one of the most common risks in web applications. For projects under maintenance, this means following urgent announcements like this one, identifying the affected components and giving the client a clear roadmap. In new projects we plan technology choice and the maintenance plan together from the start: see our tech stack selection guide. If you'd like an assessment of your current site's maintenance and security status, you can reach us through our quote form or our contact page; for related services see web applications.

Frequently Asked Questions

My site runs on WordPress; what should I do?

Updating WordPress itself does not close this flaw; the problem is in PHP. Confirm from your hosting panel or provider that your PHP version is one of the fixed versions.

I'm on shared hosting and can't update it myself.

The hosting company may manage PHP. Ask them in writing and find out when they will apply the patch. If the patch is delayed, consider taking your site offline temporarily or moving it from backup to another environment.

We use Laravel; is updating the framework enough?

No. The flaw is in the PHP runtime, not the framework. The PHP version on the server/container must be updated.

Is my Next.js site affected too?

Next.js applications do not use PHP and are not directly affected by this flaw. But PHP-based side services on the same server may be. This week also brought separate security updates for Next.js and Node.js: see our articles on Next.js and Node.js.

I've updated; do I need to rotate secrets?

If the system was exploited during the exposure window, the secrets held on the server may have been taken. Even if you haven't seen the warning signs, consider rotating them, especially high-value keys.

How current is this news?

The situation is developing quickly. This article relies on the php.net announcement and press/research sources as of 23 October 2026; check the official announcement before you decide.

Conclusion

PHP2Shell is an incident where the assumption “nobody is interested in my site” does not hold: an unauthenticated flaw affecting every system that runs PHP, reported to be tried in the wild. The first thing you can do today: find out which of your sites use PHP and in which version, then request the move to a fixed version in writing.