luroConnect

The Gap Between a Patch and a Package

By Pradip Shah ·

Source, build, package, server: the build step is the one we own. The Gap Between a Patch and a Package, PHP2Shell, October 21, 2026

The night of October 21

At 19:30 IST on Wednesday, October 21, the PHP project released fixes for PHP2Shell. By 06:00 IST the next morning, every luroConnect server running PHP 8.2 to 8.5 was patched. We did not wait for packages to do it.

PHP2Shell is two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, present in every PHP version since PHP 5. PHP runs Magento, WordPress and most of the commerce web. Details leaked a day before the planned disclosure, the PHP security team brought its release forward, and attacks were reported around the time the fix shipped.

A fix in source code is not a fix on a server. The normal path from one to the other runs through a packager, and that night the packages we normally rely on were expected the following day.

Time (IST) What happened
Wed 21 Oct, 01:03 PHP security team announces an emergency release for later that day
Wed 21 Oct, as details emerged We add edge rules and php.ini limits across the fleet as mitigations
Wed 21 Oct, 19:30 PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 released as source
Wed 21 Oct, before 23:30 Our own builds of the patched versions start rolling out
Thu 22 Oct, 06:00 PHP 8.2 to 8.5 patched across the fleet
Thu 22 Oct, night Older PHP 7.4 to 8.1 systems patched with Remi’s packages

Why there is a gap

The PHP project publishes source code. Servers do not run source code; they run compiled software, installed as packages.

Someone has to turn the source into packages for each Linux release and each PHP version still in use. For the Red Hat family of Linux, the most widely used source of current PHP packages is Remi Collet’s repository. It is a remarkable piece of community work, maintained largely by one person, covering many PHP versions across many operating system releases.

Next-day packages for an out-of-cycle emergency release are a reasonable pace for that workload. The problem is not the packager. The problem is that a host relying only on pre-built packages has handed its patch schedule to someone else’s calendar, and attackers do not keep that calendar.

Holding the line until the build was ready

Mitigations bought the hours between the announcement and our builds. Both flaws sat in how PHP handles file uploads and upload progress tracking, so that is where we closed the doors.

  • At the edge: ModSecurity and nginx rules dropped requests carrying multipart forms, the request type used for file uploads, before they reached PHP. ModSecurity is the web application firewall built into our nginx.
  • In PHP’s own settings: php.ini changes limited session upload progress tracking and the size of uploads.

We tightened these as more information about the flaws emerged. Mitigations are blunt instruments. They reduce exposure for hours, but they are not a fix, and some of them get in the way of legitimate use. The fix was the patched PHP build.

We had built this muscle on nginx

Building PHP that night was not improvised. We have built our own nginx for years, and the reasons accumulated one at a time.

  1. OpenSSL. We needed nginx linked against a specific OpenSSL library, not the one the distribution package was built with.
  2. ModSecurity. We wanted the current ModSecurity, not the version a pre-built package happened to include.
  3. njs and QUIC. Owning the build let us add njs, nginx’s JavaScript module, and QUIC support.
  4. HTTP/3. QUIC is what HTTP/3 runs on. Our customers got HTTP/3 because we controlled the build, not because a package caught up.

Each step was a small decision. Together they produced a build pipeline, a private package repository, and a team that knows how to compile, test and roll out a core server component. On October 21 we pointed that same machinery at PHP.

We built from Remi’s source packages. His packaging work, the build recipes and patches that make PHP install cleanly, stayed intact. What changed was who ran the build and when.

Own the critical path, buy the rest

Hosting can be done entirely with pre-built software: Docker images, RPM packages, vendor defaults. Most days that is the sensible choice. The question is which few parts are worth owning.

Manufacturing has an answer. Ford’s River Rouge plant took in iron ore at one end and shipped finished cars at the other. It is the classic picture of total vertical integration, and also the classic example of owning more than you need to. Zara is the better model. It keeps the time-critical steps of making clothes close to home and in its own hands, and buys the rest. The reason to own a step is speed when it matters, not control for its own sake.

For a hosting company, the time-critical steps are the components that face the internet and get emergency patches. This is how we split it:

Component How we get it Why
nginx Built in-house Our choice of OpenSSL, current ModSecurity, njs, QUIC and HTTP/3
PHP 8.2 to 8.5 Built in-house from Remi’s source packages when timing matters Patch schedule set by us
PHP 7.4 to 8.1 Remi’s pre-built packages Remi backports security fixes to versions the PHP project no longer supports
Operating system and most libraries Distribution packages No timing or build-option advantage in owning them

The third row matters as much as the first. PHP officially supports only 8.2 to 8.5. Fixes for older versions exist because packagers like Remi do the backporting work. Owning the critical path does not mean replacing the community. It means knowing exactly where you depend on it, and being able to step in where the timing is yours to control.

What a software factory costs

Owning part of the supply chain is not free, and it is worth being plain about the price.

Pre-built packages Owned builds
Patch timing Set by the packager Set by you
Build options The packager’s choices Yours
Watching for vulnerabilities Partly delegated Entirely yours
Testing against extensions Done by the packager Done by you, against the extensions your customers actually run
Infrastructure A repository you subscribe to Your own package repository or image library, build hosts, signing
Skills Package management Compiling, packaging, staged rollout, rollback

The infrastructure is the easy part. The hard part is the last row. A build pipeline that is used once a year rots, and so does the knowledge of how to run it. Ours stays exercised because nginx goes through it routinely. When PHP needed it, the pipeline worked and the people who run it did not have to relearn anything at night.

This is the real argument for a software factory. Most days it produces small advantages: a newer library, a feature a little earlier. On the rare day the supply chain is too slow, it is the difference between hours and days.

If you run an online store: questions for your host

Most hosting support is built for the everyday: a ticket raised, a service restarted, a status page updated. That is necessary, and it is not what protected stores during PHP2Shell. What mattered was whether anyone behind the support desk could act on the software itself.

If your store runs on Magento, Adobe Commerce, WordPress or WooCommerce, it runs on PHP. These are fair questions to ask your hosting partner about last week:

  1. When was the fix running on my servers? A time, not “soon” or “as soon as packages are available”.
  2. What protected my store before the fix was installed? If the answer is nothing, that is useful to know.
  3. If your package source is a day late, who on your team can build the software? A host that can only install what others have built will always be at least that day behind.
  4. Which of my sites run a PHP version the PHP project no longer supports, and where do their fixes come from? Older versions can still be patched, but someone has to know who is doing that work.

A host that answers with times and specifics knows its own stack. A host that answers with reassurance may not. The difference rarely shows on an ordinary day. It shows on nights like October 21.

The factory has to exist before the fire

We still use pre-built packages for most of what we run, and we will keep doing so. The supply chain works almost every day, and community packagers like Remi are a large part of why.

But the days it is too slow are the days that matter most, and nobody builds a factory on the night it is needed. We had ours because nginx made us build it years ago. On October 21 that meant ten and a half hours from PHP’s release to a patched fleet, with mitigations in place before the release arrived.

Sources