What do PHP, Node.js, Next.js, and Linux vulnerabilities mean for your business? Learn which systems need security updates, who handles them, and how to verify the fixes.
October-November 2026 roundup. Last reviewed November 6, 2026.
Your website loads. Customers can sign in. Orders are coming through. Then a security advisory appears for something your application depends on.
Does it affect your business? Will your hosting provider fix it? Do your customers need to download a new app?
The PHP, Node.js, Next.js, and Linux disclosures covered here affect different layers of a system, with different conditions and different fixes. Understanding those differences helps you act quickly without turning every announcement into an emergency rebuild.
This guide explains the relevant October and early November updates, the responsibilities they create, and the questions worth asking your development team.
The short answer: check the running system, then verify the fix
Security maintenance means identifying affected software, applying the appropriate fix, and confirming that the corrected version is running wherever the application is deployed. A working website or a successful deployment alone does not establish that.
| Component | What needs attention | Where the work happens |
|---|---|---|
| PHP | PHP2Shell and subsequent October guidance | The PHP installation and its configuration |
| Node.js | October runtime vulnerabilities; another release scheduled for November 11 | The runtime used by the deployed backend |
| Next.js | October and November framework vulnerabilities | Application dependencies, deployment, and relevant caches |
| Linux | CVE-2026-98432 in network connection handling | The host operating system or provider-managed infrastructure |
The release details below are a dated reference. Before applying a fix, check the linked advisory for updates and choose a supported release containing the necessary patches.
PHP: PHP2Shell and the follow-up fixes
On October 21, PHP released fixes for CVE-2026-109618 and CVE-2026-109619, commonly called PHP2Shell. These critical vulnerabilities can allow remote code execution without authentication on PHP installations serving web requests, including PHP-FPM and Apache's mod_php.
The initial fixed releases were 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP urges immediate updating. Check the PHP security announcement and subsequent updates for deployment-specific guidance.
Two follow-ups matter:
- October 23: PHP recommended disabling session upload progress for an unusual configuration involving runtime changes to the session serialization handler. The advisory explains when this additional measure applies.
- October 26: rebuilt Windows packages—8.5.12-1, 8.4.27-1, 8.3.36-1, and 8.2.35-1—included a Brotli fix. The affected decoder can be reached through cURL when automatic response decompression is enabled. The PHP runtime version itself did not change.
Ask your team which PHP package is serving live requests and whether the follow-up guidance has been applied where relevant.
Also plan beyond this incident: PHP 8.2's official security support ends December 31, 2026. Distribution or commercial support may have different terms; confirm what your installation actually receives.
Node.js: updating project packages does not update the runtime
The October 21 Node.js security release addressed ten vulnerabilities. The highest official severity was High.
One, CVE-2026-111497, affects Brotli decompression. If an application decompresses attacker-controlled Brotli data through node:zlib, malformed input can corrupt memory, potentially causing crashes, disclosure of process memory, or remote code execution.
The fixed releases were 22.23.4, 24.22.1, and 26.12.1. Running npm update does not replace the Node.js executable. The deployment must use a patched runtime, and existing processes need to be restarted or replaced.
Another Node.js release is scheduled for November 11
As of November 6, the official November announcement schedules security releases for the 22.x, 24.x, and 26.x branches on or shortly after November 11. It identifies the highest severity as High but does not yet provide the final release versions or vulnerability details.
Plan to review that announcement when the releases arrive. An upcoming update is no reason to postpone an already available fix for an affected production system.
Next.js: the configuration determines the exposure
Next.js published separate security releases in October and November. They should be assessed together when an application has fallen behind.
The October 14 release included two critical remote-code-execution fixes and a high-severity denial-of-service fix. These involved particular Cache Components behavior, an image-processing dependency on glibc-based Linux, and App Router applications using Server Actions. Fixes were released in 16.4.1 and 15.5.28.
The November 3 release announced seven further fixes in 16.4.5 and 15.5.29. Important areas to review include:
- Cached content: specific Cache Components and use cache patterns can mix results between users or tenants, or poison shared page output.
- Self-hosted responses: certain combinations of application behavior and reverse-proxy connection handling can send responses to the wrong clients.
- Image optimization: an SVG rejection bypass requires a native image backend capable of decoding SVG. That finding alone does not demonstrate code execution.
There is also a distinct Edge cookie exposure issue. It affects both App Router Edge handlers and Pages Router Edge API routes using NextResponse.cookies.set(). Exploitation requires a sensitive cookie on an affected response and attacker-controlled JavaScript already running on the same origin.
Using Pages Router is therefore not enough to rule out every issue in the release. The assessment needs the actual routes, runtime, caching behavior, image pipeline, and hosting configuration.
After upgrading, rebuild and redeploy the application. Follow the hosting platform's instructions as well: Netlify's November guidance requires an adapter update for one case and explains why production, branch, and preview deployments need separate cache attention.
For a business owner, the useful outcome is a clear statement of which advisories apply, what was changed, and where the corrected application is now running.
Linux: cloud hosting does not settle who patches the server
CVE-2026-98432 concerns memory handling during IPv4 TCP connection setup in the Linux kernel. Ubuntu classifies it as critical. As of November 5, Ubuntu's tracker still listed fixes for the linux kernel package on 22.04, 24.04, and 26.04 LTS as work in progress. Check the status for your exact release and kernel package before assuming a fix is available.
The AWS bulletin, updated November 5, describes possible crashes, memory disclosure, and corruption, with remote code execution demonstrated against hosts with a Multipath TCP listener.
For affected Amazon Linux installations, AWS directs customers to update the kernel and reboot. Its guidance identifies that combination as the complete remediation for this issue.
Responsibility varies within AWS:
| Deployment | Responsibility described in the AWS advisory |
|---|---|
| Self-managed Linux on EC2 | The customer updates the instance kernel and reboots, following the distribution’s guidance. |
| EKS control plane | AWS has applied the fix. |
| EKS managed node groups, self-managed nodes, or Karpenter using affected AMIs | Customers update the nodes to the corrected AMIs. |
| Other managed services | Follow the service-specific instructions; replacement schedules and customer actions differ. |
Ask your provider or operations team to identify the exact service and remaining action. “Hosted on AWS” leaves too much unanswered.
How to confirm that a security update is complete
The practical challenge is keeping track of every running copy of the affected software. A backend may run on several servers, while workers, scheduled jobs, and preview environments use different builds.
We recommend organizing the work into five steps.
1. Identify the software actually handling requests
Commands such as php -v and node -v are useful starting points, but they report what the current shell invokes. PHP-FPM, a process manager, a container, or a background worker may use another installation.
Record the runtime, package or image version, environment, and deployment owner. Include externally accessible test systems that can reach real data or services.
2. Match the advisory to the application
Check both the affected version range and the conditions needed to reach the vulnerable code. For example, image processing, Edge routes, and server-side decompression are different capabilities and need separate checks.
For vendor-maintained Linux packages, consult the distribution's advisory. A backported fix can leave the upstream version number looking older than expected. Equally, an empty list of available updates is not proof that the system is safe: the relevant fix may not yet be available through its configured repositories.
3. Prioritize and prepare the change
Consider exposure, potential impact, any evidence of exploitation, and available mitigations. A serious remotely exploitable issue in an exposed production service deserves urgent attention.
Before deployment, confirm that usable backups and a recovery plan are available, then test the affected application flows. Keep the scope focused enough to understand failures. Combining an urgent patch with unrelated feature work makes troubleshooting harder.
4. Deploy to every affected environment
Depending on the component, this can mean restarting a service, rebuilding and replacing containers, redeploying the application, or rebooting a host. Check deployment templates too, so scaling or recovery does not launch an old image later.
Where the architecture supports it, update instances in stages and verify service health between steps.
5. Verify both the version and the product behavior
Confirm the running version after deployment. Then check the workflows your customers and operators depend on: sign-in, permissions, purchases, uploads, admin actions, and background jobs, as applicable.
Record what changed, where it was deployed, and what passed verification. If an update must be rolled back, explicitly track any vulnerability that rollback restores.
If there are signs of compromise, patching is only one part of the response. Investigating access, preserving relevant evidence, and assessing exposed credentials or data become separate tasks.
Do these security fixes require a new mobile app release?
The server-side issues discussed here generally do not require customers to install a new mobile app. The release path depends on where the vulnerable component runs and whether the fix changes the interface the app uses.
| Location of the fix | Typical delivery path |
|---|---|
| PHP or Node.js backend | Update and restart or redeploy the backend; check API compatibility. |
| Next.js website or web admin | Rebuild and deploy the web application, following cache and hosting guidance. |
| Server operating system | Apply the distribution’s fix and complete its activation steps. |
| Native code bundled into an iOS or Android app | Build and distribute an updated app through its release channel. |
| JavaScript in an Expo app | An over-the-air update may be possible if already supported by the installed app and compatible with its native runtime. |
Expo’s runtime documentation makes the key distinction: an update cannot replace the native code inside an installed build. A JavaScript fix must work with that existing native code; otherwise, a new build is necessary.
For owners, this means the team should identify the affected layer before estimating release work or waiting for app store review.
Why ongoing updates belong in the operating plan
These releases show why security work continues even when a product's features stay the same. A new disclosure changes what is known about software already in production. Follow-up guidance can also change the action required after an initial patch.
A useful operating agreement should identify who monitors advisories, who assesses exposure, who approves work, and who verifies deployment. It should also explain what happens when an urgent issue arrives outside the normal maintenance schedule.
At Petadev, protecting our clients' systems and their users' data is part of our ongoing work. For systems we operate, we monitor relevant security announcements, check whether they affect the application or infrastructure, and coordinate the necessary updates with the client on a project-by-project basis.
That responsibility should be clear from the start of an ongoing engagement. We explain the broader division between hosting, maintenance, warranty fixes, and new development in what happens after your app launches.
If an app has fallen several versions behind, our guide to upgrading an outdated React Native app explains how to plan the catch-up work.
Five questions to send your development team
You do not need to interpret every advisory yourself. Ask for answers that can be checked:
- Which of these vulnerabilities affect our deployed systems, and why? Include the version and relevant configuration.
- Who owns each fix? Name the hosting provider’s responsibilities and the work our team must perform.
- What is the update plan? Include timing, testing, expected interruption, and any temporary mitigation.
- How will we confirm completion? Ask for the running version and the workflows tested after deployment.
- What remains open? Include old deployments, unsupported components, pending vendor fixes, and the next advisory review.
Those answers turn a security headline into a practical maintenance decision.
Who's responsible for your next security update?
Tell us about your application, hosting setup, and current support arrangement. In a free initial consultation, we'll help you identify what needs checking and discuss the next steps.
