Key takeaways
- PHP 8.2 receives no security updates from the PHP project after December 31, 2026. PHP 8.1 has been unsupported since December 31, 2025, and PHP 8.3 follows on December 31, 2027.
- PHP2Shell showed in October 2026 how little protection an end-of-life (EOL) version has: official fixes shipped only for 8.2 to 8.5. For PHP 7.4 to 8.1, the PHP project published source backports only, and older versions got no fix at all.
- A ShiftPress analysis of 54,743 websites in Germany, Austria, and Switzerland found that 21 percent of municipal websites showing their PHP version still ran PHP 8.1 or older. For well-known .de, .at, and .ch websites, the figure was 26 percent.
- Under ISO 27001:2022, outdated software touches at least controls A.8.8, A.5.9, and A.8.32, plus risk treatment under clause 6.1.3. An auditor expects either a dated upgrade plan or a documented, time-limited risk acceptance.
- If you upgrade now, move to PHP 8.4 or 8.5. Moving to 8.3 only postpones the same problem by twelve months.
PHP 8.2 End of Life is not a date that only concerns developers. From January 1, 2027, the PHP project stops fixing security flaws in this branch, including critical ones. For companies running an ISMS under ISO 27001 or subject to NIS2, every remaining PHP 8.2 installation becomes a question for the next audit: Did you know about it, how did you assess the risk, and what did you decide?
We wrote this article for IT leads, CISOs, information security officers, and compliance teams in small and mid-sized companies. It shows which PHP versions lose support and when, which options you have, and what evidence an auditor will want to see. Our article on PHP2Shell and what it means for ISO 27001 and NIS2 covers the technical side of the most recent critical flaw and the immediate steps it required.
What PHP 8.2 End of Life Actually Means
End of life means the PHP project no longer publishes updates for that branch, neither for bugs nor for security flaws. Each branch gets two years of active support, followed by two more years of fixes for critical security issues only. After four years in total, support ends.
PHP 8.2 was released on December 8, 2022. Active support ended on December 31, 2024, and since then the branch has received security updates only. Those end on December 31, 2026.
PHP2Shell as a Dress Rehearsal
PHP2Shell showed what this means in practice. On October 21, 2026, the PHP project released emergency updates for two critical flaws in the interpreter, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0. Attackers could use them to run code on web servers without logging in.
The PHP project shipped official releases only for the supported branches: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. For PHP 7.4, 8.0, and 8.1, it provided minimal source backports without an official release. Anyone running those versions had to build the patch in themselves or wait for their Linux distribution, hosting provider, or LTS vendor. Older versions got no fix at all.
A common assumption is that someone will always ship a patch when a flaw is truly critical. PHP2Shell showed that for EOL versions, this comes down to luck. If a comparable flaw hits PHP 8.2 in February 2027, there will be no PHP 8.2.36.
Which PHP Versions Lose Support and When
The table below shows the dates from the PHP project's official list of supported versions and its end-of-life list, as of November 3, 2026.
| PHP version | End of security support | Status |
|---|---|---|
| PHP 8.5 | December 31, 2029 | Actively supported |
| PHP 8.4 | December 31, 2028 | Actively supported until December 31, 2026, then security updates only |
| PHP 8.3 | December 31, 2027 | Security updates only |
| PHP 8.2 | December 31, 2026 | Security updates only, end of life at year end |
| PHP 8.1 | December 31, 2025 | End of life |
| PHP 8.0 | November 26, 2023 | End of life |
| PHP 7.4 | November 28, 2022 | End of life |
One consequence that many teams miss: if you migrate away from PHP 8.2 now, do not stop at 8.3. PHP 8.3 reaches end of life on December 31, 2027, so you would repeat the whole exercise in twelve months. PHP 8.4 is covered until the end of 2028, and PHP 8.5 until the end of 2029.
How Widespread Outdated PHP Versions Are
ShiftPress measured the scale of the problem in German-speaking countries, and Borns IT- und Windows-Blog reported the results on November 3, 2026. The analysis covered 54,743 websites in Germany, Austria, and Switzerland. Of the 1,071 municipal websites that openly show their PHP version, 21 percent reported PHP 8.1 or older. For well-known .de, .at, and .ch websites, the share was 26 percent, and for universities and schools, 19 percent.
These figures only count versions that are already unsupported today. From January 1, 2027, every website on PHP 8.2 joins them.
A Version Number Proves Nothing
The second misconception concerns the version number. Many hosting providers and Linux distributions backport security fixes without changing the displayed PHP version. An old number therefore does not automatically mean a system is unprotected. Equally, a number that looks current does not prove that every patch is in place. Only the package changelog or written confirmation from your hosting provider, naming the CVEs fixed, will hold up.
Why Outdated Software Is an Audit Topic
ISO 27001 does not prohibit outdated software. It does require you to know where it runs, assess the risk, and make a documented decision. That is exactly how an auditor will judge a PHP 8.2 installation in 2027.
The Relevant ISO 27001:2022 Requirements
A.8.8 Management of technical vulnerabilities requires you to obtain information about vulnerabilities in good time, evaluate your exposure, and take appropriate measures. A component without vendor support is a known, permanent exposure, because nobody closes new flaws in it.
A.5.9 Inventory of information and other associated assets is the precondition for everything else. Without an inventory that records versions, you do not know which systems are affected. Our overview of all 93 ISO 27001 controls explains how the Annex A controls fit together.
A.8.32 Change management applies to the upgrade itself. Changing the runtime version of a production system is a change, and it needs testing, approval, and a rollback plan.
Clause 6.1.3 Information security risk treatment governs what happens to systems you cannot switch over in time. The standard requires a risk treatment plan and the risk owners' approval of that plan and of the remaining residual risks.
Upgrade Plan or Time-Limited Risk Acceptance
For every PHP 8.2 installation after December 31, only two states will hold up in an audit. Either you have an upgrade plan with dates and named owners, or you have a documented risk acceptance that has an end date, names compensating controls, and carries the risk owner's signature. An open-ended acceptance with no end date is not risk treatment but a permanent exception, and auditors read it that way.
The case that regularly leads to a nonconformity is the third one: the system appears in neither the inventory nor the risk register. Then the auditor finds not only a missing measure but no evidence that the A.8.8 process works at all.
NIS2: Section 30 BSIG in Germany
For companies subject to NIS2 in Germany, handling vulnerabilities is a legal duty. Section 30(2) of the BSI Act lists, under number 5, security in the acquisition, development, and maintenance of IT systems, including vulnerability handling and disclosure. Number 9 requires the management of ICT assets, which in practice means an inventory. Both mirror Article 21(2) of the NIS2 directive.
Under section 38 BSIG, management must implement these measures and oversee their implementation. With a known deadline such as PHP 8.2 End of Life, management should therefore know how many systems are affected and when they will be switched over.
Our guide to NIS2 requirements summarizes the other obligations NIS2 brings.
Your Options: Upgrade, Extended Support, or Isolation
Every system on PHP 8.2 or older has three ways forward. They differ in whether they solve the problem or only buy time.
| Option | What it achieves | Drawbacks | Suited to |
|---|---|---|---|
| Upgrade to PHP 8.4 or 8.5 | Removes the problem. Official security updates until the end of 2028 or 2029 | Testing effort, possible incompatibilities with frameworks, plugins, and in-house code | Every system whose application you can test in the coming weeks |
| Extended support from a Linux distribution or LTS vendor | Backported security fixes beyond the official end date | Coverage depends on the vendor and applies only to its packages, the version number stays the same, evidence takes more work | Systems with a fixed upgrade date in 2027 |
| Isolation or shutdown | Shrinks the attack surface, for example by allowing access only through a VPN | The vulnerabilities remain; only access narrows. Not a permanent state | Legacy applications with no upgrade path, device admin interfaces |
Upgrade
The upgrade is the only option that removes the problem instead of postponing it. The effort depends less on PHP itself than on what runs on it. A current WordPress or Typo3 site with maintained extensions usually runs on PHP 8.4 without major changes. In-house applications and shops with many plugins need real testing.
Extended Support
Some Linux distributions maintain their PHP packages longer than the PHP project does. Debian 12 ships PHP 8.2 and receives security updates through Debian LTS until 2028. Commercial vendors also sell extended support for older PHP versions.
The catch is that the protection covers only packages from that exact source. If you install PHP from a third-party repository, compile it yourself, or bundle it in your own container image, you get none of it. For the audit, you also need evidence of which vendor provides the support and until when.
Isolation
Isolation fits where no upgrade is possible, such as a legacy application with no vendor or a device with a PHP-based admin interface. For firewalls, NAS systems, and load balancers, the fix arrives as a vendor firmware update anyway. Until then, keep those interfaces off the internet. A web application firewall can block known attack patterns, but it does not replace a patch.
A Realistic Upgrade Plan for December 31
From early November, you have just under eight weeks, and many companies freeze changes in the second half of December. A realistic plan therefore finishes the switchovers by mid-December.
- Build the inventory (by November 13, IT operations). Record every server, container image, and hosting package that runs PHP, each with its version and update source. Include websites that an agency or hosting provider runs for you, the intranet, old campaign sites, and staging environments. Add devices with PHP-based admin interfaces, such as firewalls, NAS systems, and load balancers.
- Assess and prioritize (by November 20, information security officer with the IT lead). Assign each system to one of the three options. Systems reachable from the internet and systems holding personal data go first.
- Test (November 23 to December 4, development or service provider). Test every application on PHP 8.4 or 8.5 in a staging environment. Update frameworks, plugins, and themes first, because outdated versions of those are often the real blocker.
- Switch over (December 7 to 18, IT operations). Run every switchover as a change under A.8.32, with approval, a time window, and a rollback plan.
- Cover the rest (by December 31, risk owner). Anything not switched over gets a time-limited risk acceptance with an end date, compensating controls, and a signature.
Consider an example. A machinery manufacturer with 120 employees finds seven PHP systems during the inventory. The intranet and the customer portal run on its own servers with PHP 8.2, an agency runs two marketing websites, and there is also a B2B shop, a NAS, and a firewall with a PHP-based admin interface. The team switches the intranet and the portal to PHP 8.4 on December 10. The agency confirms the website upgrades in writing. The shop needs a plugin that will not ship until February, so the IT lead signs a risk acceptance until March 31, 2027, with access only through a web application firewall and a weekly review. The NAS and the firewall get firmware updates, and their interfaces are now reachable only from the internal network.
What to Document
For every system, record the version before and after the switchover, the date, the change ticket with its approval, the test result, and, where relevant, the confirmation from the hosting provider or agency. Every exception needs a rationale, an end date, compensating controls, and the risk owner's signature.
What Auditors Want to See
An auditor does not expect your company to have no legacy systems. They expect you to know about them and to have made a decision you can explain. In the first audit after December 31, 2026, expect requests for this evidence:
- an inventory with PHP versions and end-of-life dates, including hosted websites and devices
- a risk register entry for outdated software, with an assessment and a risk owner
- the upgrade plan with dates and owners, plus the change tickets for completed switchovers
- for every exception, a time-limited, signed risk acceptance with compensating controls
- proof of patch level, meaning package changelogs or confirmations from hosting providers and service providers
- a process that monitors end-of-life dates going forward, instead of rediscovering them every year
The last point matters most. PHP 8.3 follows in 14 months, and operating systems, databases, and frameworks follow the same pattern. An auditor therefore looks less at the individual switchover than at whether your vulnerability management spots the next deadline on its own.
Turning Vulnerabilities and Deadlines into Audit Evidence with Kertos and Aikido
Most of the evidence on that list comes into being in the tools your IT and development teams use, not in the ISMS. Kertos closes that gap through the Aikido and Kertos integration. Aikido Security checks code, cloud environments, and running applications for vulnerabilities. Kertos reads those findings together with the remediation deadlines you set, checks daily whether any deadline has passed, and files the result as evidence for the ISO 27001 requirements on vulnerability management, secure development, and security testing.
The connection is read-only and changes nothing in Aikido. It refreshes once a day in the background, or on demand. For your audit, that means the answer to whether vulnerabilities get fixed on time is already on file, without anyone collecting screenshots.
You keep the inventory and the risk register in the same platform. Kertos's certified experts help you set up vulnerability management so that the next end-of-life date is no longer a special project. If you want to see how this looks in your environment, book a demo.
Frequently asked questions
When does support for PHP 8.2 end?
The PHP project provides security updates for PHP 8.2 until December 31, 2026. Active support with regular bug fixes already ended on December 31, 2024. From January 1, 2027, the project will not fix even critical security flaws in PHP 8.2.
What happens if I keep using PHP 8.2 after end of life?
Your application keeps running, but new security flaws stay open. During PHP2Shell in October 2026, EOL versions got no official release, only source backports or no fix at all. Under ISO 27001, each such system needs an upgrade plan or a time-limited, documented risk acceptance.
Which PHP version should I upgrade to?
Upgrade to PHP 8.4 or 8.5. PHP 8.4 receives security updates until December 31, 2028, and PHP 8.5 until December 31, 2029. Upgrading to PHP 8.3 makes little sense, because its support already ends on December 31, 2027.
Is outdated software an ISO 27001 nonconformity?
Not automatically. ISO 27001:2022 requires you, under A.8.8 and clause 6.1.3, to know, assess, and treat the risk. An EOL system with an upgrade plan or a time-limited risk acceptance can pass an audit, while a system that appears in neither the inventory nor the risk register regularly leads to a nonconformity.
How can I tell whether PHP is patched despite an old version number?
The version number alone will not tell you, because hosting providers and Linux distributions often backport fixes without a new number. Check the changelog of your distribution's PHP package, or ask your hosting provider to confirm in writing which CVEs are fixed. That confirmation also serves as evidence in the audit.
