PHP2Shell: What You Need to Know About Today’s Critical PHP Vulnerability

If your website or web application runs on PHP, update it today. On October 21, 2026, the PHP security team released patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now widely known as “PHP2Shell.”

These flaws let an attacker run code on a web server with a single request, no login required, before any of your application code even runs. PHP rates both at 9.2 out of 10 for severity. Exploit code is already circulating, and Cloudflare reports early attacks in the wild. Researchers estimate well over a million internet-facing servers could be exposed.Why this is urgent

If an attacker uses this flaw on your site, they can effectively take control of your web server. That means they could steal customer data, grab the passwords your site uses to connect to its database and other services, plant malware on your pages, or quietly leave a back door to come back later. Your site’s own login and security settings don’t protect against it, because the attack happens before your site’s code even runs.

If your site shares a server with other sites or applications, they may be at risk too. One compromised site can often give an attacker access to everything else on the same server.

Why this is urgent

If an attacker uses this flaw on your site, they can effectively take control of your web server. That means they could steal customer data, grab the passwords your site uses to connect to its database and other services, plant malware on your pages, or quietly leave a back door to come back later. Your site’s own login and security settings don’t protect against it, because the attack happens before your site’s code even runs.

If your site shares a server with other sites or applications, they may be at risk too. One compromised site can often give an attacker access to everything else on the same server.

Who is affected

Any server running PHP that handles web requests is affected. That includes:

• PHP-FPM (common with Nginx)
• Apache with mod_php (the highest-risk setup)
• php-cgi
• FrankenPHP and LiteSpeed

This covers popular platforms built on PHP, such as WordPress, Drupal, Magento and Laravel applications. If you are unsure whether your site uses PHP, ask your developer or hosting provider today.

What to do now

Upgrading PHP is the only complete fix. The temporary configuration changes in the next section can reduce your risk until you upgrade, but they only block specific attack paths.

1. Find every PHP server you run. Check production, staging and any older sites that are still online.
2. Upgrade to a patched version.

3. Use your vendor’s packages if you have them. Linux distributions and long-term support vendors received patches early, so check for updated PHP packages from your provider. If you install PHP from the Remi repository, switch to your distribution’s packages or build from source until Remi publishes updates.
4. Restart PHP services after patching so the new version is actually running.
5. Do not test with public exploit code. Some of what is circulating is unverified and may contain malware.

If you can’t patch today

If you can’t upgrade right away, you have three options, from safest to least protective.

1. Take the site offline or restrict public access until it is updated. The UK’s National Cyber Security Centre and CERT-EU both recommend isolating any internet-facing PHP system that can’t be patched right away.

2. Apply the PHP security team’s temporary configuration changes. These need to be set at the server level, not in application code, and every PHP worker must be restarted afterward. Have your developer or host review the full guidance in the official PHP advisory before making changes, since some settings can affect how your application behaves.

For CVE-2026-109618 (memory corruption):

; Set where applications can't override it, such as php_admin_value
; in the PHP-FPM pool or Apache configuration
memory_limit = -1

; 8M if your site doesn't accept file uploads, 32M if it does
post_max_size = 8M
; keep upload_max_filesize below post_max_size

• Enforce request size limits at your web server or proxy as well.
• Use a container or cgroup memory limit to protect availability. Do not use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerability.

For CVE-2026-109619 (stale global state):

session.upload_progress.enabled = 0

; PHP 8.5 only
fatal_error_backtraces = 0

• Set these in php.ini, the PHP-FPM pool or server configuration. Changing them with ini_set() or .user.ini files will not work.
• Hiding errors with display_errors or error_reporting does not help.

3. Put your site behind a web application firewall (WAF). Cloudflare has deployed rules that detect and block PHP2Shell traffic for all customers, including the free plan. A WAF only protects traffic that passes through it, so treat it as a short-term safety net alongside the steps above, not a replacement for upgrading.

After you patch, it is also worth reviewing server logs and files for anything unusual, since attacks began before many teams could update.

How Atiba can help

Our team is already patching the PHP environments we manage for our clients. If you are an Atiba client on a managed plan, your project manager will be in touch directly.

If we don’t actively manage your site, or you’re not sure who does, we’re happy to help. We can confirm whether you’re affected, apply the patch, and check for signs of compromise. If you have several sites or applications on the same server, we can review them all together.

Sources: PHP security advisory · Tenable FAQ · Help Net Security