Could IAM, IGA or PAM mitigate the critical PHP vulnerabilities?

On 21 October 2026 the PHP project published an advisory titled "Critical remote code execution vulnerabilities, update now". Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two vulnerabilities that can allow unauthenticated remote code execution, and the project considers every installation serving web requests to be at risk.

After the advisory, a client asked us a specific question: could access management (IAM), identity governance (IGA) or privileged access management (PAM) do anything to mitigate them?

The flaw is in the PHP runtime and is fixed by updating; no identity control changes that. In our case we run PHP-FPM and updated our servers as soon as the fixed versions were published. We also set session.upload_progress.enabled=0, which the advisory itself recommends keeping even after patching. FPM listens on a Unix socket, so September's IPv6 ACL bypass (CVE-2026-91768) did not affect us. And our internal panels were already behind SSO before the advisory, out of reach of anyone on the internet.

But the client's question has another part worth answering: who can reach a vulnerable server, and what they can do once inside. That depends to a large extent on identity and access decisions.

What the October releases fix

The two vulnerabilities, which the press and security firms have dubbed php2shell, both relate to how PHP cleans up the state of a request, but they are distinct flaws.

CVE-2026-109618, RCE via OOM corruption (GHSA-w8hw-w9fx-j79w). When memory runs out, PHP uses longjmp() to abort the request and can leave data partially initialized, which the subsequent shutdown treats as valid. It has a CVSS 4.0 score of 9.2.

CVE-2026-109619, RCE via stale global state (GHSA-6wmf-4rv5-p3rp). A persistent worker can keep references to memory freed by an earlier request, either because of a fatal error or because of a warning emitted during cleanup. Some operations, such as INI directive diagnostics and session.upload_progress, read that state before the next request resets it. It also scores 9.2 under CVSS 4.0, and it requires both requests to land on the same worker: more workers lower the odds of each attempt but do not remove the condition.

What has been confirmed depends on how PHP runs:

Mode	CVE-2026-109618	CVE-2026-109619
Apache mod_php	RCE confirmed, before any application code runs	RCE confirmed
PHP-FPM	Susceptible per source analysis; no complete exploit demonstrated	RCE confirmed via `session.upload_progress`, given a suitable application operation; the INI path applies only if the frontend sends `PHP_VALUE` or `PHP_ADMIN_VALUE`
FrankenPHP	Likely susceptible	No INI path established with the default configuration, which does not make it immune
LiteSpeed (LSAPI)	Application-specific exploitation, likely but unvalidated	Conditional candidate

Each branch has its fixed version: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Earlier versions in each branch remain exposed. PHP 8.1 and older no longer receive updates, although given the severity the security team published minimal source backports for 7.4, 8.0 and 8.1, and some distributors provide their own. PHP 8.2 reaches end of life on 31 December 2026. Several security firms already report public exploits and exploitation attempts.

The advisory came a month after another security round. On 24 September, versions 8.5.11, 8.4.26, 8.3.35 and 8.2.34 fixed, among others, CVE-2026-91768 (in PHP-FPM, the listen.allowed_clients ACL compared only 12 of the 16 bytes of an IPv6 address), CVE-2026-91766 (the HTTP stream wrapper forwarded credential headers when following redirects to another origin) and CVE-2026-91765 (unbounded recursion in the SOAP server that lets an unauthenticated attacker crash the process). The first two are access control problems, and we come back to them below.

Why the login screen does not protect against these CVEs

The exploit paths the advisories describe do not go through the application's login. Under mod_php everything happens before any application code starts running; under FPM the confirmed path goes through the application, but it does not require the attacker to be authenticated. The login form, application MFA, password policies and the role recertifications managed by IGA all sit outside the exploit's path.

For a public PHP site, such as the corporate portal, a store or a CMS, the answer is to patch and restart every worker. The temporary measures the PHP project published for those who cannot update right away are in the checklist at the end, with their limits.

The role of IAM for applications that should not be public

Most organizations run more PHP than they think: database panels, monitoring tools, wikis, vendor consoles. Many of those applications sit on the internet protected only by their own login screen, which is no help against these CVEs.

An identity-aware proxy, one that requires a valid SSO session before forwarding any request to the PHP server, changes who can reach the vulnerable worker: no longer anyone on the internet, but authenticated users with MFA. It works under two conditions. The proxy must terminate authentication itself, because if it merely forwards and lets the application validate the session, the request has already reached the runtime. And the network must prevent direct access to the origin server. What you gain is less exposure while you update, not a reason to postpone the update. A compromised account can also still get through.

Other PHP CVEs depend on the attacker having access to a protected feature, for example unsafe deserialization in an administrative module. There, SSO with MFA reduces the accounts an attacker can use, least privilege limits what each one exposes, and automatic deactivation of orphaned accounts, which is IGA's job, removes forgotten credentials. It pays to verify that the feature really sits behind authentication: the SOAP server in CVE-2026-91765 could be attacked without authentication on any reachable SoapServer endpoint.

For local flaws, which require some foothold on the server, the ground is PAM: named accounts instead of shared root, recorded sessions and time-bound elevation. That foothold does not have to be a legitimate account; it can also come from exploiting an application, from stolen credentials or from lateral movement.

What happens once the attacker is running code

If the application is public and the patch arrived late, the attacker runs code with the web worker's privileges, as the advisories put it. What they can do from there depends on decisions made before the incident:

One service account per application in PHP-FPM, with no write access to its own code and no access to other pools. The separation only works if permissions back it up: pools with different users that share directories, readable configuration files or credentials end up almost as exposed.
Database credentials owned by the application and with least privilege, never root or a user with access to every schema.
Secrets out of the worker's reach. Moving them out of the webroot prevents accidental downloads, but whoever runs code as www-data reads everything www-data can read.
Inventory, owner and rotation for service credentials. This is non-human identity governance, and it is where IGA and PAM contribute most in an incident like this. After an exposure, assume everything the worker could read was read; if rotating it takes weeks because nobody knows where else it is used, the incident lasts weeks.
Detection of anomalous use of application credentials, such as a database account querying tables it never touched or an API token used from a different address.

The September CVEs that touch access control

In CVE-2026-91768, listen.allowed_clients is the list of IP addresses allowed to speak FastCGI to a PHP-FPM pool, and over IPv6 matching the first 96 bits was enough to pass. The advisory clarifies that Unix sockets, IPv4-only deployments and setups with an external firewall as the real boundary are not affected. The underlying problem is using the network address as authorization: when that check fails, no other control is left. With FPM on a Unix socket, or a firewall rule scoped to the specific web server, the comparison bug would not have mattered.

CVE-2026-91766 affects applications that call an API through file_get_contents() or fopen() and pass credentials in the Authorization or Cookie headers. When following a redirect to another host, another port or from HTTPS to HTTP, PHP forwarded those headers unchanged, and whoever controlled the target received the token or the cookie. Short-lived tokens issued by an identity provider shorten how long a leaked credential remains usable, although they do not prevent its immediate use; that is why they should be combined with restricted audience and scopes, redirect controls, revocation where available and, where appropriate, client-bound tokens.

Practical checklist

Infrastructure, for today

Inventory every PHP installation serving web requests, including the ones "nobody uses".
Update each branch to its fixed version (8.2.35, 8.3.36, 8.4.27 or 8.5.12), or to the vendor package that carries the patches, verified rather than assumed, and restart every worker.
Verify in production which version each SAPI actually loads and that old workers have stopped serving requests.
If the patch cannot be applied today, use only the partial mitigations the advisory describes for each CVE, document the residual exposure and plan the exit from 8.1 and older:
- CVE-2026-109618: memory_limit=-1 enforced so that no pool, directory or application restores a finite limit, plus request size and complexity limits at the frontend.
- CVE-2026-109619: session.upload_progress.enabled=0 and, on 8.5, fatal_error_backtraces=0.
- Apply them in php.ini, the FPM pool or server configuration, not via ini_set() or .user.ini, and assess their effect before changing configuration.
Disable session.upload_progress if unused, even after patching, as the advisory itself recommends.

Identity and access

Classify every PHP application: must it be public, or is it used only by identifiable people? The latter go behind an identity-aware proxy with SSO and MFA, with no direct access to the origin.
One service account per application for PHP-FPM, with no cross-privileges.
Database and API credentials with least privilege, inventoried, with an owner and rotation.
Secrets out of the worker's unnecessary reach; short-lived, scoped tokens instead of static passwords where feasible.
Administrative access to servers through PAM: named accounts, recorded sessions, no shared root.
Alerts on anomalous use of the application's credentials, not only people's.
Replace IP-address ACLs as the sole control with Unix sockets or rules scoped to the real origin.

Our view

With the use of AI, advisories like this one are inevitable: AI speeds up both the discovery of flaws, through assisted code analysis and fuzzing, and the building of exploits from a published patch. In this case, several firms reported public exploits within days of the advisory. We see no way to stop them from appearing; what is in our hands is minimizing the risks and reducing their effects, and that depends above all on automated procedures: DevOps practices, infrastructure as code, configuration deployment and scanning.

This case shows it clearly. With versioned configuration, applying session.upload_progress.enabled=0 across every pool is one change and one deployment, not a server-by-server review. With regular scans, the inventory includes the installations nobody remembers. And with technical debt managed, with an end-of-life calendar for each PHP version, no servers are left on 8.1 or older, which no longer receive official releases and depend on backports or their distributor to get out of an advisory like this.

At Clear Intelligence we regularly review architectures where anyone can reach a server like this one and the worker account can read practically everything. Reducing both does not prevent the next CVE, but it changes what an attacker can do with it.

Sources

Related services

IAM Health Check — Identify which internal applications are exposed without identity controls and which service accounts hold more privilege than they need.
Integrations — Put your internal applications behind SSO and MFA through an identity-aware proxy integrated with your IAM platform.
Managed Support — Continuous operation with credential inventory, rotation and anomalous-use detection.