PHP Websites After PHP2Shell: Patch, Upgrade or Change the Stack

How serious the vulnerabilities are

• All server APIs (SAPIs) are affected. These include PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. According to the php.net advisory, the risk is highest with mod_php.
• Attacks have already started. A public exploit tool is used for mass scanning. watchTowr's honeypots recorded attacks on 21 October, the same day the fixes came out.
• The attacker gets everything PHP can access. The attacker's code runs with the rights of the user that PHP runs as. This gives access to the application files, the database passwords in the configuration, and the API keys for other services.

PHP 8.1 and older are past end of life

PHP 8.1 and older versions will get no new releases. For 7.4, 8.0 and 8.1, the PHP developers published fixes only as source code. To use these fixes, you have to build PHP yourself. For 5.x and 7.0 to 7.3, the PHP developers released no fixes at all.

Some companies that build PHP packages for hosting providers released their own fixes. For example, CloudLinux patched alt-php for versions 5.2 to 8.5 and ea-php for cPanel. Customers of its paid support also got fixes for the PHP in standard Linux packages. The version number in these patched packages does not change. So you cannot tell from the version number whether a server is safe.

Such a patch protects the server from PHP2Shell. But it is not a long-term solution, for three reasons.

• The patch fixes only these two vulnerabilities. Nobody promises to fix the next ones unless you pay for support.
• Not every company releases such patches, and not for every operating system.
• If PHP runs in Docker, updating the PHP packages on the host server does not change the PHP inside the container. The official "php" images for PHP 8.1 and older are no longer updated. You have to build a patched image yourself.

Which PHP version to move to

php.net publishes the support dates for each branch.

Important. Each PHP branch is supported in two phases. For the first two years, active support fixes both bugs and security issues. For two more years, only security issues are fixed. When this second period ends, the branch gets no more security updates, and running a site on it carries risks.

Moving from an old PHP version usually means changing your application's code. If you have to change it anyway, go straight to 8.4 or 8.5. Moving to 8.2 or 8.3 instead takes almost the same work. Support for 8.2 ends in two months, and support for 8.3 in fourteen. So the next PHP upgrade would have to start almost at once.

What to do today

1. Find out which PHP version serves your site. There are several ways to do this. Your hosting control panel often shows the PHP version. With SSH access, you can ask PHP for its version in the terminal. The command "php -v" shows the version of command-line PHP. The command "php-fpm -v" shows the version of PHP-FPM. The command name may include the version number, for example "php-fpm8.1". But you need to know exactly which type of PHP interpreter serves your site (PHP-FPM, mod_php in Apache, or CGI). The surest way is a small file that calls "phpinfo()". Upload this file to the server and open it at its web address. The page shows the PHP version and the interpreter type (the Server API line). Then delete the file from the server, because it reveals the server configuration.
2. If you are on 8.2 to 8.5, update to the fixed release. Then restart PHP-FPM, Apache or LiteSpeed. The fixed release is a patch release within your branch. It usually needs no changes to your application's code.
3. If you are on 8.1 or older, find out whether there is a patch for your PHP packages. Then make sure the patch is really installed. Look for CVE-2026-109618 and CVE-2026-109619 in the package changelog. CloudLinux has a ready-made command for this check. On shared hosting, ask your host to confirm that the patch is installed. If there is no patch, see the "Buy time" option below.
4. Do not rely on WAF rules. A WAF (web application firewall) filters the requests that reach your site. Its rules block known variants of the attack, but not every way to exploit the vulnerabilities.
5. Check whether the server has already been hacked. The next section explains how to check.

How to tell whether a site has already been hacked

A hack is easy to miss, because the site keeps working as usual. Meanwhile, the attacker may leave a backdoor, such as a web shell, to come back later. The attacker may also add spam links that search engines see but visitors do not. Often the owner learns about the hack only when the search engine marks the site as hacked. By then, search traffic has usually dropped. For SEO specialists and agencies, such a hidden hack is the main risk with clients on old PHP.

Check these five places.

• The Security Issues report in Google Search Console. In this report, Google lists the injected content and hacked URLs it has found.
• The page as Google sees it. Open the URL Inspection tool in Search Console. Compare the code Googlebot gets with the code your browser gets. Does Googlebot see links or text that visitors do not? That is cloaking, a typical sign of injected spam. A "curl" request with Googlebot's User-Agent is not enough for this check. Malicious code often checks the crawler's IP address too.
• Search results for your own site. Try the query "site:example.com casino", or the same query with "viagra" or "loan". If the results show pages you never published, the site has been hacked.
• Files on the server. Look for recently changed PHP files. Look for calls to "eval", "base64_decode" and "gzinflate". Look for PHP files in upload folders.
• The database. On WordPress, check the "wp_options" and "wp_posts" tables for injected scripts and links.

If you find signs of a hack, removing the spam links is not enough. The attacker could run any code, so treat the whole server as compromised. Close the vulnerability. Find and remove the backdoors. Change the passwords and keys in the application's configuration. If you have any doubt, rebuild the server from a clean image.

Why upgrading from old PHP takes more than one command

The older your PHP version, the more of the three problems below apply to you.

Removed and changed functions. Each major PHP version removes features that earlier versions marked as deprecated. PHP 7.0 removed the "mysql" extension with its "mysql_*" functions. PHP 8.0 removed "each()" and "create_function()". PHP 8 also changed how strings are compared with numbers. Many warnings became errors. PHPCompatibility, a ruleset for PHP_CodeSniffer, finds calls to removed functions. Rector can rewrite many of these calls automatically. But static analysis cannot see changes in behaviour, such as the new comparison rules. Only tests find such changes. Without tests, your users will find them.

The framework or CMS. Each framework version works only with certain PHP versions. TYPO3 9.5, for example, supports only PHP 7.2 to 7.4. Old versions of Laravel, Symfony, TYPO3 or Drupal usually do not run on current PHP. Moving to a new major version of the framework is a migration of its own, with its own breaking changes.

Dependencies. Some Composer libraries, CMS extensions and WordPress plugins have not been maintained for years. These dependencies have no versions for current PHP. You have to replace them, maintain your own fork, or rewrite them.

The longer you put off the PHP upgrade, the more of the code, the framework and the dependencies must change at once. So it pays to start now, before the amount of work grows.

How to choose a legacy application modernization path

There are four options.

• Upgrade. Move to a supported PHP version. Stay on the current major version of your framework.
• Migrate. Move to a new major version of your framework or CMS. Move to a supported PHP version along with it.
• Change the stack. Rebuild the system with other technologies. For a content site, the new stack is often a static site generator.
• Buy time. Pay a commercial vendor for extended support of your old PHP version. Extended support gives you time to prepare one of the first three options calmly. It does not replace them.

In most cases, seven yes-or-no questions decide the choice. What each answer means is written right below each question. For convenience, a diagram after the questions shows the same logic. Some readers may find the diagram easier to follow than the text.

Step 1. Urgency.

1. Does your site run on PHP 8.2 or newer?

• Yes. Update to the fixed release. If you are on 8.2, plan the move to 8.4 or newer before 31 December. Go to question 3.
• No. Go to question 2.

2. Do you manage the server yourself (a VPS, a dedicated server or your own containers)?

• Yes. Nobody will patch PHP for you. Install the patch or rebuild the image yourself today.
• No. Ask your host today to confirm in writing that the patch is installed.

In both cases, if a migration will take months, think about extended support. Then go to question 3.

Step 2. Path.

3. Does your version of the framework or CMS get security updates?

• Yes. Go to question 4.
• No. You cannot stay on your current version. Go to question 5.

4. Can you move to a supported PHP version without changing the major version of the framework or CMS?

• Yes. Upgrade. This is the most economical path. Go to question 7.
• No. Go to question 5.

5. Is your site mainly a content site (pages, articles, forms) without user accounts, payments or business logic on the server?

• Yes. Go to question 6.
• No. You have an application, not a content site. Plan a migration in stages, one module at a time. Go to question 7.

6. Do your editors' drafts, approvals and permissions rely on built-in features of your CMS?

• Yes. Compare two options, a current CMS version and a static site. The deciding factor is the cost of moving your editorial workflow. The section on the editorial workflow below explains why.
• No. Consider changing the stack and rebuilding your site as a static site. A static site needs no PHP on the server. Without PHP on the server, a whole class of vulnerabilities disappears.

In both cases, go to question 7.

Step 3. Preparation.

7. Are the key user scenarios covered by automated tests?

• Yes. Run the tests before and after every change.
• No. Before you change anything, record the current state of the site with measurements. The measurements can cover different aspects of the site, for example page loading speed, whether the content matches, and errors in the HTML output. After the migration, the same measurements show what has changed. For the key user scenarios, write tests.

All seven questions in one diagram

A sample breakdown for our own site

This is the result the old silkdata.tech would get if it were still running.

Urgency. PHP runs in our own container. No host will patch it, and there is no official patched image. For PHP 7.4, we could rebuild the image today with the source-code fix. For 7.2 and 7.3, the PHP developers released no fix. That leaves paid extended support or an urgent migration.

Recommended path. Change the stack and rebuild the site as a static one.

Rationale. TYPO3 9 no longer gets fixes. To reach a supported PHP version, TYPO3 would need several major upgrades. The site is a content site. Building pages on every request brings no benefit and keeps PHP open to attacks. Editors already wrote articles in Markdown outside the CMS. A site built from Markdown files keeps their way of working.

Preparation. There are no tests. Instead, a script will compare every page of the new site with the live one.

Main risks. The contact form must be rebuilt. Scripts inside pages must keep working. Every redirect must be kept, or the old addresses will lose their search traffic.

Why the editorial workflow matters more than the tech stack

A static site needs no PHP. The server only sends ready-made files. Content lives in Markdown files, not in the database of one particular CMS. So any future migration will be cheaper. The main difficulty of moving to a static site is the editorial workflow.

A mature CMS gives editors a lot out of the box. TYPO3, for example, has workspaces. Editors change content in a separate copy that does not affect the live site. They can preview the changes exactly as the changes will be published. A workspace can have several review stages. It can have its own owners, members and reviewers. Each editor can be limited to their part of the page tree. Notifications go out at every stage.

A Git-based CMS works differently. Content is stored in a repository. Changes are approved through branches, merge requests and code review. Permissions by section and language, custom approval stages and notifications must be built separately. Does your team use these CMS features every day? Then estimate the cost of moving the workflow to a Git-based CMS before anyone writes the first line of code.

How a migration works, using silkdata.tech as the example

The old silkdata.tech ran on TYPO3 9.5 in Docker on our own server. Our editors found the TYPO3 admin interface unintuitive. So they wrote articles in a Markdown editor instead. We wrote our own TYPO3 extension to import these articles. The extension could run on a schedule. But we never reached fully automatic publishing from Markdown. We decided not to finish this automation on an outdated stack. Instead, we moved to a stack that is easier to use and more secure.

We rebuilt the site with the Astro static site generator. We moved the hosting to Cloudflare and replaced TYPO3 with a Git-based CMS. This project shaped the migration method we now use with clients. The method has five stages. Each stage ends with a result you can use. You can stop after any stage and keep everything done so far.

The scale of our project. About 350 pages in English and German. 86 blog articles and 313 redirects. 713 MB of media, of which only 226 MB were in use. The first commit was made on 14 August 2026. The new site went live on 17 September, a little over a month later.

Stage 0. Analysis from the outside

How we do it. Before we touch the server, we look at the site the way a browser, a search engine and an AI agent see it. We validate the HTML and measure loading speed. We check search visibility. We assess how well AI agents can read the pages. This snapshot becomes the baseline we compare the new site against.

At this stage we also note how the site's sections differ. The blog, case studies and service pages often have their own structure and design. We list each difference and discuss it with you. The differences determine how many templates the new site needs and what is worth keeping from the old site.

How we did it. The FAQ markup in Schema.org matched the visible FAQ on only 7 of the 58 pages that had this markup. 92% of images had no dimensions set. In 59 of 86 RSS feed items, the title did not match the article heading.

Stage 1. A one-to-one copy

How we do it. First we copy the site exactly as it was, with all its defects. Then a script compares every copied page with the live one. We fix or explain every difference the script finds. Then we freeze the copy and record each remaining difference with its reason. From then on, no difference can appear unnoticed.

How we did it. We started from a copy made by crawling the live site automatically. That is why the whole site ran locally after five working days. We compared eight aspects of every page: whether the page exists, headings, text, labels, images, links, metadata and the Markdown version. The contact form had only worked inside TYPO3. We rebuilt the form on Cloudflare Workers. The new form has bot protection, sends mail through our own SMTP server and keeps an archive of submissions. Inline jQuery code on 115 of 352 pages kept working.

Stage 2. Fixing defects

How we do it. We fix the old site's defects only after the copy is frozen. This way each fix is a separate change. You can check each fix and roll it back without touching anything else.

How we did it. We fixed every defect found at stage 0. We also shortened page titles that were cut off in search results.

Stage 3. Improvements

How we do it. Only after the old site's defects are fixed do we add what the old site never had.

How we did it. We made three improvements.

• A strict security policy. The old Content Security Policy allowed "unsafe-inline" and "unsafe-eval". We replaced it with a strict one. At first, the new policy ran in report-only mode. On the very first day, the reports showed a problem. The new policy would have blocked a request from the cookie consent banner to a geolocation service. We fixed the policy. A week after launch, we switched the policy to enforcement.
• Structured data that matches the page. Structured data is now generated from the finished page and checked during the build. So the markup cannot drift away from the page content.
• Lighter images. Images are served as WebP where this format really makes them smaller.

These are not all the improvements we made. After the analysis, we can suggest further improvements that suit your site.

PageSpeed Insights tested our home page on 26 October 2026. The page scored 96 for performance on mobile and 100 on desktop. It scored 100 for Best Practices and SEO on both. The page also passes all four Agentic Browsing checks. This PageSpeed category shows how ready a page is for AI agents. You can check the current scores yourself.

Stage 4. An interface for editors

How we do it. When the new site has run long enough to be trusted, editors get an interface for managing the content. We set up this interface for your editorial workflow.

How we did it. Editors work in a Git-based CMS. Each article has one of five statuses.

• Incoming. A new article that nobody has worked on yet.
• Draft. An editor is working on the article.
• Review. The article is ready for review.
• Rework. The reviewer has sent the article back with notes.
• Ready. The article is approved and goes to the live site with the next deploy.

Every save in the editor creates a commit in the Git repository. After each commit, CI automatically checks the site, builds it and publishes it to a private preview copy. CI (continuous integration) is a service that runs such steps on its own after every change. The check and the build take about 15 minutes. So editors see their edits on the preview copy about 15 minutes after saving. Changes reach the live site only after review and a manual deploy.

How to roll back

At launch, the new site does not replace the old one. The old site keeps running for some time, and the domain simply points to the new site instead. If problems appear, you can quickly switch the domain back to the old site.

The new site also supports rollbacks.

• Git. Every change to the content and the code is a commit in the repository. Any commit can be reverted, and the site is then rebuilt without that change.
• Cloudflare. Cloudflare keeps the previous versions of the deployed site. You can return to a previous version in the dashboard or with one command.

Both rollback options are simple to use.

What the timeline depends on

The timeline of a migration depends on six factors.

• The number of pages, and of sections with their own templates.
• The number of languages.
• Server-side features, such as forms, search or user accounts.
• The number of redirects.
• How complex the editorial workflow is.
• Whether there are tests.

Our result

Our site runs without PHP. Vulnerabilities like PHP2Shell cannot affect it. Our other projects are in the case studies.

What we offer

We start with a security analysis. We check whether the patch is really installed. We look for signs of a hack. We assess the state of the framework and dependencies. Then we choose the next step together with you, from a patch to a change of stack. We take on two or three analysis requests a week.

Quality assurance. Our QA engineer will analyse your site and then measure its current state. If a project is done without tests, nobody can guarantee that the site works. Such work is delivered "as is".

If you choose a migration, it follows the five stages above. You can stop after any stage. After launch, your old site keeps running for an agreed period. During this period, you can switch back to the old site at any time. The work is done by our specialists in IT consulting, DevOps and web development.

Request a security analysis

Conclusion

PHP2Shell is unlikely to be the last vulnerability in PHP. A supported PHP version will get fixes for the next ones too, and a static site does not run PHP at all.

We went through the whole migration process ourselves. You are seeing its result right now, as you read this article on our site. Programmers have an old saying: if it works, don't touch it. Our site ran on TYPO3 9.5, a version released in 2018. By the time we moved, this version was eight years old. So we know first-hand how hard it is to decide on such a change.

Is something in this article unclear? Do you have a question about your own site, or would you like our opinion on another topic? Contact us in any way that suits you.