PHP and Node.js published important security updates on October 21, 2026. We have deployed fixes to the identified affected running Openstead application and platform containers, and strengthened runtime checks in managed builds.
If you deploy PHP or Node.js, check the version in your live service. A custom Dockerfile, prebuilt image or older rollback target can still contain a vulnerable runtime even after platform defaults change.
What Openstead has updated
Openstead's managed PHP tooling, phpMyAdmin image and Laravel starter now use patched runtime images. Managed PHP and Node.js builds check the resolved build runtime and the final application runtime before publication, and reject unsupported or vulnerable versions.
We verified the patched running versions and service readiness for the application and platform containers included in this rollout. We also updated Flysystem in our affected applications and corrected a rule that could allow uploaded files to execute.
These changes do not rewrite your repository, Composer lockfile, custom Dockerfile or prebuilt image. Those sources still need your own maintained runtime and dependency updates.
PHP: PHP2Shell
The PHP advisories CVE-2026-109618 and CVE-2026-109619, commonly referred to as PHP2Shell, describe memory corruption and stale request-state vulnerabilities that can allow remote code execution in affected deployments. PHP classifies both advisories as critical. Exposure depends on the server, configuration and application path; switching server software or adjusting configuration is not a substitute for applying the complete patches.
Use at least the patched release for your supported PHP series:
| PHP series | Minimum patched version |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
A later patch in the same supported series is also appropriate. If your application uses PHP 8.1 or older, plan an upgrade to a supported series and test compatibility.
Read the official PHP reports for CVE-2026-109618 and CVE-2026-109619.
Node.js: CVE-2026-111497
A crafted Brotli-compressed stream can trigger an out-of-bounds write in the decoder used by affected Node.js releases. Potential consequences include code execution, memory disclosure and denial of service. The Node.js project classifies this issue as high severity.
Use at least the patched release for your supported Node.js series:
| Node.js series | Minimum patched version |
|---|---|
| 22 | 22.23.4 |
| 24 | 24.22.1 |
| 26 | 26.12.1 |
These releases also include other security fixes. If you are running Node.js 20 or older, move to a supported release and test your application.
See the official October 2026 Node.js security release notice.
What to do next
- Update the runtime source. For a managed build, remove an old patch-version pin or select a supported patched version. For a custom Dockerfile or prebuilt image, update the base image and any pinned digest. Preserve the image variant your application needs, such as Alpine, Debian, Apache or FPM.
- Build and deploy a new release. Pull the patched base image and rebuild affected services. Clear the build cache if it could retain the old runtime. An existing deployment does not automatically inherit new build defaults. Older copies of a Laravel starter should use the patched starter source before rebuilding.
- Verify the running service. Open the live service shell and run the relevant command below. Confirm the actual runtime meets the patched floor; checking only a Docker tag or build setting is not enough.
- Review rollback targets. Reverting to an older image can restore a vulnerable runtime. Verify the target before rolling back, and replace outdated images in your normal release workflow.
For PHP:
php -v
For Node.js:
node -v
If your services use neither PHP nor Node.js, no runtime action is needed for these specific advisories. Continue maintaining your application's own dependencies and base images.
Verification and support
Our checks establish that the scoped runtime fixes were deployed and that the tested services passed readiness checks. They do not certify that an application is vulnerability-free or establish whether it was previously compromised.
We've sent registered clients a security notice with these steps. You can review your services, read the runtime documentation, or contact the Openstead team if you need help checking a deployment.