Executive Summary
For the vast majority of SAP landscapes, PHP2Shell is not an SAP problem. SAP has confirmed that PHP is not part of its core technology stack and products and, as of 25 October 2026, has no evidence of exploitation across its product and service portfolio. The ABAP, Java and HANA platforms that make up a typical SAP landscape do not run PHP.
That said, “not an SAP core problem” is not the same as “nothing to do”. PHP turns up at the edges of many SAP environments: custom applications deployed on SAP BTP, PHP-based integration layers talking to SAP databases, and the web portals and CMS front-ends that sit in front of SAP processes. If you have any of those, you need to act this week.
This post summarises what the vulnerabilities are, what SAP has said in Knowledge Base Article 3841665, and what you should check in your own landscape.
What is PHP2Shell?
PHP2Shell is the name the security community has given to two critical vulnerabilities in the PHP runtime itself, both rated with aCVSS of 9.2/10.0 and both allowing unauthenticated remote code execution. Details leaked on 20 October 2026, ahead of the coordinated disclosure, and the PHP project shipped emergency fixes on 21 October 2026.
| CVE | Root cause | Impact |
|---|---|---|
| CVE-2026-109618 | PHP handles an out-of-memory condition by aborting the request mid-way, leaving request data partially initialised. Cleanup then trusts that broken state. | Unauthenticated RCE as the web worker account, validated by PHP against mod_php with default settings. |
| CVE-2026-109619 | PHP keeps global pointers to request-owned memory after that memory is freed. The next request on the same worker can use the stale state. | Unauthenticated use-after-free, memory disclosure and RCE, validated against mod_php and PHP-FPM. |
A few points matter for how you should prioritise:
- It is the runtime, not the application. Any PHP installation serving web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed. A fully patched WordPress or Laravel on an unpatched PHP is still vulnerable.
- Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older, including end-of-life 7.x and 8.0/8.1 branches, has no official fix and must be upgraded.
- There is no complete mitigation. PHP’s own release notes say updating is the only safe choice. Configuration changes (memory_limit=-1 set administratively, session.upload_progress.enabled=0, fatal_error_backtraces=0 on 8.5) only reduce exposure while you schedule the update.
- Exploitation is already being attempted. Working reproductions exist from several research teams and honeypot operators have reported scanning and exploitation attempts. CISA has advised organisations to patch immediately and prioritise internet-facing systems.
What SAP says: KBA 3841665
SAP published Knowledge Base Article 3841665 (version 15, released 23 October 2026) with its impact assessment. The headline: SAP has no evidence of exploitation in its portfolio, PHP is not a core language in its stack, and where PHP does appear the responsibility is split between SAP and the customer. If a product is not listed, SAP states there is no known impact.
| SAP area | SAP’s position | Who acts |
|---|---|---|
| SAP BTP, Cloud Foundry Runtime | Platform not affected. PHP is only available through the community php_buildpack; patched buildpack v5.1.4 (PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) released 21 October 2026. | Customer: re-stage every PHP application so the new buildpack is picked up. SAP handles its own workloads. |
| SAP BTP, Kyma Runtime | Platform not affected. SAP does not operate a PHP runtime; PHP only exists inside customer containers. | Customer: rebuild and redeploy any container image that includes PHP, using a fixed version. |
| On-premise: SAP SQL Anywhere, SAP ASE, SAP IQ, SAP MaxDB, SAP HANA XS Advanced | These products have documented PHP support or integration (drivers, connectors, sample apps). | Customer: if you run PHP against these databases, follow the CISA advisory and patch, internet-facing systems first. |
| SAP Private Cloud (RISE / ERP Private Cloud Edition) | The PHP package is not part of the standard OS image. A small number of assets had it installed; all have been patched. Monitoring and scanning continue. | SAP: no customer action required. |
| SAP Sales Performance Management (SPM) | PHP is not used in the product itself but in backend tooling. That tooling has been patched. | SAP: no customer action required. |
| All other SAP products | Not mentioned, therefore no known impact. | None, beyond your own PHP inventory (next section). |
SAP has committed to update the KBA as the assessment continues, with the next scheduled update no later than Monday 26 October 2026, 21:00 CET. The KBA is additionally tagged against SAP SuccessFactors HCM Suite, SAP Fieldglass, SAP Incentive Management, SAP Territory and Quota, SAP Cloud Portal service and the SAP Agent Lifecycle and Agent Performance Management products; the body of the note does not describe a customer action for any of these, so we read the tagging as scope-of-investigation rather than confirmed impact. If you run those products, keep an eye on the KBA for the Monday update.
One practical note on the on-premise databases: SQL Anywhere, ASE, IQ and MaxDB are not themselves PHP applications. The exposure SAP is pointing at is the PHP code that customers (or partners) wrote on top of their PHP database extensions. The database server is not what you patch; the PHP host in front of it is.
What you should do now
Your core SAP systems (S/4HANA, ECC, SAP NetWeaver AS ABAP and AS Java, SAP HANA, SAP Web Dispatcher, SAP Gateway) do not run PHP and need no patch for PHP2Shell. The work is in finding the PHP that lives around your SAP landscape. Work through the checklist that matches your situation.
Inventory every PHP runtime that touches SAP. You cannot patch what you have not found. Typical places PHP hides in SAP-centric environments:
- Custom apps on SAP BTP Cloud Foundry using the PHP buildpack, and PHP containers on Kyma
- Customer portals, supplier portals and B2B storefronts built on WordPress, Drupal, TYPO3, Magento, Laravel or Symfony that call SAP via OData, RFC/SOAP, SAP Gateway or the SAP Integration Suite
- Middleware and glue code: PHP scripts using saprfc, sapnwrfc, the SQL Anywhere / ASE / MaxDB PHP extensions, or HANA via ODBC
- Monitoring and ops dashboards (Nagios, Zabbix, Cacti, Grafana plugins, phpMyAdmin) on jump hosts and admin networks
- Internal wikis, ticketing and documentation tools (MediaWiki, GLPI, osTicket) that sit on the same VLAN as SAP
- Appliances and partner products that embed a PHP web console
If you run PHP on SAP BTP Cloud Foundry: re-stage every PHP application (cf restage <app>) so it picks up php_buildpack v5.1.4 or later. Check the staging log to confirm the PHP version is 8.2.35, 8.3.36, 8.4.27 or 8.5.12. If you pin a buildpack version in your manifest, update the pin first.
If you run PHP containers on SAP BTP Kyma: rebuild images from a fixed base (for example php:8.4.27-fpm or newer), redeploy, and verify no old replicas remain.
If you run PHP against SAP SQL Anywhere, ASE, IQ, MaxDB or HANA XS Advanced: patch the PHP host, not the database. Prioritise anything reachable from the internet or from user networks.
If you cannot patch immediately: apply PHP’s interim hardening administratively (so applications cannot override it): memory_limit=-1 via php_admin_value, session.upload_progress.enabled=0, and fatal_error_backtraces=0 on PHP 8.5. Restart all workers afterwards. Add request-size and multipart limits at your reverse proxy or WAF. Treat this as buying days, not as a fix.
Assume compromise where PHP was exposed and unpatched after 20 October. Patching closes the door; it does not evict anyone already inside. For any internet-facing PHP host that connects to SAP, review web server logs for unusual POST requests and memory-exhaustion errors, check for new files in web roots and temp directories, and rotate any SAP credentials, RFC users, OAuth client secrets or API keys stored on that host. A PHP front-end with a technical SAP user is a direct path into your SAP system.
Review SAP Private Cloud and SPM only passively. SAP has patched its side. Confirm with your SAP account team if you want written assurance, and watch KBA 3841665 for the 26 October update.
Check your SAP connections from the SAP side. List the technical users, RFC destinations and API keys that your PHP applications use to reach SAP. Make sure each has the minimum authorisations it needs, and that none have SAP_ALL or broad RFC rights. If a PHP host is compromised, this is what limits the blast radius.
Where SecurityBridge fits in
PHP2Shell lives outside the SAP system boundary, so the patching itself is a job for your web and platform teams, not for the SecurityBridge platform. Where we help is on the SAP side of the connection: making sure that a compromised PHP host cannot become a compromised SAP system, and spotting it quickly if someone tries.
Threat detection on inbound connections. Our Event Monitoring flags unusual RFC and HTTP/OData activity from technical users, logons from unexpected hosts, and privilege use that does not match a user’s normal pattern and trigger one of the SecurityBridge Listeners. If an attacker lands on a PHP portal and starts using its SAP service account to explore functions outside it’s scope and critical actions for example, that is what should light up.
Technical user and authorisation review. The Security & Compliance Monitor shows which technical users hold broad authorisations, which RFC destinations store credentials, and where SAP_ALL or wide RFC rights are assigned. Use it to tighten the accounts your PHP applications use (step 8 above).
Interface visibility. Our interface monitoring gives you the list of systems and users calling into SAP, which is a fast way to answer “which external hosts actually talk to our SAP systems?” when you are building the PHP inventory in step 1.
Patch Management stays unaffected. KBA 3841665 is a Knowledge Base Article, not an SAP Security Note, and SAP has not released a security note for PHP2Shell because no SAP-delivered component needs a patch. Your Patch Day workload does not change; if SAP does publish a note after the 26 October update, it will appear in Patch Management as usual.
Our Security Research lab is monitoring the SAP KBA and the public exploitation reports and will update this post if SAP’s assessment changes. Customers with questions about their specific setup can reach us through the usual support channels.
Bottom line
PHP2Shell does not change the security posture of your SAP core. It does change the urgency of patching every PHP system that sits next to it, especially the ones holding SAP credentials. Find them, patch them to 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or re-stage them on BTP, check the ones that were exposed, and make sure the SAP accounts they use cannot do more than they need. Then watch KBA 3841665 for SAP’s next update on Monday 26 October.
Sources
- SAP KBA 3841665, PHP Vulnerability impact on SAP Products, version 15, 25 October 2026 (SAP for Me, S-user required)
- PHP 8.4.27 release notes, PHP project, 21 October 2026
- PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- CERT-EU Security Advisory 2026-018
- Datadog Security Labs: PHP2Shell detection, analysis and remediation
- watchTowr: PHP2Shell FAQ
- Huntress: Rapid Response, PHP2Shell