PHP 8.2 End of Life: Upgrade Before 31 December 2026

If your WordPress or Laravel site runs PHP 8.2, you have a deadline. PHP 8.2 end of life is 31 December 2026, and after that date the PHP project will ship no further security fixes for it. A critical security release on 21 October 2026 showed exactly what that means for sites that fall behind.

This guide explains the dates, why the October release matters, how AI tools are speeding up both attack and defence, and how to upgrade without breaking your site.

The PHP 8.2 end of life date and what replaces it

Each PHP branch first gets active support, with bug and security fixes, and then a period of security fixes only. PHP 8.2 came out on 8 December 2022 and has been security-only since its active support ended on 31 December 2024. Here are the dates from php.net's supported versions page, as viewed in late October 2026:

PHP 8.1, 8.0 and 7.4 are already end of life. Also note that PHP 8.4 leaves active support on the same day 8.2 dies, so from 1 January 2027 only 8.5 is in active support. PHP 8.6 is still a release candidate, and php.net says do not use it in production. Its general release is planned for 19 November 2026.

Why the October 2026 security release matters

On 21 October 2026, every supported branch got a patch on the same day: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The security advisory explains why. Two critical bugs in PHP itself let a stranger run their own code on your server, with no login needed. Their records are CVE-2026-109618 and CVE-2026-109619. The researchers at Wiz nicknamed the pair PHP2Shell, which is the name most news coverage uses. php.net itself does not use it.

Both flaws score high. php.net rates them 9.2 on CVSS 4.0, while NVD scores them 9.8 and 8.1 on CVSS 3.1. On workarounds, the PHP project is blunt: "There are no complete mitigations, updating is the only safe choice."

A stopgap setting and the 23 October follow-up

php.net does offer one stopgap for the hours before you can update. Turn off session.upload_progress.enabled in php.ini, in your PHP-FPM pool file or in the server config, then restart every PHP worker. Setting it with ini_set() or a .user.ini file does not count. It closes the known routes but not every variant, so treat it as a seatbelt, not a fix.

; php.ini or PHP-FPM pool config, then restart PHP
session.upload_progress.enabled = 0

On 23 October, php.net added a follow-up: a third, less likely route to running code, CVE-2026-115560, which also affects the patched releases. Its full advisory is due with the next regular bugfix release. Until then, php.net suggests keeping that setting off even after you update.

Reports on attacks differ. Security vendor watchTowr reports seeing exploitation in the wild since 21 October. Canada's Cyber Centre said in its 23 October update that proof-of-concept code is public, but it had not identified active exploitation. As of 26 October 2026, neither CVE was in the CISA Known Exploited Vulnerabilities catalog. Either way, the code to attack it is out, so do not wait for confirmed attacks.

Now look at what older branches got. Because the flaws were so severe, the PHP security team made an exception and published minimal source-only backports for 7.4, 8.0 and 8.1. Those are not releases. For anyone still on those branches, php.net points out that "some distributions and LTS vendors provide backported fixes". If that is you, ask your host what they actually ship. After 31 December, PHP 8.2 joins that group. Do not plan around another exception.

What this means for WordPress sites

WordPress.org says no WordPress update is required for these issues. The fix lives in PHP itself, so it is your host's job, or yours. That matters because so many sites lag behind. As of 26 October 2026, per WordPress.org's PHP version statistics, about 23.3% of WordPress sites run PHP 8.2 and about 34.0% run 8.1 or older. If nothing changes, about 57% of WordPress sites will run PHP without upstream security support on 1 January 2027.

Part of the reason is that WordPress still runs on PHP 7.4 or newer, so nothing forces an upgrade. Even so, WordPress recommends PHP 8.3 or greater.

AI tools are shrinking the time to patch

Finding bugs is getting faster. Earlier in 2026, the PHP Foundation and Alpha-Omega scanned PHP with Anthropic's Claude Mythos. Since then the team has added OpenAI's Daybreak Red to validate reports and exploits. According to the PHP Foundation, its security team has published 15 CVEs since 1 July 2026, and AI-assisted research means it gets far more reports than before.

Frameworks see the same trend. Symfony reports that Claude Mythos Preview found 19 vulnerabilities in Symfony and Twig, and all 19 turned out to be real.

The PHP Foundation sums it up: "Tools now find bugs faster than ever, for defenders and attackers alike." Once a fix is public, attackers can study it while many sites are still waiting to update. For the WordPress ecosystem, the vendor Patchstack reports a weighted median of 5 hours to the first exploit attempt for heavily exploited flaws in 2025. It measures that from when its own protection rule goes live. Patchstack also counted 11,334 new WordPress-ecosystem vulnerabilities in 2025, 91% of them in plugins.

So the lesson is simple. On supported PHP you are racing a short clock. On unsupported PHP there may be no fix to race with at all.

If AI agents call into your PHP app, limit what they can do

Many PHP apps now give AI assistants a way in: a plugin that connects to a chatbot, an API, or a Model Context Protocol (MCP) server. Paraline Tech built a remote MCP endpoint that lets AI assistants act on a Laravel marketplace, so this is a real design question, not a future one.

The risk is not the model itself. It is what the model is allowed to do. OWASP lists prompt injection as LLM01: text the AI reads from a website or file can carry hidden instructions. It lists excessive agency as LLM06, caused by too much functionality, too many permissions or too much autonomy. OWASP's advice translates into four rules for a PHP app:

• Least privilege. Give each tool only the access it needs, for example a database user that can read orders but not delete them.
• Authorization in PHP. Check permissions in your code on every tool call. Never let the model decide.
• Human sign-off. Make a person approve refunds, deletions and other privileged actions.
• Untrusted input. Treat anything the AI fetched as user input, and validate it.

In Laravel, the tool handler should run the same policy check as any other request:

<?php

namespace App\Actions;

use App\Models\Order;
use Illuminate\Support\Facades\Gate;

final class RequestOrderCancellation
{
    public function handle(int $orderId): array
    {
        $order = Order::findOrFail($orderId);

        // PHP decides, not the model. Throws a 403 if the user may not cancel.
        Gate::authorize('cancel', $order);

        // Flag it for a person to approve instead of cancelling directly.
        $order->status = 'cancellation_requested';
        $order->save();

        return ['status' => 'awaiting human approval'];
    }
}

None of this helps if the PHP underneath is unpatched, so the upgrade still comes first.

Your PHP upgrade checklist

Follow these steps in order. Only step 7 changes the live site.

1. Check your version. In WordPress, go to Tools > Site Health > Info > Server. In Laravel, run php artisan about or php -v on the server.
2. Patch today. Whatever branch you use, run at least 8.2.35, 8.3.36, 8.4.27 or 8.5.12, as of late October 2026. Keep session.upload_progress.enabled = 0 until the next bugfix release, which is expected to fix CVE-2026-115560.
3. Pick a target. Choose 8.3 or newer, and 8.4 or 8.5 if you want a longer runway. WordPress 7.0 and 7.1 are marked compatible with 8.2 to 8.5.
4. Check Laravel. Per the Laravel release notes, Laravel 12 supports PHP 8.2 to 8.5 and gets security fixes until 24 February 2027. Laravel 13 needs PHP 8.3 or newer and gets them until 17 March 2028. Laravel 11 lost security fixes on 12 March 2026, so upgrade it too.
5. Copy the site to staging. Switch staging to the new PHP version first, never the live site.
6. Test plugins, themes and packages. Update them on staging, then watch the error log while you click through forms, logins and checkout. Developers can run composer why-not php 8.4 to see which packages block a version.
7. Back up, then switch live. Take a full backup first. Most hosts offer a PHP version selector in the control panel. If yours does not, ask your host when they will move you, and how they handle old branches.
8. Watch and keep a rollback. Check the error log for a few days, and switch back if something breaks.

What to do next

Check your PHP version today and put the upgrade in your calendar for November, well before 31 December. If you would rather hand it over, Paraline Tech looks after WordPress sites and runs ongoing maintenance through Managed Tech. Get in touch and we can plan the move with you.