Tech debt always gets repaid
To paraphrase Valery Legasov, from the HBO series Chernobyl:
“Every upgrade we avoid incurs a debt to future exploits. Sooner or later, that debt is paid.”
Every organisation carries some tech debt. The ones that manage it pay a little and often. The ones that ignore it pay all at once, usually during a security emergency. In October 2026 a pair of serious flaws in PHP, one of the most widely used technologies on the web, showed exactly how that plays out.
What tech debt is
Tech debt is the cost of putting things off. Every time an upgrade is delayed because the system still works, or a replacement is pushed to next year's budget, the organisation borrows against the future.
That is often a sensible decision in the moment. There is always something more urgent. But like any loan, the debt doesn't go away. It sits on the books, and it grows.
Why it has to be managed
Tech debt accrues interest. Each skipped update makes the next one bigger. Other software stops working with your old version. The people who understood the system move on. A small, routine upgrade turns into a large, risky project.
The bigger danger is that software doesn't stay supported forever. Every product has an end-of-life date, after which its makers stop fixing security problems. Systems keep running past that date, often for years, without anyone noticing that they are no longer protected.
And the debt is always repaid eventually. The only question is when, and on whose terms.
Paid on schedule, it's a planned piece of maintenance. Left too long, it gets called in by an attacker, at the worst possible moment, with no good options left.
A real example: the PHP flaws of October 2026
PHP is the software behind a huge share of websites and web applications, from WordPress sites to internal business tools. On 21 October 2026 its developers released urgent fixes for two serious flaws, nicknamed "php2shell". Either one could let an attacker take control of a web server without needing a password.
Attackers moved fast. The first attempts to exploit the flaws were seen four days before the fixes were even published, and attacks were under way on the day of release.
Current version
For organisations running a current version of PHP, the answer was simple: install the update.
End-of-life version
For those running older versions that had reached end of life, there was no ready-made fix. Their choices were all poor: rush through a major upgrade under pressure, build unofficial fixes themselves, take the service offline, or leave it exposed and hope.
The flaw was the same for everyone. What made the difference was whether the tech debt had already been paid.
One more warning: PHP 8.2, still in use in many places, reaches end of life on 31 December 2026. Those who stay on it will be in the second group next time.
How HowTech can help
HowTech helps you pay down tech debt steadily, so it never gets called in by an attacker.
Know what you have.
We keep an up-to-date record of the software and systems you run, including the ones hidden inside other products.
Watch the deadlines.
We track when each system reaches end of life and raise it well in advance, so there's time to plan.
Keep things updated.
Security updates are tested and applied on a regular schedule, with a fast track for urgent fixes.
Plan the bigger moves.
When a major upgrade is due, we plan it, test it and schedule it around your business.
Act fast when it matters.
When a serious flaw like php2shell appears, we check whether you're affected and deal with it.
Keep costs predictable.
Maintenance becomes a steady, budgeted cost rather than an unplanned emergency project.
The result: when the next serious flaw is announced, it's a routine update rather than a crisis.
Technical appendix
For IT teams who need the detail.
The vulnerabilities
Both flaws are in PHP's core request handling, so every PHP web stack is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Both are rated CVSSv4 9.2 and allow unauthenticated remote code execution (Tenable, Rapid7).
| CVE | Flaw | Worst exposure |
|---|---|---|
| CVE-2026-109618 | Out-of-memory during a request leaves half-built data that clean-up code then trusts | Apache mod_php, before any application code runs |
| CVE-2026-109619 | Use-after-free: stale state from one request points at freed memory used by a later one | mod_php and PHP-FPM via session upload progress |
Fixed in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Exploitation attempts were seen from 17 October 2026.
Version support
| Branch | Security support ends | Fix for php2shell |
|---|---|---|
| 8.3, 8.4, 8.5 | 2027 or later | Official release |
| 8.2 | 31 December 2026 | Official release |
| 8.1 | Ended 31 December 2025 | Source backports only |
| 8.0 | Ended 26 November 2023 | Source backports only |
| 7.4 | Ended 28 November 2022 | Source backports only |
| 7.3 and older | Ended | None |
Dates from HeroDevs.
Checklist
- 1Inventory every PHP runtime, including appliances, containers and vendor products, with exact version and SAPI.
- 2Patch to a fixed release or your distro's fixed package, then restart every PHP worker.
- 3Where patching must wait, set memory_limit=-1 administratively, session.upload_progress.enabled=0, and on 8.5 fatal_error_backtraces=0. These reduce exposure; they are not a fix.
- 4Isolate or put a WAF in front of anything internet-facing that stays unpatched.
- 5Look for signs of compromise from 17 October onwards.
- 6Plan the move off 8.2 before 31 December 2026.
Source: Tenable, "php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ". Two critical PHP vulnerabilities could lead to unauthenticated remote code execution. Patches are available for supported PHP 8.x branches.
Want to know how much tech debt you're carrying?
We'll help you find it, plan it and pay it down before an attacker calls it in.
Related insights
Fraudsters compete with each other, borrowing what works and dropping what doesn't – and what finance directors need to know.
The Five Eyes intelligence agencies have warned that advanced AI models are months away from fundamentally transforming cyber attacks.
The Cyber Security and Resilience Bill pulls IT providers and their supply chains into scope.