What php2shell is and why it matters
If you run PHP, upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now. The hard part is finding every place PHP actually runs.
php2shell is a pair of critical flaws in the PHP interpreter, tracked as CVE-2026-109618 and CVE-2026-109619. Both are use-after-free bugs that can let an unauthenticated attacker run code remotely. They are rated 9.2 on CVSS v4.0, and watchTowr scores them 10.0 (Tenable, watchTowr).
PHP 5.4 and later are affected (Sansec). Cloudflare has reported early exploitation attempts, and the Dutch NCSC says public proof-of-concept exploits exist (Brandefense). PHP sits behind a large share of the web, so the exposure is broad.
The catch: PHP isn’t in your dependency list
php2shell lives in the PHP runtime, not in a Composer package. Your composer.json and composer.lock list the libraries your app uses. They don’t list the interpreter that runs it.
So a scan that only reads source code and manifests can report a clean bill of health while every server runs a vulnerable PHP build. PHP usually arrives some other way: an official php: container base image, an OS package such as php8.3-fpm, or a binary baked into an appliance or vendor product. To see php2shell, you have to look where PHP actually ships.
How Black Duck SCA helps you respond
Black Duck SCA finds PHP wherever you scan for it and tells you which of your applications are exposed. If your images are already in Black Duck SCA, the answer is a search, not a scan..
- Scan containers and binaries, not just code. Black Duck Secure Container scanning analyzes each layer of a container image using binary analysis. It identifies OS packages such as php8.3-fpm and components added outside the package manager, then shows which layer introduced them. Black Duck Binary Analysis applies the same analysis to firmware, appliances and other compiled deliverables.
- Answer “where are we exposed?” across your portfolio. Once PHP appears in your bills of materials, search Black Duck SCA for the php2shell BDSA or CVE ID. The results list every project version containing an affected PHP component, whether it came from upstream PHP or a Linux distribution package. Because the KnowledgeBase updates existing BOMs, you don’t need to rescan to get this answer. The Black Duck SCA MCP can support this wherever you use AI-enabled workflows.
- Get vetted guidance fast. Black Duck Security Advisories BDSA-2026-37953 and BDSA-2026-37954 cover php2shell, with researched details, fixed versions, and workaround notes. BDSAs often arrive ahead of, or alongside, the NVD entry.
- Stop new exposure at the gate. A policy that flags or fails builds containing affected PHP versions keeps vulnerable images from reaching production while you remediate. Create a policy rule covering affected PHP versions and run Detect with — detect.policy.check.fail.on.severities. Builds with violations exit with a policy-failure code and stop the pipeline
- Prove the fix. Rescans confirm each project has moved to a fixed release, and remediation status gives security and engineering one shared view of progress.
Know the gaps
SCA is one part of a php2shell response. Plan for these four limits.
- Systems you don’t scan. VMs, bare-metal servers and managed hosting outside your pipelines won’t show up in an SCA BOM. Pair SCA with infrastructure vulnerability scanning to cover them.
- Distro backports. Debian, Ubuntu and RHEL often patch a flaw without changing the upstream version number. Black Duck matches Linux packages to their distribution origin, so vulnerability results account for many distro backports. Where a distribution declares a package not affected without shipping a patch, confirm against the vendor’s notice and record that decision as a remediation status.
- End-of-life PHP. PHP 5.x through 8.1 has no official fixed release, only source backports for 7.4, 8.0 and 8.1 (Pentestit). SCA will flag these versions, but fixing them is a backport or an upgrade project.
- Reachability and workarounds. SCA shows that a vulnerable version is present. It can’t tell you whether the app faces the internet or whether a configuration workaround is in place, and PHP treats those workarounds as partial.
A seven-step response playbook
- Check what you already have. Search for associated BDSAs or CVEs and view affected projects for an at-a-glance view of the potential scope.
- Scan where PHP ships. Run container and binary scans on your production images and artifacts, not just source repositories.
- Search your BOMs. Find every project with a PHP runtime component and note the version and where it came from.
- Triage by exposure. Fix internet-facing apps first, then internal ones. Confirm distro-backported packages against vendor notices.
- Set a policy. Flag or block affected PHP versions in CI so new builds don’t add to the backlog.
- Upgrade and rebuild. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and rebuild images from patched base images. Plan backports or migrations for end-of-life versions.
- Rescan and confirm. Close each finding only when a fresh scan shows the fixed version.
Find it before attackers do
php2shell is a reminder that your attack surface includes the runtime under your code, not just the libraries in it. Teams that already scan containers and binaries can answer “are we exposed?” in an afternoon.
If you’re not sure your scans cover the PHP runtime, now is the time to check. If you license Black Duck SCA Professional run –detect.tools=CONTAINER_SCAN against your production PHP images today, and if you use BDBA standalone, upload your production PHP images to perform the same analysis. Otherwise, contact us about extending SCA coverage to your containers and binaries.
