On June 4, 2026, the PHP team pushed two releases: PHP 8.4.22 and PHP 8.5.7, both routine bug-fix updates. Notice what’s missing: no 8.2 release, no 8.3 release. That’s not an oversight — it’s the lifecycle working as designed. Once a PHP branch exits active support, it receives security patches only when a qualifying CVE appears. Routine bug fixes stop. June was a bug-fix month, so 8.2 and 8.3 sat it out.

That’s fine for now. The larger issue is the clock: PHP 8.2 reaches full end-of-life on December 31, 2026. Six months out. After that date, no patches of any kind — bug fix or security — will be issued for the 8.2 branch. Any CVE disclosed on January 1, 2027 or later will stay unpatched on 8.2 forever.

Where Things Stand Right Now

The currently supported PHP landscape looks like this:

  • PHP 8.1 — already EOL as of December 31, 2025. If you’re still on it, you’ve been running unpatched software for six months.
  • PHP 8.2 — security-only patches until December 31, 2026, then gone.
  • PHP 8.3 — security-only patches (active support ended late 2025), EOL December 31, 2027.
  • PHP 8.4 — full active support with monthly bug fixes; EOL December 31, 2028.
  • PHP 8.5 — newest branch, full active support; EOL December 31, 2029.

The practical read: if you want to be on a branch that gets regular bug fixes, not just emergency security patches, you need 8.4 or 8.5. If 8.3 or 8.2 is acceptable for now, fine — but set a hard deadline, and for 8.2 that deadline is six months away.

Why EOL Actually Matters

The usual framing is “no more security patches = bad,” and that’s true. But the specific mechanism is worth understanding.

When PHP is actively maintained, a CVE gets filed, the PHP team investigates, a patch ships, and you upgrade. The exposure window is the time between discovery and your next update cycle — measured in days to weeks.

When PHP goes EOL, that loop breaks. CVEs still get filed. Researchers still publish proof-of-concept exploits. Automated scanners still find your version string. The difference: no patch ships. The exposure window becomes permanent.

Worse, most vulnerability scanners flag known CVEs against running software. EOL software generates a subtler risk: future CVEs that your scanner can’t possibly know about yet. You’re not running software with zero known vulnerabilities; you’re running software where the known vulnerability list will only grow, with no remediation path.

For a PHP application on a shared hosting server — WordPress, an older Laravel app, a billing portal — this is a genuine operational risk, not a theoretical one.

The Compatibility Question

The reason sites linger on old PHP versions is almost always compatibility, not laziness. PHP 8.x made breaking changes relative to 7.x, and some older plugins, themes, or custom code still rely on deprecated functions. Between 8.2 and 8.4, the changes are more incremental, but they’re there.

Before December, the checklist is short:

  1. Find out what PHP version your site is actually running. In cPanel, it’s under “MultiPHP Manager.” On a VPS, php -v or php8.2 -v depending on how it’s installed.
  2. If you’re on 8.1, treat this as urgent — you’re already EOL.
  3. If you’re on 8.2, test your application against 8.4 in a staging environment now, while you have time to troubleshoot.
  4. If you’re on 8.3, you have until December 2027, but the same staging exercise is worth doing at a relaxed pace.
  5. If you’re on 8.4 or 8.5, you’re current. Nothing to do for now.

The worst time to discover a PHP upgrade breaks your application is after a forced migration under time pressure. Six months is a comfortable window to test; two weeks is not.

What This Means for kalfaoglu.net Customers

We support PHP 8.2, 8.3, 8.4, and 8.5 across all hosting plans. If your site is currently running on 8.2, you can switch to 8.4 via the control panel’s PHP version selector without downtime — the change is per-domain and instantaneous to apply. Whether it works cleanly depends on your application, which is why testing in staging first is the sensible move.

If you’re unsure what version you’re on or want help testing an upgrade, open a support ticket. We’d rather spend 20 minutes helping you migrate on a schedule than untangle a broken site in December under pressure.

PHP 8.1 customers: if any exist, this is already urgent. The branch has been unsupported for six months and you’re accumulating unpatched CVEs with each passing week. Upgrade now.