Summary
The PHP project released security updates on 21 October 2026 for CVE-2026-109618 and CVE-2026-109619. The critical vulnerabilities can enable unauthenticated attackers to execute arbitrary code remotely in vulnerable PHP web runtimes. Successful exploitation could allow an attacker to compromise affected web applications and servers, access data available to the PHP process, disrupt application availability, and potentially use the compromised system as a foothold for further attacks.
For SAP solutions, the principal exposure is PHP software deployed alongside, connected to, or hosted within SAP environments. This includes custom PHP applications on SAP Business Technology Platform (BTP), custom PHP runtimes on SAP HANA XS Advanced, and external PHP applications integrated with SAP. Organizations should update affected PHP installations immediately.
Key Points
- Prioritize internet-facing PHP services, followed by internal applications with sensitive data or privileged SAP connections.
- Assess the PHP interpreter actually serving requests, including copies embedded in buildpacks and container images.
- Rebuild and redeploy affected applications with corrected runtimes; changing a buildpack catalog alone does not establish that running applications are patched.
- Review SAP credentials, service bindings, and network access available to affected applications.
Background
CVE-2026-109618 and CVE-2026-109619 affect memory handling within the PHP runtime and can allow invalid or previously released request data to be accessed during processing. The vulnerabilities are present at the runtime layer, meaning potentially affected systems cannot be identified solely by the framework, CMS, or application running on PHP.
Apache mod_php deployments present a particularly significant attack surface because exploitation may occur before application code is executed. PHP-FPM and other PHP web runtimes may also be exposed depending on their configuration. Consequently, application-level authentication does not provide reliable protection against exploitation of the underlying vulnerable PHP runtime.
Impact
Successful exploitation can enable an unauthenticated attacker to execute arbitrary code with the permissions of the affected PHP web worker. While exploitation does not directly provide administrative access to the underlying host or compromise connected SAP systems, it can expose the resources, credentials, and interfaces available to the affected PHP application.
- Where the application is integrated with SAP systems, potential impacts include:
- Exposure of SAP data stored or processed by the application, or accessible through connected databases and APIs.
- Theft of database credentials, OAuth tokens, service-binding secrets, and other integration credentials accessible to the PHP process.
- Unauthorized business operations through OData, REST, SOAP, or RFC interfaces where the compromised application has sufficient permissions.
- Disruption of portals, integrations, and business processes that depend on the affected PHP application.
- Further compromise of connected or reachable systems through stolen credentials or exploitation of additional vulnerabilities.
The extent of the impact depends on the privileges, credentials, and network connectivity available to the compromised application. Containerization and workload isolation can restrict an attacker’s reach, but they do not prevent access to resources that the application is legitimately authorized to use. Consequently, a vulnerable PHP application with privileged access to production SAP systems can represent a significant security and business risk even when the connected SAP systems are fully patched.
Scope
The following matrix is an exposure assessment, not an SAP product-wide affected-version declaration.
| Environment | Assessment and recommended focus |
| SAP S/4HANA, ECC, NetWeaver ABAP/Java, HANA database, SAP GUI, ICM, and Web Dispatcher | These SAP components should not be considered directly vulnerable based solely on the PHP CVEs. Assess PHP runtimes and PHP-based applications separately, particularly where they connect to SAP systems or process SAP data. In these scenarios, the primary risk is compromise of the PHP application and subsequent misuse of the SAP access, credentials, or connectivity available to that application. |
| SAP BTP, Cloud Foundry | Customer applications using a PHP community/custom buildpack, or another deployment that embeds PHP, may contain the vulnerable interpreter. Identify the actual runtime and application owner. |
| SAP HANA XS Advanced | Custom PHP buildpacks may introduce exposure. PHP is a customer-added runtime in this scenario; do not infer that the HANA database engine is vulnerable. |
| SAP BTP, Kyma | Customer container workloads containing affected PHP require assessment and image remediation. This is workload exposure, not evidence of a defect in Kyma’s control plane. |
| External portals, middleware, and third-party integrations | PHP services can create an indirect route to SAP data and operations, regardless of where they are hosted. Include partner-managed applications. |
| SAP-managed cloud services | Obtain service-specific confirmation from SAP or the responsible provider. Customer application exposure cannot establish the patch status of SAP-operated services. |
PHP applications deployed through Cloud Foundry or SAP HANA XS Advanced buildpacks can introduce exposure to these vulnerabilities within SAP environments. However, the presence of a PHP buildpack alone does not indicate that a system is vulnerable. Exposure depends on whether the deployed application uses an affected PHP runtime.
Remediation
Identify and prioritize affected applications
Inventory production, development, test, disaster recovery, and stopped applications that could be restarted. Record the application owner, externally reachable routes, PHP version and package provenance, web runtime, buildpack or image version, and SAP connections. Check the serving runtime; the host’s command-line PHP installation may be different.
Treat an internet-facing PHP application with privileged SAP access as an urgent remediation priority. Internal applications also require attention when reachable from partner networks, compromised endpoints, or other applications.
Install corrected runtimes and redeploy
The PHP advisories identify the following patched upstream releases for supported production branches:
| PHP branch | Affected branch versions | First fixed release |
| 8.2 | Earlier than 8.2.35 | 8.2.35 |
| 8.3 | Earlier than 8.3.36 | 8.3.36 |
| 8.4 | Earlier than 8.4.27 | 8.4.27 |
| 8.5 | Earlier than 8.5.12 | 8.5.12 |
Use these releases or a later supported release containing the fixes. For distribution packages, verify the vendor’s package revision and backport status instead of relying only on the upstream version number. PHP 8.1 and older no longer receive normal upstream updates; PHP has supplied limited source backports for 7.4, 8.0, and 8.1, but these do not restore lifecycle support. Prefer migration to a supported branch or a vendor-maintained package with confirmed fixes.
Cloud Foundry PHP buildpack v5.1.4 includes the corrected PHP releases. Check whether the appropriate buildpack is available and compatible in the target SAP landscape; upstream availability does not prove SAP rollout. Update runtime pins and custom buildpack dependencies as necessary.
Restage or redeploy Cloud Foundry applications so a new droplet contains the corrected interpreter. A normal restart reuses the existing compiled droplet. Rebuild XS Advanced custom runtimes and Kyma images, then replace all affected instances. Verify the runtime in the deployed artifact and active workers, and prevent rollback to unpatched artifacts.
Reduce exposure while patching
Restrict unnecessary public routes and direct backend access. Where practical, place an independent access control in front of the PHP application, constrain outbound connectivity, and reduce integration privileges. Remove or isolate an exposed service if adequate temporary protection cannot be established quickly.
PHP’s configuration measures are partial safeguards. Disabling session upload progress before request parsing and restarting every worker blocks confirmed session paths, but does not cover all variants. PHP 8.5 also has a separate fatal-error-backtrace safeguard. Apply the complete, current vendor guidance rather than treating one setting or a WAF rule as a fix.
PHP also describes temporarily removing its per-request memory limit while enforcing external resource and request limits. This changes availability risk and is not a blanket recommendation for shared SAP hosts or BTP applications. Assess it with the runtime owner; underlying allocation failures remain possible.
Monitor for compromise
Correlate web, application, container or host, and SAP-side telemetry. Investigate unexpected worker crashes, repeated memory errors, unusual request bursts, new executable files, unexpected child processes, and unfamiliar outbound connections. Review abnormal SAP API/RFC activity and use of technical identities associated with the PHP application. These are investigative leads, not unique signatures for these CVEs.
If compromise is suspected, preserve evidence, isolate the application, and rebuild from a trusted artifact. Revoke or rotate exposed credentials and review downstream activity. Patching alone does not remove persistence or invalidate stolen secrets.
Cybersecurity Extension for SAP
The Cybersecurity Extension for SAP can identify SAP BTP applications running in Cloud Foundry that use vulnerable PHP runtime versions, enabling organizations to quickly determine their exposure to CVE-2026-109618 and CVE-2026-109619 and prioritize affected applications for remediation.
Frequently Asked Questions
Are SAP systems directly affected by PHP2Shell?
CVE-2026-109618 and CVE-2026-109619 affect vulnerable PHP runtimes rather than SAP S/4HANA, ECC, NetWeaver, SAP HANA, SAP GUI, ICM, or SAP Web Dispatcher directly. However, PHP applications deployed alongside or integrated with SAP systems may be exposed and could provide attackers with access to SAP data, credentials, or interfaces available to the compromised application.
Can SAP BTP applications be affected by CVE-2026-109618 and CVE-2026-109619?
Yes. Customer-developed applications running in SAP BTP, Cloud Foundry may be exposed when their deployed application contains an affected PHP runtime. The presence of a PHP buildpack alone does not confirm exposure. Organizations should verify the PHP interpreter contained in the deployed application.
How can organizations identify vulnerable PHP applications in SAP BTP?
The Cybersecurity Extension for SAP can identify SAP BTP applications running in Cloud Foundry that use vulnerable PHP runtime versions. This enables security teams to identify applications potentially exposed to CVE-2026-109618 and CVE-2026-109619 and prioritize them for remediation.
Does updating the Cloud Foundry PHP buildpack automatically patch existing applications?
Not necessarily. Existing applications may continue running artifacts created with an earlier PHP runtime. Affected applications should be rebuilt or restaged using a corrected runtime and the PHP version in the resulting deployed artifact should be verified.
Which PHP versions should organizations upgrade to?
For the supported branches identified in your article, the first corrected upstream releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. For vendor-supplied PHP packages, organizations should verify whether the vendor has backported the security fixes rather than relying solely on the upstream PHP version number.
Can application authentication protect against PHP2Shell?
Application authentication should not be considered sufficient protection against these vulnerabilities. Because the vulnerabilities affect the PHP runtime, exploitation may occur below the application layer, depending on the runtime and deployment configuration.
What could happen if an SAP-integrated PHP application is compromised?
An attacker executes code with the privileges available to the affected PHP worker. Depending on the application’s permissions and connectivity, this could expose SAP data, service-binding secrets, OAuth tokens or other credentials, enable misuse of authorized SAP interfaces, disrupt integrations and business processes, or provide a foothold for attacks against other reachable systems.
Does PHP2Shell automatically give an attacker control of SAP?
No. Compromising a PHP application does not automatically compromise an SAP backend or provide SAP administrative privileges. The downstream risk depends on the credentials, permissions, data, interfaces, and network connectivity available to the affected application.
Are containerized PHP applications protected from these vulnerabilities?
Containerization can limit the scope of a compromise, but it does not prevent an attacker from using resources that the compromised application is legitimately authorized to access. PHP applications running in containers should therefore still be assessed for vulnerable runtimes and excessive access to SAP resources.
What should organizations prioritize?
Internet-facing PHP applications should receive immediate attention, particularly applications with access to production SAP systems, sensitive SAP data, technical-user credentials, or privileged APIs. Internal PHP applications should also be assessed where they have sensitive SAP connectivity or can be reached from other potentially compromised systems.
How can the Cybersecurity Extension for SAP help?
The Cybersecurity Extension for SAP provides visibility into SAP BTP Cloud Foundry applications using vulnerable PHP runtime versions, helping organizations identify exposure, locate affected applications, and prioritize remediation for CVE-2026-109618 and CVE-2026-109619.