When working software suddenly needs urgent attention
The website loads. Customers can log in. Orders are coming through. From a business perspective, everything looks normal. Then a security advisory arrives, and software that was working perfectly yesterday needs urgent attention today. This week offered several examples of how quickly that can happen—and how much an application depends on components its users never see.
Critical PHP flaws beneath the application code
On 21 October, the PHP project released emergency fixes for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both can allow remote code execution without authentication. The project identified installations serving web requests as at risk, with the highest risk in Apache’s mod_php configuration, where a demonstrated attack can trigger before application code runs. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with distribution-specific fixes available through some vendors. That last detail matters. A carefully developed application can still be exposed through the runtime processing its requests. Updating the website’s content or its CMS plugins does not establish that the underlying PHP installation has been fixed.
Node.js and the runtime actually deployed
Node.js received security updates on the same day. Among the issues was CVE-2026-111497, a flaw in its bundled Brotli decompression code that can permit remote code execution. The Node.js project rates it High and released fixes in 22.23.4, 24.22.1 and 26.12.1. Exposure depends on whether attacker-controlled compressed data reaches the vulnerable decoder. Imperva demonstrated code execution in specific applications using an official Node.js Linux arm64 image, through both incoming compressed requests and responses fetched from another server. Its tests also confirmed that the patched runtime rejected the same inputs.
Updating a dependency file is only one step
For operators, this means checking the runtime actually deployed inside each service and container. Updating a dependency file is only one step; the running application must receive the corrected software.
When the software update becomes the risk
The week also exposed a different risk: the software update itself. LiteLLM reported that its release pipeline had been compromised on 21 October. A malicious v1.107.0 release reached Python package and container registries, containing credential-stealing malware and remote-access functionality. The affected artifacts were subsequently removed. According to the project, its private enterprise release was unaffected. That incident requires a different response from an ordinary vulnerability. If a malicious package has run, replacing it alone cannot establish that credentials remain safe. Investigation, containment and credential recovery become part of the work.
Certificates can trigger urgent maintenance too
Meanwhile, Google and Mozilla published responses on 20 October to compromised eMudhra intermediate certificate keys, reported to them on 17 October. Google attributed the weakness to insufficient randomness during key generation and blocked the affected keys. It also announced removal of the associated root from Chrome’s trust store, expected on 27 October, requiring affected website operators to replace their certificate chains. An application can therefore need urgent maintenance even when its own source code has not changed.
Maintenance is an ongoing business responsibility
Taken together, these incidents make a practical case for treating maintenance as an ongoing business responsibility. Every organisation operating software should be able to answer:
- What are we running? Include runtimes, container images, dependencies and certificate chains.
- Who owns the response? Establish responsibility across developers, hosting providers and internal teams.
- How quickly can we deploy a fix? Keep testing, deployment and rollback procedures usable.
- How do we confirm completion? Verify the software running in production after deployment.
- What happens if compromise is suspected? Have a process for investigation, recovery and replacing exposed credentials.
A business continuity problem waiting for a deadline
The most uncomfortable situation is an application that cannot be updated because nobody understands its dependencies, its original supplier has disappeared, or routine maintenance has been postponed for years. That is a business continuity problem waiting for a deadline. This week provides a good reason to review that position. Keeping software safe requires visibility, clear ownership and the ability to change it while the business continues to operate.