loading
loading
On October 21, 2026 the PHP and Node.js projects released security updates addressing vulnerabilities that can allow remote code execution. Teams running either runtime should identify affected services and apply the appropriate patches immediately. Applying those takes more than changing a version number. PHP and Node.js can appear in container images, OS packages, CI pipelines, and infrastructure configurations across many repositories. Each affected deployment needs to be identified, updated, tested, and deployed. Applications running unsupported versions may also need to go through compatibility changes. To support teams, we packaged the remediation workflow we used ourselves into an open-source plugin for Devin and any coding agent. With the Vulnerability Fixes plugin, your agent identifies affected repositories, asks before changing anything, patches each deployment to a verified fixed version, tests your application before and after the change, and opens one focused PR per repo. The bugs PHP2Shell (CVE-2026-109618, CVE-2026-109619) PHP2Shell is a pair of critical (CVSS v4 9.2) unauthenticated remote code execution flaws in the PHP runtime: - CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): memory corruption after an out-of-memory condition. - CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): stale global state from one request reused by the next. Who is affected: PHP’s advisories say every web-serving PHP setup is at risk, including PHP-FPM, Apache mod_php (rated highest risk), php-cgi, FrankenPHP and LiteSpeed. Fixed versions: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older don’t get new releases; PHP published source-level backports for 7.4, 8.0 and 8.1. Upgrading is the only complete fix. Things to watch for: - Distro packages keep their old version numbers. Debian and Ubuntu backport the fix without changing the upstream version. For example, Ubuntu 24.04’s fixed package is 8.3.6-0ubuntu0.24.04.13 and Ubuntu 22.04’s is 8.1.2-1ubuntu2.28, so php -v still says 8.3.6 or 8.1.2. Check your vendor’s security advisory or package changelog, not php -v. - Images pinned by digest need a new digest, not just a tag change. Floating tags like php:8.3-fpm need a rebuild that pulls the new base image. - Source builds need the new tarball and its checksum from php.net. - Changing Composer’s require.php or config.platform.php doesn’t patch anything. Those settings don’t choose the PHP that runs in production. If you can’t upgrade immediately, PHP lists temporary mitigations that reduce exposure but don’t fix the bug, for example setting session.upload_progress.enabled=0 in php.ini or the FPM pool and restarting every worker, and limiting request body size and multipart part counts at your proxy. Don’t use RLIMIT_AS or RLIMIT_DATA as a mitigation: they trigger the vulnerable code path. See the advisories for the full list. Node.js October 21, 2026 security release (including CVE-2026-111497) The Node.js October 2026 security release fixes 10 CVEs. Four are rated High: - CVE-2026-111497: an out-of-bounds write in the Brotli decoder that can lead to remote code execution. Prioritize internet-facing services that decompress Brotli, including HTTP clients, servers and proxies. - CVE-2026-105482, CVE-2026-105483 and CVE-2026-106069: TLS and DNS hostname issues. Prioritize services that connect to user-supplied hosts. Fixed versions: 22.23.4, 24.22.1 and 26.12.1. Node.js 20 and older are end-of-life and will not be fixed, but remain exploitable. They need a major-version upgrade to 22 or later. The release also updates bundled OpenSSL, c-ares, Undici, SQLite and the CA store, which no longer includes the eMudhra root. Services that make outbound TLS connections should be tested after upgrading. How to fix with Devin These bugs are being actively exploited via automated means, so your first step should be to take down your PHP web applications immediately while you address the issue. Then, you will need to test the impact of the patches on your code. A patch release within the same line (i.e. 8.3.30 → 8.3.36, or 24.21.0 → 24.22.1) is usually low risk, but should still be tested. However, many sites are running on versions of PHP and Node that are end-of-lifed and not patched, so upgrading to a new major release is likely to cause problems with any complicated application. We have released a plugin in the Devin Marketplace to handle this process for you for both PHP and Node. How Devin will address these issues - Inventory, read-only. Devin searches every repository it can access for PHP or Node: Dockerfiles and base images, distro packages, source builds, CI (setup-php, setup-node, .nvmrc, .tool-versions), Helm values, Terraform, Packer, AWS Lambda runtimes, and Ansible, Chef or Puppet. It reports what it found, what’s affected and what’s already fixed. - Ask for approval. You choose which repositories to patch. Devin calls out anything riskier than a patch bump, such as a minor or major upgrade, a base-OS change or a likely application-code change, before it starts. - Patch to a verified target. Devin confirms every tag, digest, package version and checksum against the official registry, vendor advisory or php.net before updating the local build specifications. - Test before and after. Devin runs your test suite on the current version to get a baseline, then runs it again inside the new production image. It compares the two runtimes (extensions, ini settings, OpenSSL and ICU versions, base OS), starts the container and checks real responses. On major or minor upgrades it adds compatibility checks. If anything regresses, it stops and proposes the smallest fix. - Open pull requests. Devin will complete the process by opening one pull request per repository with before/after versions, test results, runtime differences, a risk label, and a rollout and rollback plan. How to use it 1. Install the plugin In Devin: - In the left-hand sidebar, navigate to the Customize sub-menu. - In the Plugins tab, click on Browse Marketplace. - In the search bar, type in Vulnerability Fixes. - Click Install and install the plugin to the relevant scope. In the Devin CLI: run the following from your terminal. devin plugins install CognitionAI/devin-marketplace#plugins/devin-vuln-fixes Organization or Enterprise admins can install the plugins for many users, although it’s unlikely that you would want dozens of engineers cutting PRs for these bugs at the same time. 2. Ask Devin to fix it Start a session to invoke one of the remediation prompts: You can also ask in plain language (“Please fix my PHP vulnerability”) and Devin picks the matching skill, or run a skill directly with /vuln-fixes:fix-php-vuln, /vuln-fixes:fix-node-vuln or /vuln-fixes:fix-gitlab-vuln. To narrow the scope, name the repositories: “Please fix my PHP vulnerability in acme/billing-api and acme/storefront.” 3. Review the inventory and approve Devin replies with a table of every PHP or Node deployment it found and whether each one is affected. Tell it which repositories to patch and whether major upgrades (for example Node 20 → 22) are in scope. 4. Review, merge and deploy Review each pull request’s test results and risk label. Roll high-risk changes out to staging or a canary first. The fix only takes effect once the new build is deployed, so redeploy every patched service, and rebuild anything that uses a floating image tag. Things to watch out for - Devin can only validate what your tests cover. For lightly tested applications, the pull request says so and recommends staging or a canary. You can also ask Devin to write additional tests; this might be the right time to do that! - Managed runtimes are patched by their provider. Devin reports these cases with the check to run, rather than claiming they’re fixed. - Vendor appliances and Electron apps bundle their own PHP or Node. Devin flags them for vendor updates instead of patching them in place. How to fix with other products We are also releasing a plugin for other coding tools to help you address the issue. The plugin is built from standard Agent Skills and is compatible with npx skills, meaning it can be easily installed and utilized in other products such as Claude Code, Codex, Cursor, Factory Droid, GitHub Copilot, Gemini CLI, and OpenCode. Install the skills npx skills Works with any agent. The CLI detects the agents on your machine and asks where to install. npx skills add CognitionAI/devin-vuln-fixes Add -g to install for every project, -a <agent> to choose agents (for example -a claude-code -a codex -a cursor), or --skill fix-php-vuln to install a single skill. Requires Node.js 22.20 or later. To pick up new fixed versions as vendors ship them, run npx skills update. Run them Ask in plain language, as you would ask Devin: “Please fix my PHP vulnerability.” The agent picks the matching skill from its description. In agents that support slash commands you can also run a skill directly: /fix-php-vuln /fix-node-vuln /fix-gitlab-vuln If you installed the Claude Code plugin, the commands are namespaced, for example /vuln-fixes:fix-php-vuln. The skills follow the same steps described above: a read-only inventory, an approval gate, patches to verified versions, tests before and after, and one pull request per repository. They don’t depend on any one agent’s tools. If your agent supports subagents, the skills use one per repository; otherwise they work through repositories one at a time. The agent needs git, a shell and read access to your repositories. The build and test steps also need Docker and access to the image registry or package mirror your CI already uses. If public hosts are blocked, the skills mark the target version as unverified in the pull request and let CI confirm it. Review any skill before you run it. Many of these products run locally, lack the isolation we can provide in Devin, and skills run with your agent’s full permissions. Looking Ahead These will not be the last critical, easily exploited flaws released in foundational technologies; it’s likely we have reached a new normal due to the pace of vulnerability discovery and the ability for attackers to use AI to automate their killchains. Going forward, we recommend: - Understanding and reducing your attack surface. Too many companies have no idea what code they are exposing to the internet. You need to be continuously scanning your external attack surface and decommissioning unneeded applications and moving internal apps behind VPN/ZTNA. - Refactoring your code to run on the latest runtimes and to be containerized, to eliminate the challenges of patching traditional servers. Teams that were already on the latest trains of PHP and Node are having a much easier week than those jumping ahead one or two generations. Thirty-day patch cycles for production servers are not going to be sufficient in this environment, and if you want to maintain reliability while reacting quickly to security news that means moving to the cloud or running containerized applications on a rapidly updated hosting substrate. - Consider building the functionality you need yourself instead of using standard libraries. Between the backdooring of standard packages and the tens of thousands of vulnerabilities found in them over the last year, it could be wise to utilize the power of coding agents to build hyper-targeted capabilities instead of importing millions of lines of code that introduce a massive attack surface with standard, well-understood flaws. You can join our CSO, Alex Stamos, on a webinar on Monday, October 26 at 10:30 AM PT to discuss these and more longer-term solutions.
document fetched 2026-10-24 11:26