PHP2Shell (CVE-2026-109618): Patch PHP, Rotate Login Secrets

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of critical bugs in the PHP runtime that let an unauthenticated request run code on the server before any of your application code runs. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both, so patch now, then rotate the login secrets the host held.

This post is for teams that already saw the headline and run PHP applications, whether Laravel, Symfony, WordPress or an older monolith, that sign users in through Keycloak or another identity provider. The news coverage stops at “patch now”, which is the right first step. We add the part that matters for an application that acts as an OpenID Connect or SAML relying party: a PHP host that was reachable while unpatched held a client secret, session cookies, refresh tokens and often a SAML signing key, and code running as the web worker can read all of them. So the job is patch first, then rotate, and we give an order for both.

What is PHP2Shell?

PHP2Shell is the name Wiz Research and the press use for two bugs in how the PHP engine handles out-of-memory conditions and fatal errors in the middle of a request. The PHP project published both on 21 October 2026, and the advisory on php.net lists them as “RCE via OOM corruption” (CVE-2026-109618) and “RCE via stale global state” (CVE-2026-109619), and names the affected server APIs as PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk on mod_php, where the project demonstrated an exploit “where an unauthenticated request can trigger the attack before any application code runs” (PHP: Critical remote code execution vulnerabilities, 21 October 2026). Both GitHub advisories credit four reporters by their GitHub handles, one of them sagitzadik-wiz (GHSA-w8hw-w9fx-j79w), and Wiz’s own disclosure timeline dates the first find to 19 August 2026, with unauthenticated remote code execution confirmed against Drupal on 20 August and against WordPress on 21 August (Wiz Research, PHP2Shell).

The disclosure did not go to plan. Ubuntu’s security team notes that the coordinated date was 22 October, but “due to a public leak, the disclosure date has been moved forward to 21 October 2026 14:00 UTC” (Ubuntu, php2shell fixes available). SecurityWeek reports that a video of a working proof of concept was published by mistake ahead of the disclosure date, that mitigation advice given to critical infrastructure organisations may have leaked as well, and that six hours before the coordinated release Chainguard published built images containing the fix it had received in advance (SecurityWeek, 21 October 2026). That leak is why the window between “attackers know” and “a fix exists” was measured in hours rather than days, and why the rotation advice later in this post applies even to teams that patched quickly.

The CISA alert of 21 October describes the pair as allowing “unauthenticated remote code execution in PHP” and affecting “all PHP installations serving web requests”. It asks you to inventory your PHP systems, “apply the patch immediately, prioritizing internet-facing systems”, take systems offline if you cannot patch, use a web application firewall as an interim measure, and watch for suspicious activity from PHP worker processes. It also says CISA had “not observed exploitation of these vulnerabilities as of the time of publication” (CISA alert, 21 October 2026). Private sensor networks saw attempts the same day, as the detection section below explains.

CVE-2026-109618: remote code execution via out-of-memory corruption

CVE-2026-109618 is in the way PHP bails out when a memory allocation fails. The CVE record, assigned by the PHP Group, explains that PHP uses longjmp() to escape an out-of-memory error, and that when the allocation fails during request initialisation, before setup is complete, the engine leaves request memory partly uninitialised and the later cleanup code reads it or branches on it as if it were valid (CVE-2026-109618 record, NVD entry). The GitHub advisory describes several ways to reach that state through multipart form parsing: a request without a usable content length, unlimited headers inside multipart parts, and empty file fields that create metadata without counting toward the upload limits. It confirms “unauthenticated remote code execution as the web worker account” over HTTP against mod_php with default settings (GHSA-w8hw-w9fx-j79w).

The practical consequence for a login page or an SSO callback is that the URL does not matter. The corruption happens while PHP is still parsing the request body, so your framework’s router, your authentication middleware and your CSRF check never get a chance to run. An attacker can send the request to any path that PHP handles, which on most servers is every path.

The advisory lists interim measures for this bug, from request size limits to an unusual use of memory_limit, and it is explicit that they are incomplete. We cover them, with their trade-offs, in the section on what to do while you wait to patch.

CVE-2026-109619: remote code execution via stale global state

CVE-2026-109619 is a different route to the same outcome. PHP keeps some state in globals that live as long as the worker process but point to memory that belongs to one request. The CVE record says that when a fatal error or memory exhaustion interrupts a request before that state is reset, the globals keep pointing at freed memory, and the next request handled by the same worker can use that stale state before normal initialisation replaces it (CVE-2026-109619 record, NVD entry). The GitHub advisory names two confirmed paths: the storage of fatal error backtraces, which exists in PHP 8.5, and the session upload progress feature, which is confirmed on mod_php, with a separate validated path on FPM. The impact is “unauthenticated heap use-after-free, memory disclosure and remote code execution with the web worker’s privileges” (GHSA-6wmf-4rv5-p3rp).

Session upload progress is worth a sentence because, according to the security firm Hadrian, most of the attacks it observes abuse it (SecurityWeek). When the session.upload_progress.enabled setting is on, any multipart POST that contains a field named after session.upload_progress.name makes PHP track the upload inside $_SESSION (PHP manual, session upload progress), and the manual’s configuration table gives that setting’s default as PHP_SESSION_UPLOAD_PROGRESS (PHP manual, session runtime configuration). Most applications never use it, which is why the advisory’s interim measure is to set session.upload_progress.enabled=0 and restart the workers, set fatal_error_backtraces=0 on PHP 8.5, remove invalid or deprecated per-request settings, and fix fatal errors and timeouts on paths an attacker can reach. The advisory’s conclusion is that “updating to a release containing the complete state reset patch is the only reliable mitigation” (GHSA-6wmf-4rv5-p3rp).

The memory disclosure part of this CVE is the detail that turns a server problem into an identity problem. Wiz writes that it “demonstrated that attackers could read sensitive data from the PHP process’s memory” without needing to achieve remote code execution, and that this memory “may contain passwords, authentication tokens, API keys and certificates belonging to other requests” (Wiz Research). On a relying party, that leaked memory can contain the tokens and session identifiers of users who are signing in at the time.

Which PHP versions fix PHP2Shell, and which get no fix?

The fixed releases are the same across every source we checked: the php.net advisory, which php.net also links from the banner on its security page, both CVE records and the CISA alert. The table adds the support status of each branch from php.net, because it decides whether you can expect further security fixes on that line (PHP supported versions).

At the time of writing, the php.net changelog entries for all four fixed releases list both GHSA ids under the core fixes, so a changelog check is one way to confirm a build carries the patch (PHP 8 ChangeLog).

PHP 8.1, 8.0 and the 7.x line are the hard case. The php.net advisory says “PHP 8.1 and older no longer receive updates from the PHP project” and points those users to their vendors or to an upgrade, but it adds that, given the severity, the PHP security team “provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor” (php.net advisory). Those are patches against the source tree, not packaged releases. The distributions are filling the rest of the gap: Ubuntu lists fixed packages for its php8.1 on 22.04 and, under Expanded Security Maintenance, for php7.4 on 20.04 and older releases (Ubuntu), and Help Net Security also notes the source backports for 7.4, 8.0 and 8.1 (Help Net Security, 21 October 2026). If you run an unsupported PHP that nobody packages a fix for and you cannot build from source, the interim measures above and network isolation are what you have until you upgrade the runtime, and CISA’s advice to take the system offline applies with full force.

In what order should I patch distro packages, containers and managed hosts?

Work from the most exposed host inward, which is also what CISA asks for. The order below assumes you have more PHP than you can patch in one sitting.

1. Inventory before anything else. Run php -v and php-fpm -v on every host and list every container image that contains PHP, including the admin tools and status pages nobody owns. CLI-only hosts such as cron and queue workers matter less for this pair, because the bugs are reached through web requests, but they usually share a package or an image with the web workers, so patch them in the same pass.
2. Internet-facing web hosts first, then internal ones. A host that terminates HTTP from the internet is the one the scanners already found. Internal hosts come next, because a stale global state bug on an internal admin app is still reachable by anyone who can send it a request.
3. Distribution packages. On Debian and Ubuntu, run apt update and apt upgrade, and then restart Apache or PHP-FPM; Ubuntu’s note says a restart of the Apache daemon is required for the fix to take effect (Ubuntu). At the time of writing, Debian’s security tracker lists 8.4.27-1deb13u1 for trixie under DSA-6574-1 and 8.2.35-1deb12u1 for bookworm under DLA-4848-1 (Debian security tracker, CVE-2026-109618). Do not judge a distro build by php -v alone. Ubuntu 24.04’s fixed package is 8.3.6-0ubuntu0.24.04.13, so the binary still reports 8.3.6 after the fix; the package changelog is what tells you the patch is in.
4. Containers. At the time of writing, the official image definition for the Docker Hub php image lists 8.2.35, 8.3.36, 8.4.27 and 8.5.12 tags (docker-library official images, php). Rebuild anything that starts from php:8.x-fpm or php:8.x-apache and redeploy; a floating tag such as php:8.3-fpm picks up the fix on the next pull, a pinned digest does not. Third-party base images, including framework-specific ones, need their maintainers to rebuild first, so check the image’s PHP version with docker run --rm image php -v rather than trusting the image’s own version label.
5. Managed and shared hosting. If a provider runs the PHP runtime for you, you cannot patch it yourself. Check their status page or advisory, confirm the version they now serve, and if they are slow, apply the interim measures you still control, such as request size limits at a CDN or WAF in front of the host.
6. Verify, then move to rotation. After each host restarts, confirm the running version from inside a web request, not just from the shell, since a server can have more than one PHP installed. Then start the rotation steps below for that host while you patch the next one.

What can I do while I wait to patch?

Nothing short of the patch closes these bugs: updating to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is the only real fix, and the people who wrote it say so. The php.net advisory says its measures “reduce exposure to specific attack paths but do not make an installation safe” (php.net advisory), and BleepingComputer, which writes that the mitigations “don’t fully protect against exploitation”, reports PHP core developer Gina Peter Banyard warning that no PHP2Shell mitigation would fully block attacks and that the official patches are the only permanent defence (BleepingComputer, 21 October 2026). With that caveat, the measures below reduce the attack surface and buy time.

• Turn off session upload progress (session.upload_progress.enabled=0) and restart workers. This removes the path that Hadrian says most of the attacks it observes abuse (SecurityWeek).
• Cap request bodies at the edge. Enforce a low decoded request size at the proxy or web server, keep post_max_size low (the php.net advisory suggests 8M where nothing uploads and 32M where it does) with upload_max_filesize below it (php.net advisory), and, per the GitHub advisory, reduce max_input_nesting_level and block multipart requests entirely on applications that do not accept uploads (GHSA-w8hw-w9fx-j79w).
• Put a WAF in front and keep its rules current. CISA recommends a web application firewall as an interim control, and Help Net Security reports that Cloudflare has an initial set of rules deployed for the known exploit vectors (Help Net Security). The Hacker News reports Cloudflare saying it saw attack traffic against its customers and watched attackers change their payloads to get around its rules, which it had switched on by default at 03:02 UTC on 21 October, before the patch, so treat a WAF as a filter, not a fix (The Hacker News, 21 October 2026). If your Keycloak runs on Skycloak, the WAF is a paid add-on on the Launch and Business plans and is included on Enterprise (Skycloak pricing); it filters the traffic that reaches the Keycloak side of the login flow, and your PHP application still needs its own patch.
• Isolate what you cannot patch today. Move it behind a VPN or an allowlist, or take it offline, which is CISA’s own fallback.
• Do not treat memory_limit=-1 as a fix. For CVE-2026-109618 the advisory suggests setting memory_limit=-1 through php_admin_value in the FPM pool or Apache configuration, and it is precise about the limit of that measure: it “removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path” (php.net advisory). It narrows the confirmed exploit path and leaves the bug in place. It also needs a container or cgroup memory limit, preferably with a policy that kills only the affected worker, or you have traded a security bug for an easy denial of service, and the advisory warns against using RLIMIT_AS or RLIMIT_DATA for that limit because they can cause the vulnerable allocation failure themselves.

What does PHP2Shell expose on an OIDC or SAML relying party?

Code running as the web worker user can read whatever the application can read. On a typical PHP relying party that is a short and sensitive list, and the memory disclosure variant of CVE-2026-109619 can reach parts of it without a full compromise.

Two points keep this in proportion. First, Keycloak runs on a Java runtime, its getting-started guide asks for OpenJDK 25 (Keycloak, getting started on OpenJDK), not on PHP, so a self-hosted Keycloak needs no PHP patch for PHP2Shell, and the same goes for the Keycloak clusters on Skycloak’s managed hosting, which are Keycloak servers that we operate, not PHP stacks. What is exposed is the trust Keycloak placed in the PHP application: the secret it issued to that client, the sessions it opened for that client’s users and the tokens it handed over. Second, a leaked client secret alone does not let anyone sign in as an arbitrary user; it lets them act as your application, which in OIDC is the party that receives codes and tokens and asks for refreshes. Combined with intercepted authorization codes or the refresh tokens from the session store, that is enough to hold user sessions open after you patch.

Our Laravel and Keycloak tutorial has you add the Keycloak client secret to the application’s .env file as KEYCLOAK_CLIENT_SECRET, and a file the application reads at start-up is one that code running as the web worker can read too. The same applies to a client secret in a Symfony bundle configuration or a WordPress SSO plugin’s options table.

What should I rotate after patching, and in what order?

Rotate after the patch is live on that host, not before. A new secret written to a host that is still vulnerable is just a new secret to steal. Then work through the list in this order, because each step limits what the previous one left open.

1. Regenerate the Keycloak client secret. In the admin console, regenerate the secret on the client’s credentials tab (the Server Administration Guide says to “click Regenerate to recreate random secret if necessary” in its section on confidential client credentials, and its rotation section places Regenerate Secret “in the client’s credentials tab”: client credentials, client secret rotation), or call the Admin REST API, then deploy the new value to the application. On Keycloak 26.8 and later you can enable the client secret rotation policy first; its Rotated secret expiration setting is, in the guide’s words, “the remaining expiration time for the old secret” after a rotation (Keycloak Server Administration Guide, client secret rotation), which gives a rolling deploy an overlap in which both secrets work. Our post on client secret rotation in Keycloak 26.8 explains the policy and its one trap, which the guide states as “rotations do not occur automatically or through a background process” (Keycloak Server Administration Guide, client secret rotation). Without the policy, rotating “risked service interruptions if the old secret was invalidated before all consumers switched to the new one”, as the 26.8.0 release notes put it (Keycloak release notes), so coordinate the deploy.
2. Revoke the sessions the host could have exposed. If you can identify affected users, delete their sessions individually through the Admin REST API, as our guide to revoking a single Keycloak session shows; Skycloak’s session management feature covers the session timeouts and concurrent-session limits that decide how long a stolen session stays usable. If you cannot, use the realm-wide control: under Sessions, open the Revocation action and click Set to now, which sets the policy to the current date and time so that sessions and tokens issued before it are invalid, then click Push, which sends that policy to the registered OIDC clients that use the Keycloak OIDC client adapter (Keycloak Server Administration Guide, revoking active sessions). That logs everyone in the realm out, so schedule it. The guide also says administrators can revoke offline tokens by setting a revocation policy, and can revoke them for one user from that user’s Consents tab (Keycloak Server Administration Guide, offline access).
3. Rotate the application’s own keys. Generate a new APP_KEY or APP_SECRET, and flush the session store so that sessions encrypted or signed with the old key die with it. Laravel’s documentation describes listing the old key in APP_PREVIOUS_KEYS so values encrypted with it still decrypt during the changeover (Laravel documentation, gracefully rotating encryption keys); whether you want that grace period during an incident is a judgment call, since the point of the rotation is to end the old sessions.
4. Replace the SAML service provider key pair, if the application is a SAML client, and upload the new certificate on the client’s Keys tab in Keycloak, where the guide says you “need to import or generate the key” for Client Signature Required and Encrypt Assertions unless Keycloak downloads it from your metadata URL, and recommends generating the key pair outside Keycloak and uploading only the certificate (Keycloak Server Administration Guide, SAML client Keys tab), so assertions are encrypted for the new key and signatures made with the old one stop verifying.
5. Rotate every other credential the host held: database passwords, API keys, SMTP credentials and the service account secret if the application used one to call the Admin REST API. If that service account carried realm-management roles, also review the realm’s admin events for changes you did not make, because the attacker had an administrator’s reach for as long as the secret was valid.
6. Move the secrets somewhere better than a file, once the fire is out. On the Keycloak side, the vault SPI lets fields such as SMTP, identity provider and client credentials reference a vault entry with a ${vault.key} expression instead of holding the value directly (Keycloak Server Administration Guide, using a vault to obtain secrets), and the same principle applies to the application: a secret that is fetched at start-up from a secret manager and held only in memory is still readable by code running in the worker, but it is not sitting in a file that every future bug can read too.

After rotating, watch the Keycloak event log for the next few days. The user events Keycloak records include a code-to-token event, when “an application, or client, exchanges a code for a token”, and a refresh-token event, when a client refreshes one (Keycloak Server Administration Guide, event types); those events from an address that is not your application’s are the sign that a copy of the old secret or a stolen token is still in use, and CLIENT_LOGIN_ERROR events, which appear in the same guide’s example list of error event types to enable, show you who tried the old secret. Skycloak’s audit logs track the same Keycloak authentication events and export them to your SIEM. If you stream events out, our guide to Keycloak event streaming and webhooks lists these event types, including CODE_TO_TOKEN and REFRESH_TOKEN, and covers filtering and routing them, and on Skycloak’s managed hosting the built-in HTTP webhook is set up in the Skycloak console, as our guide to forwarding Keycloak events to a SIEM through the Skycloak webhook shows. Once the incident work is done, the Keycloak security hardening checklist covers shortening the access token lifespan and turning on Revoke Refresh Token, so the next leaked token is worth less.

How do I tell whether anyone tried PHP2Shell on my servers?

The honest answer is that you can see the attempts far more easily than you can see a success, which is the main reason we recommend rotating on any internet-facing host that was unpatched after 20 October.

The attempts are visible. ELLIO’s sensor network saw its first PHP2Shell request at 08:36 UTC on 21 October, about five and a half hours before the fix was published, and by 23:00 UTC had recorded 743 requests from 33 addresses carrying the session upload progress field (ELLIO, PHP2Shell: what we observed). Others saw traffic earlier still: SecurityWeek reports that “Amazon saw exploitation attempts four days before the patches were released”, and Help Net Security describes the attempt Amazon’s honeypot network recorded on 17 October (SecurityWeek, Help Net Security). SecurityWeek also reports that watchTowr, Hadrian, Patchstack, Cloudflare and Vega observed attempts, and quotes watchTowr saying that “whilst nobody has been successful to date, we don’t expect that will last long”, and BleepingComputer reports Cloudflare’s CTO saying the company was “already observing early attacks” before the patches were released (BleepingComputer).

The indicators ELLIO lists are concrete enough to search for:

• Multipart POSTs with a part named PHP_SESSION_UPLOAD_PROGRESS.
• Multipart boundary strings beginning ----p2s, such as ----p2shell.
• User agents php2shell-scan/109618, php2shell-109618 and php2shell-verify/1.0.
• For the out-of-memory variant, bodies carrying hundreds of empty file fields or field names nested dozens of levels deep, many of them sized at or just over 10 MiB.

So search your web server access logs for multipart POSTs to paths that never take uploads, especially ones carrying that field name or those user agents, and search your PHP error logs for bursts of “Allowed memory size” errors, which is what a worker hitting the out-of-memory path writes. Wiz also lists “unexpectedly large or malformed PHPSESSID response cookies” as an indicator (Wiz Research). If you forward logs to a SIEM, the request bodies themselves are usually not there, so the field name will not be searchable; the user agents, the paths, the sizes and the error bursts will be.

A clean log is not proof of a clean host. Scanners rotate user agents, a memory disclosure read leaves no error behind, and a worker that was corrupted and then served normal requests looks normal. If a host was unpatched and reachable from the internet after the leak on 20 October, the cheapest safe assumption is that its secrets were readable, and rotation costs far less than finding out later that they were.

Frequently asked questions

Is PHP2Shell being exploited in the wild?

Exploitation attempts are confirmed; a confirmed compromise was not public as of 21 October, and you can check whether either CVE has since been added to CISA’s Known Exploited Vulnerabilities catalog. CISA’s alert says it had not observed exploitation at the time of publication, while watchTowr, ELLIO, Hadrian, Patchstack, Cloudflare and Vega all reported attempts hitting their sensors or networks on 21 October, some of them before the fix was published, and SecurityWeek reports that Amazon saw attempts four days before the patches (SecurityWeek). watchTowr’s position was that no attempt had succeeded yet and that it did not expect that to last.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, published with the 21 October 2026 advisory, fix both CVEs. Distribution packages may carry the fix under an older version string, so check the package changelog rather than the output of php -v.

I am on PHP 8.1 or 7.4. What do I do?

The PHP project ships no release for those branches, but its security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source or have no LTS vendor (php.net advisory). Ubuntu has fixed packages for php8.1 on 22.04 and, under Expanded Security Maintenance, for php7.4 and older, and other vendors are backporting. If no backport exists for your runtime, apply the interim measures, isolate the host and plan the upgrade to a supported branch now rather than later.

Is Keycloak affected by PHP2Shell?

No. Keycloak runs on a Java runtime, its getting-started guide asks for OpenJDK (Keycloak, getting started on OpenJDK), not on PHP, so neither a self-hosted cluster nor a managed one needs a PHP patch for these CVEs. The exposure is on the PHP application that trusts Keycloak: its client secret, its users’ sessions and the tokens it holds. Rotation happens in Keycloak, but the vulnerable software is the PHP runtime.

I patched within a few hours. Do I still need to rotate?

For an internet-facing host, we would. Details leaked online on 20 October, ELLIO’s sensors saw exploit traffic from 08:36 UTC on 21 October, Amazon reported attempts four days before the patches (SecurityWeek), and the memory disclosure variant leaves little trace. Rotating a client secret with an overlap window and pushing a not-before time in the realm is an afternoon’s work; discovering a long-lived stolen refresh token later is not.

What to do next

Today, find every PHP host and image, check the running version from inside a web request, and patch anything below 8.2.35, 8.3.36, 8.4.27 or 8.5.12, internet-facing hosts first. Where you cannot patch yet, turn off session upload progress, cap request bodies at the edge, put current WAF rules in front and isolate what remains. Then, host by host as each one comes back patched, regenerate the Keycloak client secret, revoke the sessions that host could have exposed, rotate the application key and the SAML key pair, and watch the Keycloak event log for logins that are not yours.

If you would rather not run the Keycloak side of this yourself, the clusters on Skycloak’s managed hosting come with event webhooks, SIEM export and a WAF as options, and we apply Keycloak security releases to customer clusters while you keep ownership of your realm configuration.

Sources

• PHP, “Critical remote code execution vulnerabilities, update now”, php.net news, 21 October 2026, retrieved 2026-10-22, https://www.php.net/index.php#2026-10-21-5
• PHP, “Security” (php.net security page, with a banner linking the 21 October advisory), retrieved 2026-10-22, https://www.php.net/security
• PHP, GHSA-w8hw-w9fx-j79w, “RCE via OOM corruption”, php/php-src security advisories on GitHub, 21 October 2026, retrieved 2026-10-22, https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• PHP, GHSA-6wmf-4rv5-p3rp, “RCE via stale global state”, php/php-src security advisories on GitHub, 21 October 2026, retrieved 2026-10-22, https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• CVE Program, CVE-2026-109618, CNA record from the PHP Group, published 21 October 2026, retrieved 2026-10-22, https://www.cve.org/CVERecord?id=CVE-2026-109618
• CVE Program, CVE-2026-109619, CNA record from the PHP Group, published 21 October 2026, retrieved 2026-10-22, https://www.cve.org/CVERecord?id=CVE-2026-109619
• PHP, “PHP 8 ChangeLog”, entries for 8.5.12 and 8.4.27, retrieved 2026-10-22, https://www.php.net/ChangeLog-8.php
• PHP, “Supported Versions”, retrieved 2026-10-22, https://www.php.net/supported-versions.php
• PHP, “Session Upload Progress”, PHP manual, retrieved 2026-10-22, https://www.php.net/manual/en/session.upload-progress.php
• PHP, “Sessions: Runtime Configuration”, PHP manual, retrieved 2026-10-22, https://www.php.net/manual/en/session.configuration.php
• NVD, CVE-2026-109618, retrieved 2026-10-22, https://nvd.nist.gov/vuln/detail/CVE-2026-109618
• NVD, CVE-2026-109619, retrieved 2026-10-22, https://nvd.nist.gov/vuln/detail/CVE-2026-109619
• CISA, Known Exploited Vulnerabilities Catalog, retrieved 2026-10-22, https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA, “Critical Vulnerabilities in PHP Require Immediate Patching”, alert, 21 October 2026, retrieved 2026-10-22, https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
• Wiz Research, “PHP2Shell”, Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz, retrieved 2026-10-22, https://www.wiz.io/blog/php2shell-php-rce
• Ubuntu Security, “php2shell (CVE-2026-109618 and CVE-2026-109619)”, retrieved 2026-10-22, https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
• Debian Security Tracker, CVE-2026-109618, retrieved 2026-10-22, https://security-tracker.debian.org/tracker/CVE-2026-109618
• Docker Official Images, php image definition, retrieved 2026-10-22, https://github.com/docker-library/official-images/blob/master/library/php
• ELLIO, “PHP2Shell: what we observed and what to do”, retrieved 2026-10-22, https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do/
• SecurityWeek, “PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors”, Ionut Arghire, 21 October 2026, retrieved 2026-10-22, https://www.securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/
• BleepingComputer, “PHP ships emergency patches for critical PHP2Shell flaws”, Sergiu Gatlan, 21 October 2026, retrieved 2026-10-22, https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/
• Help Net Security, “PHP2Shell: Critical PHP vulnerabilities patched, update now!”, Mirko Zorz, 21 October 2026, retrieved 2026-10-22, https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
• The Hacker News, “PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge”, Swati Khandelwal, 21 October 2026, retrieved 2026-10-22, https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html
• Skycloak, pricing (Web Application Firewall add-on), retrieved 2026-10-22, https://skycloak.io/pricing/
• Keycloak, Server Administration Guide, “Revoking active sessions”, retrieved 2026-10-22, https://www.keycloak.org/docs/latest/server_admin/index.html#_revocation-policy
• Keycloak, Server Administration Guide, “Offline access”, retrieved 2026-10-22, https://www.keycloak.org/docs/latest/server_admin/index.html#_offline-access
• Keycloak, Server Administration Guide, “Confidential client credentials”, retrieved 2026-10-22, https://www.keycloak.org/docs/latest/server_admin/index.html#_client-credentials
• Keycloak, Server Administration Guide, “Client Secret Rotation”, retrieved 2026-10-22, https://www.keycloak.org/docs/latest/server_admin/index.html#_secret_rotation
• Keycloak, Server Administration Guide, SAML client “Keys tab”, retrieved 2026-10-22, https://www.keycloak.org/docs/latest/server_admin/index.html#keys-tab
• Keycloak, Server Administration Guide, “Event types”, retrieved 2026-10-22, https://www.keycloak.org/docs/latest/server_admin/index.html#event-types
• Keycloak, Server Administration Guide, “Using a vault to obtain secrets”, retrieved 2026-10-22, https://www.keycloak.org/docs/latest/server_admin/index.html#_vault-administration
• Keycloak, Release notes, “Client Secret Rotation (supported)”, retrieved 2026-10-22, https://www.keycloak.org/docs/latest/release_notes/index.html#client-secret-rotation-supported
• Keycloak, “Getting started on OpenJDK”, retrieved 2026-10-22, https://www.keycloak.org/getting-started/getting-started-zip
• Laravel, “Encryption: Gracefully Rotating Encryption Keys”, Laravel 12.x documentation, retrieved 2026-10-22, https://laravel.com/docs/12.x/encryption#gracefully-rotating-encryption-keys