PHP2Shell, Node.js, GitLab, Zeabur and Signal: security issues and fixes

Use Valyu DeepResearch to investigate CVE-2026-109618 and CVE-2026-109619, establish which fixes apply, and turn the findings into an actionable remediation plan.

PHP2Shell is the public name used for two critical remote code execution vulnerabilities in PHP itself: CVE-2026-109618 and CVE-2026-109619. Both have a CVSS v4.0 severity score of 9.2 out of 10, according to PHP's OOM corruption advisory and stale global state advisory. PHP published its advisories on 21 October 2026. The supported-branch fixes are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The PHP security team urges users to update immediately. PHP security announcement

The difficult question is what that means for a particular deployment. Its command-line PHP version might differ from the web-serving runtime. A distribution might have backported the patch. A rebuilt image might not yet be running.

This guide follows those decisions through a PHP-FPM container example, with Valyu DeepResearch handling the investigation and the operator handling deployment and verification. A wider-security section covers Node.js, Railway, public Linux kernel reports, LiteLLM, Zeabur, eMudhra, GitLab, Java, Signal and WordPress latest security issues. Their remedies differ: some need a runtime or trust-store update; others need credential revocation or a clean rebuild.

TL;DR

• Both PHP2Shell CVEs score 9.2 out of 10 under CVSS v4.0. They concern PHP runtime vulnerabilities, not a Composer package that can be fixed by changing an application dependency.
• Update each supported branch to a release containing both fixes. For distribution or hosting packages, verify the vendor's backport notice and installed package revision.
• Include PHP-FPM in the inventory. The two advisories describe different exploitation conditions; FPM is not a reason to skip the update.
• Use DeepResearch to compare authoritative advisories, collect dated exploitation evidence and draft a remediation checklist. Review the decisive claims against their sources.
• Rebuild and replace affected workloads, then verify the deployed image and workers. Installing a patch does not establish that an earlier compromise never occurred.
• Keep the wider incident queue open: a provider's leaked credentials or a malicious package can require action even when no CVE or CVSS score is assigned in its incident notice.

The scope and update guidance come from PHP's announcement and the two official advisories: OOM corruption and stale global state.

If you're an agent: Set up Valyu and make your first search.

If you're a human: Create an account and get an API key.

MCP onboarding: Connect your agent to https://mcp.valyu.ai/mcp and follow the MCP setup guide for authentication.

Which PHP versions are affected by PHP2Shell?

For the supported branches listed by PHP, releases below the following branch-specific fixes require an update unless the responsible vendor documents an equivalent backport.

Source: PHP security announcement, 21 October 2026. These are the first fixed releases for these CVEs, not a promise that they remain the latest recommended releases when this page is read.

All installations serving web requests are at risk, including FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP 8.1 and older no longer receive regular upstream updates. PHP supplied exceptional minimal source backports for 7.4, 8.0 and 8.1; a backport branch is not a normal supported release or proof that an installed vendor package contains the fix. Check the vendor's evidence or move to a supported branch. PHP update guidance

Am I affected? Start with the runtime serving requests

Consider a maintainer responsible for an internet-facing application behind nginx. Its deployment record identifies an upstream PHP 8.4.26 FPM container, with no documented vendor backport. The maintainer needs a patch decision without trying an exploit against the service.

The illustrative inventory is small:

{
  "scenario": "illustrative, not an inspected deployment",
  "frontend": "nginx",
  "php_sapi": "fpm-fcgi",
  "php_version": "8.4.26",
  "build_provenance": "upstream",
  "vendor_backport_evidence": "not established",
  "internet_facing": true,
  "compromise_status": "unknown"
}

For that inventory, 8.4.26 falls below PHP's 8.4.27 fix. The next action is to prepare a patched image and rollout, not to wait for a working exploit demonstration against that exact application.

For a real service, first trace the frontend's FastCGI upstream to the actual pool or container. Record its image digest or package revision, runtime version, build source and replicas. Include scheduled jobs and long-running workers where they use the same runtime. Do not upload credentials, customer data or unredacted configuration to a research service.

Running php -v on a laptop or host only identifies that command's binary. It does not establish which runtime handles the website. Even inside a container, distinguish the CLI binary from FPM and confirm the workload that receives traffic.

Why PHP-FPM still needs attention

The mechanisms explain why deployment details belong in the research request.

CVE-2026-109618 concerns partially initialised request state after an allocation failure. PHP reports complete unauthenticated remote code execution against mod_php before application code runs. Its advisory supports FPM susceptibility through source analysis, but says no complete FPM exploit has been demonstrated for this CVE. Official OOM advisory

CVE-2026-109619 concerns request-owned state retained after its memory has been freed. PHP reports session-lifecycle RCE validated against both mod_php and FPM. The validated FPM path needs a suitable application operation after successful startup, followed by a later request reaching the same worker. Official stale-state advisory

The decision is to patch the runtime. The uncertainty is whether a particular attack path is reachable or was previously used, not whether every FPM deployment can be dismissed as unaffected.

Use DeepResearch to turn the CVEs and news into a patch decision

A security engineer has a different job: reconcile the advisories, hosting notices and rapidly changing news before deciding what belongs in the remediation ticket.

Valyu DeepResearch accepts a research question, seed URLs and research guidance, then returns a cited report. The API also supports structured output and source controls. Those capabilities help assemble the evidence; they do not certify the answer. DeepResearch configuration

What the actual research run found

The discovery run used fast mode and the following question, with PHP's changelog, Node.js's vulnerability index and CISA's KEV catalog as seed URLs:

As of 22 October 2026, identify new or updated PHP runtime/CGI and
Node.js runtime security advisories in past 30 days, plus older CVEs
with credible recent exploitation news. Separate npm/framework supply
chain. Verify CVE IDs, disclosure/update dates, affected/fixed versions,
deployment conditions and CISA KEV listing/date from primary sources;
flag missing evidence.

Review accepted the PHP CVE identities and fixed versions after checking PHP's advisories directly. It kept Node.js's separate runtime update out of the PHP patch decision.

Review also rejected a claim. The report said its inspected CISA catalog contained no PHP runtime entry. The feed actually contains CVE-2024-4577, a different, older Windows PHP-CGI vulnerability, added on 12 June 2024. That entry must not be conflated with PHP2Shell. CISA KEV JSON feed

That correction is part of the workflow. A completed report and a citation are starting points for checking a claim, not permission to copy it into a security ticket unchanged.

Run a narrower follow-up for the deployment

For the illustrative FPM inventory, ask a focused question. The following is a proposed follow-up request, not the original run, and was not submitted during preparation. It creates a billable task if executed.

With an authenticated Valyu CLI, run this from a private working directory. The receipt uses a new file; noclobber prevents overwriting an existing one. Keep credentials in the CLI's supported authentication configuration, not in the command or article files.

umask 077
set -o noclobber
 
valyu --json deepresearch create \
  "Investigate PHP2Shell as of 22 October 2026. For an illustrative internet-facing nginx application using upstream PHP 8.4.26 FPM with no verified backport, compare affected versions, fixes, deployment prerequisites and exploitation reports updated on 16-22 October. Propose remediation and verification steps; mark unknowns and do not claim live inspection." \
  --mode fast \
  --output-format markdown \
  --url https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w \
  --url https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp \
  --research-strategy "Prioritise PHP and vendor advisories. Read older baseline evidence where needed. Check exact CVEs in CISA KEV. Attribute dated exploitation observations, separate attempts from confirmed compromise, cite decisive claims and retain conflicts." \
  --report-format "Return an affected/fixed table, an inventory-specific decision, operator actions, verification criteria, unknowns and source URLs." \
  > php2shell-task.local.json

Save the returned deepresearch_id. Assign that exact value to DEEPRESEARCH_ID, then retrieve the same task:

valyu --json deepresearch status "$DEEPRESEARCH_ID"

Read the result only as a completed report when status is completed. A failed or cancelled task is not a completed investigation, and paused checkpoints need input. A status timeout is not a reason to submit a duplicate task. Task lifecycle

For later investigations, update the date and inventory. Avoid a blanket date filter that excludes an older vendor advisory needed to interpret this week's news. A bounded research run cannot promise every relevant report or continuous monitoring.

What should go into the remediation ticket?

The engineer reviews the report against primary sources and records:

This is a reviewed decision for stated inputs, not an automatically discovered inventory or a record of completed remediation.

How to rebuild and verify a PHP-FPM container

The operations engineer now needs to make the patch decision real. The example below isolates the runtime steps. It has no application files, nginx service, credentials or network access, and publishes no ports. It deliberately does not start the vulnerable before-state.

Test boundary: the registry manifest and Compose configuration were checked during preparation. Docker's local daemon was unavailable, so the image build, container startup and FPM commands below were not executed. No end-to-end application test is claimed.

Create examples/php2shell/Dockerfile:

FROM docker.io/library/php:8.4.27-fpm@sha256:e2d8e787dc775bdbd9d7e0c5e8f2f9ddb41ce5977c8bbaf99a2ba2e7d90fd8ae
 
RUN php-fpm -v && php-fpm -t
 
CMD ["php-fpm", "-F"]

The digest is the multi-platform registry index observed for this tag on 22 October 2026. It pins the selected content; changing only the version label later will not update the digest. Re-verify both when selecting a newer patched image. Registry metadata alone is not a runtime test or proof that every component in an image is secure.

Create examples/php2shell/compose.yaml:

services:
  php:
    build:
      context: .
    image: php2shell-example-php:8.4.27
    network_mode: none
    restart: "no"

From the directory containing examples, use a dedicated project name so the commands do not target an existing Compose deployment:

dc() {
  docker compose --project-name php2shell-example \
    --file examples/php2shell/compose.yaml "$@"
}
 
dc config --quiet
dc build --pull --no-cache php
dc up --detach --force-recreate --wait --wait-timeout 60 php
dc exec -T php php-fpm -v
dc exec -T php php-fpm -t
 
container_id="$(dc ps --quiet php)"
test -n "$container_id"
docker inspect --format '{{.Image}}' "$container_id"
docker image inspect --format '{{.Id}}' php2shell-example-php:8.4.27
docker top "$container_id"

build --pull --no-cache rebuilds the image. up --force-recreate replaces the example container. Building alone does not replace a running container. Docker build and Docker up document those separate operations.

The FPM version check should identify the chosen release. The -t command tests configuration syntax, not vulnerability resistance. The two image IDs should match, and the process listing should show FPM. The locally built image ID and upstream registry index digest are different identifiers; retain both in the appropriate build and deployment records.

For this service, --wait establishes that the container is running, not that an application can successfully serve requests. In production, use the approved rollout process, inspect every replica and pool, confirm traffic reaches the replacement workload, and run application tests, including uploads and sessions where applicable. Do not substitute a newly launched php-fpm -v process for evidence about workers that were already running.

Keep FastCGI private. PHP explicitly warns that FPM must not be reachable from an untrusted network. Do not add a public phpinfo() page to prove a patch was deployed.

Remove the isolated example containers when finished:

dc down

The intended outcome is an evidence-backed rollout: the approved patched image is running, old workers are replaced, and application checks pass. Those are acceptance criteria to establish in the actual environment, not results observed in this example.

Is PHP2Shell being exploited, and what if patching must wait?

The fetched CISA catalog identifies itself as version 2026.10.21, released at 2026-10-21T14:04:39.8983Z. Neither new PHP CVE appears in that snapshot. Absence from KEV is not evidence of absence of exploitation, and that snapshot does not establish what CISA may add later. CISA feed

If an update cannot happen immediately, follow the vendor's temporary measures for the relevant path and document their limits. Disabling session upload progress, for example, blocks demonstrated session paths for CVE-2026-109619 but not every state-lifecycle path. PHP says updating is the complete solution. Avoid copying an isolated memory-setting change into production without reviewing its availability consequences and the full advisory. PHP mitigation guidance

Where compromise is suspected, follow the incident-response process, preserve evidence and assess secrets reachable by the web worker. Patching closes the known vulnerability; it does not remove an existing foothold or determine what happened earlier. PHP2Shell response checklist

What other security issues should teams check this week?

PHP2Shell is the main worked example, but a useful investigation also checks adjacent runtimes, hosts and delivery systems. The following developments were disclosed or reported during 19 to 22 October 2026. They are separate incidents, not additional PHP2Shell CVEs. Use a separate DeepResearch question and the relevant vendor sources for each; do not apply PHP's fix table or severity score to them.

Node.js Brotli decoder RCE: CVE-2026-111497

Node.js's 21 October security release fixes CVE-2026-111497, a high-severity out-of-bounds write in its bundled Brotli decoder, across maintained 22.x, 24.x and 26.x lines. The fixed releases are 22.23.4, 24.22.1 and 26.12.1. Vercel explains that exposure depends on an application or library decoding attacker-controlled Brotli data, whether from an inbound request or a fetched response. Its inbound WAF rules do not cover fetched responses or replace the runtime patch.

For a team running a Node.js service alongside PHP, the decision is to inventory its actual Node runtime separately, update the relevant image or managed runtime and verify the redeployment.

Have DeepResearch compare the Node and hosting advisories, but retain the operator's runtime evidence as the closure criterion. Demonstrated code execution is not by itself proof of exploitation in the wild. Node.js advisory · Vercel exposure and update guidance

GitLab: CVE-2026-110264 has a maximum CVSS 3.1 score of 10.0

GitLab's 21 October critical patch release addresses CVE-2026-110264, an integer-overflow issue in its Regular Expression Compiler that could allow an unauthenticated user to execute code on the server under the described conditions. GitLab assigns it a CVSS 3.1 base score of 10.0 out of 10. This is the maximum-severity GitLab issue, separate from PHP2Shell's 9.2 under CVSS v4.0. GitLab lists fixes in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, and says GitLab.com is patched.

For a self-managed operator, have DeepResearch match the installed CE/EE branch to the current advisory and supported upgrade path, then plan the upgrade and check the completed migrations and deployed version. Updating a GitLab Runner alone does not update the GitLab server.

Do not confuse this CVE with the earlier CVE-2026-97229: a previous October patch level is not automatically sufficient for the new issue. The severity score and published detection guidance do not establish that an instance has already been exploited. GitLab's official advisory and branch ranges

Railway: possible access to customer secrets

On 21 October, Railway disclosed that an unauthorised third party may have accessed encrypted environment variables and obtained some decrypted contents. Its initial analysis suggested a subset of users, but Railway recommended precautionary action for all users: rotate stored secrets, including API keys and private-registry credentials, and review service logs. This is a credential-exposure response, not a PHP or Node CVE fixed by rebuilding a runtime. A Railway customer should identify the issuing services behind those variables, revoke or rotate the credentials there, update the deployments and check for misuse. DeepResearch can turn Railway's disclosure and provider-specific follow-ups into that service-by-service checklist. Closure needs evidence that the old credentials are invalid and replacement workloads work; editing a variable alone does not establish revocation. Railway's 22 October GCP follow-up also calls for a cloud audit review where a service-account key may have been exposed. Railway disclosure · GCP follow-up

Linux kernel reports posted publicly: reported CVSS scores up to 9.0

On 22 October, Phoronix reported that several ZDI Linux kernel vulnerability reports appeared on public mailing lists in what it described as an apparently accidental disclosure. The archived reports independently confirm ZDI-CAN-33549, an SMB Direct integer-underflow RCE report, and ZDI-CAN-33774, a KSMBD protocol-dispatch race-condition RCE report, each with a reported CVSS score of 9.0 out of 10. These are ZDI candidate identifiers, not CVE numbers; the reports list a tested kernel, not a complete affected-version matrix. A maintainer's public reply to a separate vmwgfx report explicitly questions the public submission without a patch.

For a Linux fleet owner, the next action is to identify relevant subsystems and exposure, restrict unnecessary reachable services and obtain the distribution or kernel maintainer's applicable fix status. Ask DeepResearch to track each report separately. A patch under review or in a development branch is not proof that the installed distribution kernel is fixed. Phoronix coverage · SMB Direct report · KSMBD report · Maintainer reply

LiteLLM 1.107.0: a compromised release, not an ordinary dependency update

LiteLLM's 21 October incident report identifies malicious litellm==1.107.0 PyPI artifacts and compromised container artifacts, including mutable tags during the documented publication window. The vendor says they contained credential-stealing malware and remote-code-loading functionality, and distinguishes the published artifacts from the official source tag, which did not contain the malicious files. For a team operating a model gateway, the question is which artifact actually ran and what secrets that environment could reach.

Use DeepResearch to compare the vendor's affected-artifact list and timeline with sanitised deployment records. If exposure is established, isolate the environment, follow the vendor's clean-rebuild guidance and rotate reachable credentials. Do not start with a routine pip upgrade inside the affected environment: LiteLLM warns that starting Python, including pip, can execute the malicious startup files again. A clean rebuild and credential response are different closure requirements from simply changing a version pin. LiteLLM incident and response guidance

Zeabur: a current-week disclosure of earlier platform compromise

Zeabur's preliminary report, published 19 October, describes intrusion activity on 14 and 15 October, including access to shared infrastructure, GCP Dedicated Servers and a platform database containing environment variables. It is a new disclosure this week, not evidence that the intrusion began this week. The vendor separates confirmed observations from assessments and unconfirmed hypotheses, and asks customers to replace exposed credentials even if they rotated them after its earlier August incident. For an affected operator, DeepResearch can map the report's response steps to the services and hosts actually used. The next actions can include issuer-side key revocation, database-side password changes and rebuilding compromised servers.

Changing a platform environment variable does not change the password stored inside the database. Retain the report's scope qualifications: projects that had moved their variables off the platform database avoided that particular read, but a compromised host is a separate exposure path. Zeabur preliminary incident report

eMudhra TLS certificates: browser protection does not update every client's trust store

The eMudhra intermediate CA compromise is a certificate-authentication issue, not evidence that TLS encryption itself has been broken. Mozilla's 20 October account says it received a report on 17 October that the private keys of eight eMudhra intermediate certificates were compromised. Such keys could support fraudulent HTTPS certificates and website impersonation for an attacker able to intercept a connection. Mozilla blocked the affected certificates through OneCRL on 17 October, then shipped browser and NSS updates to reach clients that did not receive that protection; its post records a further Android fix on 21 October.

eMudhra says the intermediate keys were generated incorrectly, revoked on 18 October, and that its root CA private keys were not compromised. It also says it has no evidence the weak keys were recovered or exploited before disclosure. Keep those vendor statements attributed rather than turning potential interception into a claim of observed attacks. Mozilla's response · eMudhra's statement

For a team running API clients, CI jobs or containers, a protected browser is not the closure test. The researcher-maintained incident site explains that clients which do not consume revocation information can still need software or trust-store updates.

Ask DeepResearch to identify the actual CA bundle used by each client, including separately bundled runtime stores, and compare the relevant vendor releases. Update those packages or runtimes, rebuild and redeploy affected images, and verify certificate rejection through that same application stack while normal trusted connections still succeed. Do not disable certificate verification to work around failures. If the team's own service certificate chains to a distrusted hierarchy, follow the issuer's replacement guidance too. The researcher's site says exploitation against non-browser clients remains unknown; no interception test or trust-store modification was performed for this article. Incident response and downstream update tracker

Java: CVE-2026-91403 makes the eMudhra response runtime-specific

The Java issue is CVE-2026-91403, which OpenJDK's 21 October advisory explicitly links to the eight compromised eMudhra intermediate certificates. Its security-libs/javax.net.ssl risk matrix gives a CVSS v3.1 score of 9.1. This is a Java remediation path for the same underlying certificate incident, not evidence of a separate encryption break. A JVM fleet owner needs to establish which Java installation and certificate store each service actually uses.

OpenJDK recommends updating standalone runtimes, and explains that many Linux-distribution builds use the operating system's certificates instead; FreeBSD and Homebrew builds are exceptions in its guidance. Ask DeepResearch to compare the exact JDK vendor, build and packaging with that advice before choosing a runtime update or OS trust-store update. Replace or restart affected workloads as appropriate, then verify the effective certificate policy and normal TLS operation.

Do not treat a host-level CA update as proof that an application's separate bundled JDK was fixed. OpenJDK advisory, risk matrix and packaging-specific guidance

Signal: CVE-2026-113380 can interfere with ending a call

Signal's calling-library issue is CVE-2026-113380, published in the CVE record on 20 October and scored 9.3 under CVSS v4.0. The record says RingRTC versions before 2.72.0 are affected: a malicious call peer can interfere with local hang-up teardown, potentially leaving audio, and perhaps video, active. The record's uncertainty about video matters; it does not establish that every affected call leaves the camera on. This is a call-lifecycle problem, not a claim that Signal's encryption was cracked or that an unrelated observer can decrypt conversations.

Signal users should update official clients, while developers embedding RingRTC need to verify the library dependency and containing application build. DeepResearch can connect the CVE to the upstream fix and platform release notes, but must not present 2.72.0 as a Signal app version. An authorised application test should establish that media stops when a call ends; no such call or interception test was performed here. CVE record and score · Upstream call-termination fix

WordPress: stolen UpdraftCentral keys used to install backdoors

The WordPress story is the TeamUpdraft/UpdraftCentral service-key compromise, not a newly identified WordPress core flaw. TeamUpdraft's 19 October disclosure, updated through 22 October, says an intruder accessed its website over 17 and 18 October and that it believes the customer database, including connection keys, was accessed. Patchstack reports attackers using valid keys to install backdoors on connected WordPress sites. The vendor's later updates identify UpdraftPlus 1.26.13 and 2.26.13 as releases that revoke the old UpdraftCentral connection keys; use those dated updates rather than an older article's "no fix yet" status.

For a site operator, DeepResearch should distinguish cloud UpdraftCentral from self-hosted installations, which the vendor says were not affected, and collect the current response checklist. Verify the installed update and revoked connections, review unexpected plugins and users with elevated capabilities, and rotate relevant credentials. Key revocation does not remove a backdoor already installed. The vendor says the UpdraftPlus plugin files and downloads themselves were unaffected; do not describe this as a poisoned plugin release or assign it a fabricated core CVE. TeamUpdraft's disclosure and updates · Patchstack's observed campaign

For the research agent, the shared job is to produce a dated decision record: what happened, which asset or credential is relevant, the next action, and the evidence needed to close it. Do not force a CVE or CVSS score onto a breach or supply-chain incident whose notice does not assign one.

Frequently asked questions

Does PHP2Shell affect PHP-FPM?

PHP includes FPM in its affected deployment guidance. The evidence differs by CVE: the OOM advisory describes source-analysis susceptibility without a complete demonstrated FPM exploit, while the stale-state advisory reports a validated FPM session-lifecycle path with application prerequisites. Update rather than treating FPM as exempt. PHP announcement

Is a lower version number always proof that the patch is missing?

No. A distribution or LTS vendor can backport fixes while retaining an older upstream version number. Verify the complete installed package revision against the vendor's security notice and establish that the patched build is running. An upstream-only version comparison cannot make that decision. PHP vendor guidance

Can Valyu find and fix vulnerabilities automatically?

DeepResearch can investigate published vulnerabilities, compare evidence and propose actions for a supplied inventory. It is not proof of private-code scanning, live exposure testing, patch installation or deployment verification. Those jobs need the appropriate tools, access and responsible operator. DeepResearch capabilities

Is this the same issue as CVE-2024-4577?

No. CVE-2024-4577 is the older Windows PHP-CGI command-injection vulnerability listed by CISA in June 2024. PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619. Keep their affected configurations, fixes and exploitation evidence separate. CISA record

Give the research result a deployment owner

For the illustrative upstream 8.4.26 FPM deployment, the decision is to adopt a build containing both fixes, replace the affected workload and verify the result. Backport evidence, actual rollout completion and prior compromise remain separate questions until checked.

Give a security research agent the advisory URLs and a sanitised inventory. Have it return source-backed decisions and unknowns. Then hand the reviewed plan to the operator who can establish what is really running. The DeepResearch introduction and configuration guide cover the research side of that workflow.

Evidence and revision history

This is a dated investigation of PHP2Shell with selected wider-security developments, not an exhaustive record of every vulnerability or security incident that week.