A critical security fix can be available from the software project and still be missing from the package repository your server uses.
That distinction mattered during the October 21 PHP security emergency. It also shaped our response for CollegeInbound-hosted websites, where we applied the updates without taking sites offline.
For anyone responsible for a business website, the practical question is simple: when an urgent fix is released, how does it reach your production environment?
What happened
On October 20, the PHP project announced an upcoming security release addressing two critical vulnerabilities, both rated 9.2 out of 10. The fixes were released on October 21.
The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, can allow an attacker to execute code on an affected server without logging in. Because PHP is used by many web applications, including WordPress, the response required action at the hosting layer.
Updating website content, themes, or plugins does not replace updating the PHP runtime underneath them.
PHP’s guidance also made an important distinction: temporary measures could reduce exposure to specific attack paths, but applying the update was the complete fix.
The update source is part of your security response
Servers do not all receive PHP from the same place.
One might use packages supplied by its operating system vendor. Another might use a third-party repository to obtain newer PHP releases. A third might run a custom build.
Each arrangement has its own path from an upstream security fix to an installed production package.
That means “PHP has released a patch” and “our servers have the patch” are two different statements. Someone needs to know which packages are available, which hosts need them, and how the changes will be applied.
What we found in the CollegeInbound environment
Our inventory covered the hosts, their PHP versions, and the repositories supplying their packages.
Some hosts used Ubuntu’s PHP packages. Others used a third-party repository that provided newer PHP releases.
At the point we needed the fixes, Ubuntu’s patched packages were available, while the third-party builds those hosts depended on were not yet available.
For the affected hosts, we applied interim hardening to reduce exposure and moved them onto Ubuntu’s patched packages the same day. The hardening was a temporary step while the package changes were completed.
We began applying the fixes at 11:12 a.m. Eastern on October 21 and finished that afternoon. No CollegeInbound-hosted site was taken offline.
Knowing the environment helped us act without first having to investigate how each server received its software.
Read the CollegeInbound incident account.
A newer version number does not tell the whole story
Third-party repositories can provide useful access to newer PHP releases. Operating system packages may stay on an older release line while receiving security fixes through backports.
That is why the headline version number alone is not enough to determine whether a server is patched.
For a vendor-maintained package, the relevant questions include whether the operating system release is still covered, whether the package receives security updates, and whether the installed package revision contains the fix.
Ubuntu’s security trackers list fixed package versions for both vulnerabilities. Some older operating system releases require additional support coverage.
For the CollegeInbound hosts we moved, the supported operating system packages provided the update path we needed. That was an operational decision for those sites, not a rule that every third-party repository should be avoided.
Three questions worth asking your hosting provider
-
Where does our PHP come from?
Ask whether it is supplied by the operating system vendor, a third-party repository, or a custom build. There should be a clear owner for that update path.
-
What happens when an urgent fix is released?
The answer should cover identifying affected systems, obtaining the corrected packages, applying the update, and checking the running website afterward.
-
How do you know when a critical update is waiting?
A team may deliberately control update timing to account for compatibility and service restarts. That approach still needs a reliable way to identify urgent patches and get them applied.
Preparation makes urgent patching more manageable
An accurate inventory and a supported package source are routine parts of hosting operations. During an emergency, they become immediately useful.
The CollegeInbound response showed why. We knew which hosts needed attention, where their packages came from, and where we needed to change the update path.
For website owners, that is a useful conversation to have before the next security advisory arrives.
Sources
PHP security advisory and release announcements
Ubuntu security tracker, CVE-2026-109618