← All articles

PHP2Shell: What the Critical PHP Flaws Mean for Your Small Business Website

By Front Range Cybersecurity ·

Most small business owners never think about PHP. But if your business has a website, an online store, a booking form, or a client portal, there is a good chance PHP is running underneath it.

On October 21, 2026, the PHP project released fixes for two critical vulnerabilities that can allow remote code execution without a login. Five days later, on October 26, CISA added both to its Known Exploited Vulnerabilities (KEV) catalog. In the same week, CISA also added a flaw in Adobe Commerce and Magento, the software behind many online stores, and a Linux kernel flaw that CISA says can be chained with the PHP bugs.

Here is what happened and what to do this week.

What happened

The PHP flaws ("php2shell")

PHP is a programming language that runs on web servers, and many popular website and store platforms are written in it. The PHP project's October 21 security advisory describes two critical bugs:

  • CVE-2026-109618, remote code execution through out-of-memory corruption.
  • CVE-2026-109619, remote code execution through stale internal state left over from an earlier request.

The PHP project says "all PHP installations serving web requests" are at risk, and it considers the risk highest for one of those setups (Apache with mod_php), "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." In plain terms: an attacker may not need a password, and may not need a bug in your own website code, to get in.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP project says there are no complete mitigations and that updating is the only safe choice.

CISA's alert, which uses the nickname "php2shell," urges organizations to inventory systems running PHP and patch immediately, internet-facing systems first.

Why "on the KEV list" matters

CISA's KEV catalog lists vulnerabilities that attackers are known to be using, not just ones that exist in theory. NHS England's cyber alert on the same flaws was updated on October 29 to note exploitation. It says security researchers have shown working exploits "in products integrating PHP such as WordPress, Drupal, and Joomla." It says the NHS England National CSOC had not seen mass exploitation but judged future exploitation "highly likely."

The federal directive that sets KEV deadlines (BOD 26-04) applies only to federal civilian agencies, but CISA encourages every organization to prioritize KEV vulnerabilities. For a small business, anything on that list moves to the top of the to-do list.

The same week: online stores and the server underneath

Two other KEV additions from the same week matter to anyone who runs a website:

  • Adobe Commerce and Magento (CVE-2026-48356), added October 27. Adobe's bulletin APSB26-73 rates it critical, with a CVSS base score of 9.6, and says no login is required to exploit it. It is an unrestricted file upload flaw. CISA added it to the KEV catalog "based on evidence of active exploitation."
  • Linux kernel (CVE-2026-46300), added October 28. CISA's KEV entry says this flaw can be chained with the two PHP vulnerabilities "to implant PHP webshells and run commands as root." A webshell is a small file an attacker leaves on a web server to run commands later; "root" is full control of the server.

The takeaway: your website's software is part of your attack surface, the same as your firewall or remote access login. Internet-facing systems get patched first, and that includes your website.

Is your business affected?

Where PHP tends to hide

CISA notes that "PHP is often a component of other software and prevalence may not be directly observable." You may be running it without knowing. Common places:

  • Your main business website, especially if it runs on a content management system you or a developer installed.
  • An online store or shopping cart.
  • Client or patient portals, appointment booking pages, and file-upload forms.
  • Old campaign or event sites that were never taken down.
  • Web apps a past employee or contractor set up and left running.

Who is responsible for the update?

It depends on how the site is hosted, and settling this is often the most useful first step.

  • A website builder or hosted platform (you never see a server): the platform usually manages the underlying software. Check their security notices or ask.
  • Managed or shared hosting: the host usually manages PHP, but you may choose the version in a control panel, and some hosts let customers stay on old versions.
  • A server you or your developer run (a virtual server or cloud instance): you, or whoever you pay, must update PHP and the operating system.
  • A store or app a developer built and maintains: check your agreement. Not every website build contract includes ongoing security updates.

If nobody can answer "who updates PHP on our website?" in one sentence, that gap is worth closing this week.

What to do this week

These steps are for an owner or office manager working with a web host, developer, or IT provider. You don't need to do the technical work, but you should know it was done.

  1. List every website and web app you have. Include stores, portals, booking pages, old sites, and anything a vendor runs for you. If you're not sure what is reachable from the internet, ask your host or IT provider for a list of your public IP addresses and domains.
  2. For each one, write down who hosts and maintains it, with contact details.
  3. Ask each owner whether it runs PHP, and which version. You are looking for 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later on those branches. PHP 8.1 or older is a red flag: the PHP project no longer issues regular updates for it.
  4. Get the update applied, internet-facing sites first. The PHP project notes that Linux distributions and long-term support vendors received the patches in advance, so the fix may arrive as a normal system update. Ask your provider to confirm the install date and that PHP was restarted afterward.
  5. If your store runs on Adobe Commerce or Magento, apply the fix in Adobe bulletin APSB26-73 and confirm your version against Adobe's fixed-version table.
  6. Patch the server's operating system too. Because of the Linux kernel chain, updating PHP alone may not be the whole job on a self-managed server.
  7. Ask for a quick check for signs of compromise. CISA suggests watching for PHP worker processes that launch shells or download tools. Your provider can also look for unfamiliar PHP files in the website's folders and odd entries in the web logs. "We patched" is not the same as "we were not affected." If anything looks wrong, treat it as an incident and contact your incident response provider, and your insurer if your policy requires it.
  8. Write down what you did: dates, versions and who did the work.

If an update can't happen right away

Sometimes old plugins or custom code break on a newer PHP version. The official guidance is direct:

  • The PHP project lists configuration changes that reduce exposure, but it says they "do not make an installation safe."
  • CISA says systems that cannot be updated, or that are still on PHP 8.1 or older, should be taken offline until they can be patched or updated.
  • CISA also notes that a web application firewall "may provide some protection" until systems are updated.

A few days offline, with a simple "back soon" page hosted elsewhere, is usually less painful than cleaning up after a break-in.

Plan ahead: PHP 8.2 reaches end of life on December 31

In its PHP 8.2.35 release notice, the PHP project says that PHP 8.2 reaches end of life on December 31, 2026 and will receive no further security fixes after that date.

If your site is on PHP 8.2, it is fixed for now, but ask your host or developer to test and schedule a move to a supported version before year-end. Doing it calmly in November beats doing it during the next emergency.

Questions to send your web host or developer

You can copy these into an email:

  1. Do our website, store or portals run on PHP, and which version is in production?
  2. Has the October 21, 2026 PHP security update been applied, and on what date?
  3. Is the server's operating system fully patched, including the Linux kernel?
  4. Did you check for unfamiliar files or unusual activity from before the patch?
  5. Who watches for updates like this going forward, and how will you tell us when one is applied?

Vague answers tell you something too. Responsibility for a website's underlying software is easy to lose between a host, a former developer and the business.

Making this a habit, not a fire drill

The pattern will repeat: a widely used component gets a critical fix, lands on the KEV list within days, and every business that depends on it has to find out fast whether it is exposed. It goes best for businesses that already know what they have on the internet and who maintains it.

For a free list of security basics, see the SMB Security Checklist.

The key step this week is simple: find out whether your website runs PHP, and get a clear yes or no on whether the update is in.

Sources

All pages were fetched and read on November 2, 2026 (America/Denver).

This article is general information, not legal or compliance advice. Only test systems you own or have written authorization to test.