Ravindra BagaleCourses & study guides Track your progress

Daily Cyber Incidents · 22 October 2026

PHP2Shell: two critical PHP flaws let attackers run commands on web servers without a login

By , Cyber Security trainer LinkedIn Published: Last updated:

On 21 October 2026, the PHP team fixed two critical flaws, together called PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They let a stranger make a PHP web server run commands without a login. Amazon saw a first attack attempt on 17 October, and attacks spread after the fix. Governments in Finland and the Netherlands took websites offline as a safety step. The only full fix is to update PHP and restart every worker.

Quick facts

  1. What: two critical flaws in PHP itself that allow remote code execution without a login.
  2. When: fix released on 21 October 2026; first attack attempt seen by Amazon on 17 October.
  3. Who is at risk: every PHP install that serves web pages (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed).
  4. Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older need a vendor fix or an upgrade.
  5. Score: CVSS v4.0 9.2 for each flaw.
  6. Response: many sites went offline for a while; UK NCSC, CERT-EU and India's CERT-In issued warnings.

The full story (English, मराठी, हिंदी)

Pick your language. The story, the defence steps and the checklist are the same in all three.

PHP2Shell: the full story

1. What happened

PHP is the language that builds web pages on the server. WordPress, Drupal, Joomla and many control panels run on it. In this lesson you set PHP up and made its settings safe.

  • On 21 October 2026, the PHP team released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These fix two critical flaws: CVE-2026-109618 and CVE-2026-109619. Together they are called "PHP2Shell".
  • Both flaws allow remote code execution (RCE) without a login. That means a stranger on the internet can make your server run their commands. Each flaw has a CVSS v4.0 score of 9.2.
  • PHP says every PHP install that serves web pages is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, where one request can start the attack before any of your PHP code runs.
  • Researchers from Calif, Wiz and OpenAI found the flaws with the help of AI tools. Details leaked on social media on 20 October, so the PHP team had to rush its warning.
  • Amazon saw an attack attempt on its trap servers (honeypots) on 17 October, four days before the public warning. After the fix came out, Amazon said PHP2Shell is now "being broadly exploited in the wild".
  • Many sites went offline as a safety step. Finland shut its government public web services for a while. The Dutch cyber security agency took its own website offline. Wikimedia took some systems down. The UK NCSC said: patch now, or take the system offline until you can. India's CERT-In also issued a critical warning.
  • PHP 8.1 and older no longer get fixes from the PHP project. You need a fix from your Linux vendor, or a move to a supported version.

2. How the hack happened (public reporting only – high-level)

  1. Attackers scan the internet for servers that run PHP. They do not need to pick a victim. Any public PHP page is enough.
  2. They send one specially shaped form request to any PHP page. No login is needed. Datadog showed that even a page that only prints one short reply is enough.
  3. The request makes PHP stop in the middle of its work (for example, it runs out of memory). Some of PHP's own data is left half-ready.
  4. PHP then cleans up after the failed request, or the next request on the same worker uses old leftover data. PHP trusts this broken data.
  5. The attacker's command then runs as the web server user (like apache or www-data). From there they can read files, read database passwords from config files, or leave a hidden backdoor.
  6. Your login page, your input checks and your firewall rules inside the app do not help, because all this happens before your code runs.

3. How to stop it / defend (this lesson: secure PHP settings)

  • Patch first. It is the only full fix. Check the version with php -v. Update with your package manager (sudo dnf update 'php*' on Amazon Linux, sudo apt update && sudo apt upgrade on Ubuntu). Then restart every worker: sudo service php-fpm restart (Ubuntu: php8.3-fpm), and sudo service httpd restart (Ubuntu: apache2) if you use Apache.
  • Check the PHP that serves the web, not only the command line. The web server can use a different PHP. Open a test page with phpinfo() on your own lab server, read the version, then delete the test page.
  • If you cannot patch today, take the site offline, as the NCSC advised. As a short-term extra step only, the PHP team lists php.ini settings that block some attack paths: session.upload_progress.enabled = 0, a small post_max_size (8M if you have no uploads, 32M if you do) and upload_max_filesize smaller than post_max_size. Put them in php.ini or the FPM pool file, not in ini_set() or .user.ini, and restart. These settings do not make you safe.
  • Hiding errors does not stop this bug. display_errors = Off is still right for production, but the PHP team says hiding errors with display_errors, error_reporting or @ does not help here.
  • Limit the damage. Run PHP as its own low-power user. Give the website's database user only the rights it needs. Keep secrets out of files the web user can read when you can.
  • A WAF in front helps for a few days. Cloudflare added rules, but its CTO called them a "STOPGAP only".

4. How to take care so it won't happen again (checklist)

  • Make a list of every place PHP runs: servers, containers, control panels and products that hide PHP inside.
  • Patch internet-facing servers in hours, not weeks, when a critical flaw is out.
  • After patching, restart every worker and rebuild container images.
  • Look at logs from 17 October onwards: very large form requests, "Allowed memory size ... exhausted ... in Unknown on line 0" errors, and any shell started by the web server user.
  • Move off PHP 8.1 and older. Plan upgrades before support ends.
  • Keep production php.ini safe: display_errors Off, expose_php Off, small upload limits, settings that apps cannot override.

Why your login page did not help

Think of what happens when a request reaches a PHP website:

  1. The web server (Apache, Nginx or LiteSpeed) gets the request.
  2. PHP reads the request: the form fields, the cookies and the uploads.
  3. Only then does your PHP code run: the login check, the input checks, the database query.

PHP2Shell works in step 2. So the attack is over before step 3 starts. Your login check and your input checks never get a chance to say no.

DefenceDoes it stop PHP2Shell?Why
Update PHP and restart workersYesIt removes the bug
Take the site offline until patchedYes, for that siteNo request reaches PHP
Login page, input checks in your codeNoThe attack happens before your code runs
display_errors = OffNoHiding errors does not fix the bug
Temporary php.ini settingsPartlyThey block some known paths only
WAF rules in frontPartly, for a short timeA stopgap until you patch

Check and patch, stack by stack

Do this on your own servers. Check the PHP that serves the web, not only the php command.

Your setupCheck the versionUpdateRestart
Amazon Linux 2023 + Apache or Nginx + PHP-FPMphp -v and php-fpm -vsudo dnf update 'php*'sudo service php-fpm restart and sudo service httpd restart (or nginx)
Ubuntu + Apache with mod_phpphp -v, then a phpinfo() test pagesudo apt update && sudo apt upgradesudo service apache2 restart
Ubuntu + Nginx + PHP-FPMphp-fpm8.3 -v (your version number)sudo apt update && sudo apt upgradesudo service php8.3-fpm restart
Docker image with PHPdocker exec <container> php -vPull a fixed base image and rebuildReplace the running containers
Shared hosting or a control panelThe panel's PHP version pageAsk your host, or switch to a fixed version in the panelThe host restarts it
WordPress, Drupal, Joomla, MagentoCheck the server's PHP, not the CMSA CMS auto-update does not update PHPAs per the server type above

After the update, open your phpinfo() test page on your own lab server once more, confirm the new version, and then delete the test page.

What to look for in your logs

Amazon says to start looking from 17 October 2026, not from the day of the fix.

  1. In the web server access log: unusually large form (POST) requests to normal pages.
  2. In the PHP error log: "Allowed memory size ... exhausted ... in Unknown on line 0". "Unknown on line 0" means PHP failed before any script ran.
  3. On the server: any shell or command started by the web server user (apache, nginx or www-data). This is the strongest sign.
  4. New or changed .php files in the website folder that nobody on your team made.

If you find signs, treat the server as broken in: keep the logs, build a clean server, and change the database and other passwords the website used.

Summary

QuestionAnswer
What is PHP2Shell?Two critical flaws in PHP: CVE-2026-109618 and CVE-2026-109619
What can an attacker do?Run commands on the server as the web user, without a login
Who is at risk?Every PHP install that serves web pages
Main fixPHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every worker
If you cannot patch todayTake the site offline; temporary settings only reduce risk
Check logs from17 October 2026

Quick quiz: check what you learned

  1. What can PHP2Shell let an attacker do?

    1. Run commands on the server, no login
    2. Read only the public home page text
    3. Change the website's domain name
    4. Send email from the visitor's phone
    Show answer

    A. It is remote code execution without a login.

  2. Why did the site's login check not stop it?

    1. The attack runs before your code runs
    2. The attacker knew every user password
    3. Login pages are switched off by PHP
    4. The attack only targets admin pages
    Show answer

    A. PHP is hit while it reads the request, before your script starts.

  3. What is the only full fix?

    1. Update PHP and restart every worker
    2. Set display_errors to Off in php.ini
    3. Add a CAPTCHA to the contact form
    4. Change the database root password
    Show answer

    A. Patched PHP versions remove the bug; restarts load the fix.

  4. From which date should you check your logs?

    1. 17 October 2026, before the fix came
    2. 1 January 2026, start of the year
    3. Only from the day you patch PHP
    4. No need, a WAF blocks all of it
    Show answer

    A. Amazon saw a first attempt on 17 October, four days early.

Sources

  1. PHP: "Security advisory: Critical remote code execution vulnerabilities, update now", 21 October 2026
  2. AWS Security Blog, CJ Moses: "Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot", 21 October 2026
  3. BleepingComputer, Sergiu Gatlan: "PHP ships emergency patches for critical PHP2Shell flaws", 21 October 2026
  4. Datadog Security Labs: "PHP2Shell - Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619)", 21 October 2026
  5. BBC News: "Websites taken down worldwide as critical PHP cyber-security update issued", 21 October 2026
  6. Reuters via CNBC: "Government websites go dark as software flaw sparks security scramble", 21 October 2026
  7. Business Today: "Critical PHP vulnerabilities: What is it, how it can affect websites" (CERT-In note), 22 October 2026

This page is a defensive, educational summary of public reporting. It does not include exploit code, attack requests or IP addresses.

Learn it properly

These pages go deeper: