Beyond PHP2Shell: Finding Vulnerable PHP Across Your Firmware Portfolio

Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were recently disclosed by the PHP project. Collectively dubbed PHP2Shell, these vulnerabilities can allow unauthenticated remote code execution under certain conditions.

While major cloud and hosting providers had the opportunity to prepare for the disclosure, and the broader PHP ecosystem was urged to patch immediately, embedded devices face a different challenge. Devices running vulnerable PHP versions often remain exposed until their manufacturers release updated firmware and those updates are deployed.

Given the long lifecycles of embedded devices and the prevalence of outdated software components, the impact of PHP2Shell could persist well beyond the initial disclosure.

In this post, we'll walk through the steps to identify and remediate PHP2Shell vulnerabilities in embedded firmware, and show how the ONEKEY platform can help you throughout the process.

Remediation

We recommend taking the following steps to address PHP2Shell in embedded environments:

1. Identify affected firmware — Search your firmware inventory for vulnerable PHP runtimes, including statically bundled or custom-built versions.
2. Update PHP — Integrate a fixed PHP version into your firmware and distribute a signed firmware update.
3. Restrict network exposure — Disable unnecessary PHP-based management interfaces or restrict access to trusted management networks.
4. Apply temporary mitigations — Harden PHP configuration and HTTP request processing when an immediate firmware update is not possible.
5. Address end-of-life versions — Apply validated backported patches or migrate to a supported PHP branch.
6. Verify remediation — Reanalyze updated firmware to confirm that vulnerable components have been updated or patched.

Let's look at how ONEKEY can support each stage of this process.

Identifying Affected Firmware

The first step is to understand where PHP is present across your firmware portfolio.

The ONEKEY platform lets you search your entire firmware collection for specific software components, making it easy to identify which products and firmware versions contain PHP.

To get started, navigate to “Search In” → “Components” and search for PHP.

Navigate to “Search In” → “CVEs” and search for either CVE-2026-109618 or CVE-2026-109619.

This helps you quickly narrow down which firmware images require further investigation and prioritize remediation efforts.

Keep in mind that identifying a vulnerable PHP version does not necessarily mean the device is exploitable. Actual exposure depends on factors such as how PHP is used, whether it processes web requests, and whether the affected service is reachable.

Fixed Versions

If your firmware includes a PHP branch for which a security update is available, the recommended remediation is to upgrade to a fixed release.

The security updates released on October 21, 2026, introduced the following minimum fixed upstream versions:

For embedded devices, this typically means integrating the patched PHP runtime into a new firmware image, validating compatibility, and deploying the update to affected products.

However, upgrading is not always straightforward, particularly when devices rely on older PHP versions that are no longer supported upstream.

End-of-Life Versions

Many embedded devices continue to use PHP versions that have reached end of life, including PHP 8.1 and earlier. These versions no longer receive regular upstream security updates.

If upgrading to a supported PHP release is not feasible, you may need to backport the relevant security fixes or request a patched firmware release from your OEM.

This introduces another challenge: How can you verify that a vulnerable PHP version has actually been patched?

Simply checking the version number is not enough. A vendor may backport a security fix without changing the reported PHP version, potentially causing version-based vulnerability scanners to continue reporting the CVEs.

This is where ONEKEY's Automated Impact Assessment can help. With release 2026.10.26, we introduced automated impact assessment rules designed to identify the presence of PHP's official security patch in compiled binaries.

‍

By detecting evidence of the patch directly in firmware binaries, ONEKEY can distinguish patched implementations from potentially vulnerable ones, even when the reported PHP version has not changed.

This helps reduce false positives and gives security teams greater confidence when assessing the effectiveness of vendor backports. All our automated impact assessment comes with VEX information (here set toFIX_APPLIED), that is also exported when you perform an SBOM export.

Temporary Mitigations

When a firmware update or backported patch cannot be deployed immediately, temporary mitigations can help reduce the risk of exploitation.

The PHP security advisories recommend several configuration changes:

• CVE-2026-109618 — Set memory_limit=-1, restrict HTTP request and file-upload sizes, and avoid relying on RLIMIT_AS or RLIMIT_DATA as alternative memory controls.
• CVE-2026-109619 — Set session.upload_progress.enabled=0 and, on PHP 8.5, set fatal_error_backtraces=0.

For more details, refer to the PHP2Shell advisory and the official PHP security guidance.

Important: These mitigations do not fully resolve the vulnerabilities and should not be considered substitutes for patching. In memory-constrained embedded environments, changes such as disabling PHP's memory limit must also be carefully evaluated to avoid introducing stability or availability issues.

If you decide to apply configuration-based mitigations, the ONEKEY Query Language (OQL) can help you inspect firmware files and identify relevant PHP configuration settings.

You can perform these searches within an individual firmware image or across your entire firmware collection to identify configurations that may still require attention.

This provides an additional way to investigate mitigation coverage while waiting for a permanent firmware fix.

Verifying Remediations

Once you have updated PHP or applied a backported patch, the final step is to verify that the remediation is reflected in your firmware.

With ONEKEY, you can analyze the updated firmware image and compare it with the previous release to identify changes in software components and vulnerability findings.

For example, comparing the latest firmware version with its predecessor lets you check whether:

• The PHP runtime has been upgraded to a fixed version.
• A previously reported PHP2Shell vulnerability is no longer detected.
• A vendor backport has been recognized through Automated Impact Assessment.
• Other software components or vulnerability findings have changed as part of the update.

In the example below, firmware version 1.0 backported the patch to its PHP version 7.4.

We see that both PHP2Shell CVEs have been removed, thanks to Automated Impact Assessment:

In this second example, the PHP version running on the firmware was updated and CVEs were therefore removed:

This comparison helps you validate the remediation work and maintain a clear record of how your firmware security posture evolves between releases.

Key Takeaways

PHP2Shell highlights a recurring challenge in embedded security: critical vulnerabilities can remain present in firmware long after fixes become available upstream.

Addressing this challenge requires visibility into the software running on your devices, the ability to identify affected products, and reliable ways to verify that patches have actually been applied.

The ONEKEY platform helps you:

• Identify exposure across your firmware portfolio by searching for software components, CVEs, and relevant files.
• Assess firmware without source code Whether you're a device manufacturer or a critical infrastructure or industrial operator, ONEKEY enables vulnerability analysis directly from firmware binaries, without requiring access to proprietary source code.
• Reduce false positives by recognizing patched binaries, including vendor-backported security fixes, through Automated Impact Assessment.
• Investigate temporary mitigations by searching firmware configurations with OQL.
• Verify remediation efforts by comparing firmware versions and tracking changes in vulnerability findings.

And remember: the more complete your firmware inventory, the more comprehensive your vulnerability visibility. Uploading firmware across all product lines and versions helps ensure that outdated components and unpatched vulnerabilities don't go unnoticed.

‍

‍