Four Security Advisories in One Month: How We Decided What to Patch

A Busy Month for Anyone Running Web Applications

October 2026 was not a quiet month for server maintenance. Within roughly a week, four separate projects published security advisories that touch the kind of stack many business applications run on:

• Ubuntu / Linux kernel: CVE-2026-98432, a critical TCP vulnerability, published on 15 October.
• Laravel: two advisories, CVE-2026-114509 and CVE-2026-114508, published on 19 October.
• PHP: two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October.
• Node.js: a security release with ten CVEs, led by CVE-2026-111497, also on 21 October.

Headlines like these tend to produce one of two reactions: panic, or the assumption that someone else has dealt with it. Neither protects an application. What protects it is a calm, repeatable process: find out which advisories apply, act on the ones that do, and prove that the action worked.

This article describes how we handled that month. The technical details of each vulnerability and each command are already published on qadrlabs, our learning platform, and linked at the end. Here we focus on the decisions, because those are what an application owner should expect from whoever maintains their systems.

Step One Is Not Patching. It Is Matching.

The first question for every advisory is simple: does this affect anything we actually run?

Answering it requires an up-to-date inventory of the stack: operating system and kernel, web server, language runtime and its version, framework and its version, and any other runtimes such as Node.js. Without that inventory, a team either patches everything blindly or, worse, assumes that nothing applies.

For the projects we maintain, the answer split cleanly into three groups:

Each row needed a different kind of work. Treating all four the same way would have wasted effort on one and under-protected another.

PHP: Installing the Patch Was the Easy Part

The PHP team gave an unusual advance notice on 20 October, saying that two critical vulnerabilities, both rated CVSS v4 9.2, would be fixed the next day. On 21 October the patched releases arrived: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Our production server runs Ubuntu 24.04 with Nginx and PHP-FPM, with both PHP 8.4 and 8.5 installed. The upgrade itself was a routine package update. The real work was what came after it.

Checking the runtime that serves requests

php -v reports the version of the command-line PHP. A website, however, is served by PHP-FPM, which can be a different binary or even a different version. So we checked each one separately: the CLI, each PHP-FPM service, and which version Nginx actually passes requests to. A patched CLI on its own proves very little.

Finding something that had nothing to do with the CVE

While confirming where the PHP packages came from, we found two overlapping package sources configured on the server. The patched versions were already installed, so this was not a security gap. It was, however, the kind of inconsistency that makes the next update harder. We treated it as a separate maintenance task, simulated the change before applying it, and aligned the packages to a single source.

Keeping the two tasks apart mattered. The security objective was met as soon as the patched versions were running. The repository cleanup was housekeeping, and it was planned and tested as such.

Verifying after the reboot, not only before

The same update window also installed a newer kernel, so we rebooted the server. After it came back, we checked again: Nginx and both PHP-FPM services running, the expected PHP version reported, no services left on outdated binaries, and the public application responding normally.

A successful installer message is not evidence. A running service, the right version, and an application that answers requests are.

Laravel: A Fix That Shipped Before the Announcement

The Laravel advisories followed a different pattern. The fixes were released on 25 August 2026 in Laravel 12.68.0, 13.27.0 and 13.29.0 as part of normal version updates. The security details were only published on 19 October.

• CVE-2026-114509 is rated critical (CVSS v4 9.2). It affects applications that use the built-in token authentication guard with a MySQL or MariaDB database, and it can allow authentication to be bypassed.
• CVE-2026-114508 is rated moderate (CVSS v3.1 6.5), but its impact is unauthorised deletion of data, which no business would describe as moderate if it happened to them.

We updated the framework in our Laravel applications to a release that contains both fixes, then ran the usual checks that the applications still behaved as expected.

The timeline carries a lesson of its own. Applications that receive regular dependency updates were protected for almost two months before anyone knew there was a problem. Applications whose dependencies were frozen became exposed the moment the details went public. Routine updates are not glamorous, but they are often the reason an advisory turns out to be a non-event.

Node.js: Deciding That No Action Is Needed Is Still a Decision

The Node.js release on 21 October fixed ten vulnerabilities across its supported lines, with patched versions 26.12.1, 24.22.1 and 22.23.4. The most serious, CVE-2026-111497, is a potential remote code execution issue in Brotli decompression.

Node.js is not part of the runtime stack of the projects we maintain, so there was nothing to patch. That does not mean the advisory was ignored. It was read, checked against the inventory, and recorded as not applicable, together with the reason.

That record is useful. If a client asks whether they were affected, the answer is already written down. If Node.js is ever added to a project, the decision will need to be revisited, and the note makes that obvious.

Ubuntu Kernel: When the Patch Does Not Exist Yet

The hardest kind of advisory is the one without a fix. CVE-2026-98432 is a critical vulnerability (CVSS 9.8) in how the Linux kernel sets up TCP connections. When it was published, Canonical listed fixed kernels as "work in progress" for the supported Ubuntu releases, including 24.04. No active exploitation had been reported.

There is nothing to install in that situation, so the work becomes monitoring. Since October we have been checking the status of the fix regularly, so that the patched kernel can be installed and the server rebooted as soon as Canonical publishes it. Until then, the honest status for this advisory is "affected, fix pending, being watched", not "resolved".

What This Means If You Own an Application

You do not need to follow every security mailing list yourself. You do need confidence that someone is doing it on your behalf, and that they work in a way you can check. Here is what we would expect from any maintenance partner, including ourselves:

1. They know your stack. They can tell you, without guessing, which operating system, runtime, framework and versions your application uses.
2. They respond per advisory, not per headline. Each advisory is matched against your stack and placed in one of three groups: patch, not applicable, or monitor.
3. They verify, not just install. After a patch they confirm the version that actually serves requests, the health of the services, and that the application still works.
4. They separate security work from housekeeping. Problems found along the way are fixed deliberately, not mixed into an urgent change.
5. They tell you what was done. A short report listing each advisory, its relevance to you, the action taken and the evidence is enough. It should also include advisories that did not apply.
6. They keep dependencies current between incidents. Regular updates are what turn many advisories into non-events.

If you cannot get clear answers to these points from whoever maintains your application today, that is worth addressing before the next busy month arrives.

The Technical Details

For administrators and developers who want the full technical picture, our learning platform qadrlabs covers each advisory in depth:

• PHP Critical RCE Vulnerabilities CVE-2026-109618 and CVE-2026-109619: What Happened and How to Protect Your Servers
• How We Patched Critical PHP RCE Vulnerabilities on an Ubuntu 24.04 Server
• Laravel Security Advisories CVE-2026-114509 and CVE-2026-114508
• Node.js October 2026 Security Release: Brotli RCE (CVE-2026-111497) and Nine More Fixes

Closing

Security advisories will keep arriving, often several at once. The difference between a stressful week and a manageable one is rarely technical skill alone. It is knowing exactly what you run, deciding calmly what each advisory means for it, and confirming that the fix is really in place.

If you are not sure how your application would fare in the next round of advisories, we are happy to look at it with you. Get in touch and tell us what your application runs on; we will start from there.