/// article

PHP2Shell Hands-On Lab: Testing CVE-2026-109618 and CVE-2026-109619 in a Controlled Linux Environment

By lordfrancs3

On October 21, 2026, the PHP development team released emergency security updates addressing two critical vulnerabilities collectively known as PHP2Shell. The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, both received CVSS v4.0 scores of 9.2. Under documented conditions, unauthenticated attackers can exploit these flaws to execute arbitrary code with the privileges of a PHP web worker. These vulnerabilities are especially concerning because they affect PHP’s internal request handling rather than a particular PHP application. Updating WordPress, Laravel, or another PHP-based application alone does not resolve the underlying problem. The PHP maintainers have confirmed remote code execution against Apache mod_php. They have also documented different exploitation conditions affecting PHP-FPM and other PHP execution environments. In this guide, we will examine the vulnerabilities, create an isolated Linux laboratory, inspect an affected PHP release, compare it against a patched release, and learn how to distinguish an affected runtime from evidence of actual exploitation. The objective is to understand the security implications using repeatable technical checks rather than treating every error, crash, or outdated version as proof of successful exploitation. 1. Understanding PHP2Shell PHP2Shell refers to two distinct memory-management vulnerabilities in PHP. Although both can result in remote code execution, they involve different internal mechanisms. Vulnerability Description CVSS v4.0 CVE-2026-109618 Remote code execution through out-of-memory corruption 9.2, Critical CVE-2026-109619 Remote code execution through stale global state and use-after-free 9.2, Critical Both vulnerabilities can affect PHP applications that process incoming HTTP requests. However, the exploitation requirements differ depending on the PHP version, execution environment, installed extensions, and application behavior. CVE-2026-109618: Out-of-Memory Corruption PHP uses internal memory-management routines to allocate and release memory while processing requests. When memory allocation fails, PHP must interrupt the current operation and handle the error safely. The vulnerability occurs because PHP’s out-of-memory handling can interrupt execution while some internal request data is only partially initialized. The affected implementation uses longjmp() to escape from certain out-of-memory conditions. When this happens at an unsafe point, the request shutdown procedure may later operate on invalid internal state. The PHP security advisory confirms that the resulting corruption can lead to remote code execution. This behavior is particularly significant under Apache mod_php because request shutdown can occur even when initialization fails before the application’s PHP code begins executing. Official advisory: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w CVE-2026-109619: Stale Global State The second vulnerability involves internal PHP state that remains accessible after the memory backing that state has been released. A PHP worker may process multiple HTTP requests during its lifetime. Certain internal values belong to one request and must be cleared before another request is handled. If PHP fails to reset such values correctly, a later request may access memory that has already been freed. This is known as a use-after-free vulnerability. The PHP maintainers describe situations where fatal errors, session handling, initialization diagnostics, or extension behavior can leave behind state that should no longer be accessible. Successful exploitation generally requires an operation that leaves stale state behind and a later operation that accesses that state. The maintainers confirmed remote code execution through specific request-lifecycle paths, including a session-related path affecting both mod_php and PHP-FPM. Official advisory: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp 2. Which PHP Versions Are Vulnerable? According to the official PHP security advisories, the following upstream PHP releases require updates. PHP branch Affected upstream versions First patched version PHP 8.2 Before 8.2.35 8.2.35 PHP 8.3 Before 8.3.36 8.3.36 PHP 8.4 Before 8.4.27 8.4.27 PHP 8.5 Before 8.5.12 8.5.12 Older PHP branches require separate consideration because some distributions continue maintaining packages after upstream support ends. For example, Ubuntu may distribute a package labeled PHP 8.3.6 while incorporating fixes backported from newer PHP releases. Therefore, administrators should examine both the PHP version and the security status of the package supplied by their distribution. A version string alone does not always establish whether a distribution-maintained package is vulnerable. Official PHP announcement: https://www.php.net/archive/2026.php#2026-10-21-5 3. What Has Been Confirmed About Exploitation? Before setting up the laboratory, it is important to distinguish confirmed exploitation from theoretical exposure. The official PHP advisories provide the following findings. Environment CVE-2026-109618 CVE-2026-109619 Apache mod_php RCE demonstrated over HTTP RCE demonstrated PHP-FPM Susceptible code paths identified, but no complete FPM exploit demonstrated for this CVE Session-lifecycle RCE demonstrated under suitable application conditions FrankenPHP Application-independent exposure considered likely from source analysis Depends on the relevant state lifecycle LiteSpeed LSAPI Application-specific exposure considered likely but not validated for this CVE Depends on application and runtime conditions The differences matter. A proof of concept demonstrated under Apache mod_php should not automatically be presented as evidence of successful exploitation under PHP-FPM. Similarly, reproducing a memory allocation error does not necessarily demonstrate the vulnerable memory state required for remote code execution. For this laboratory, we will use Apache mod_php as the primary reference environment because the PHP maintainers have confirmed successful exploitation under that configuration. 4. Preparing the Laboratory We will use Docker to maintain two separate PHP environments. The first will contain PHP 8.4.26, an affected upstream release. The second will contain PHP 8.4.27, the first patched release in the same branch. Both environments will use Apache mod_php. Laboratory requirements A Linux host or Linux virtual machine Docker Engine installed and running Internet access for downloading official PHP source archives during the build At least 4 GB of available RAM recommended for compiling PHP Sufficient free disk space for Docker images and compilation A terminal with curl and standard Linux utilities Security warning: The affected PHP version must run only inside an isolated, authorized test environment. Do not publish its HTTP port on a public interface, connect it to production data, or use a production server for this laboratory. The Docker examples bind HTTP ports to 127.0.0.1. For stronger isolation, perform the entire exercise inside a disposable virtual machine with no inbound access from external networks. Step 1: Create the project directory Create a working directory: mkdir -p ~/php2shell-lab/site cd ~/php2shell-lab Our working directory will contain: php2shell-lab/ ├── Dockerfile └── site/ └── runtime.php Step 2: Create the Dockerfile We will build PHP directly from its official source archives so that the laboratory uses exact upstream versions. Create a file named Dockerfile: FROM debian:bookworm-slim ARG PHP_VERSION ARG PHP_SHA256 RUN apt-get update && \ apt-get install -y --no-install-recommends \ apache2 \ apache2-dev \ build-essential \ ca-certificates \ curl \ libxml2-dev \ libsqlite3-dev \ pkg-config \ xz-utils && \ rm -rf /var/lib/apt/lists/* RUN set -eux; \ curl -fsSLo /tmp/php.tar.xz \ "https://www.php.net/distributions/php-${PHP_VERSION}.tar.xz"; \ echo "${PHP_SHA256} /tmp/php.tar.xz" | sha256sum -c -; \ mkdir -p /usr/src/php; \ tar -xJf /tmp/php.tar.xz \ -C /usr/src/php --strip-components=1; \ cd /usr/src/php; \ ./configure \ --with-apxs2=/usr/bin/apxs2 \ --disable-phpdbg \ --disable-cgi \ --without-pear; \ make -j2; \ make install; \ cp php.ini-production /usr/local/lib/php.ini; \ rm -rf /tmp/php.tar.xz /usr/src/php RUN a2dismod mpm_event && \ a2enmod mpm_prefork && \ printf '%s\n' \ '<FilesMatch "\.php$">' \ ' SetHandler application/x-httpd-php' \ '</FilesMatch>' \ > /etc/apache2/conf-available/php-lab.conf && \ a2enconf php-lab COPY site/ /var/www/html/ EXPOSE 80 CMD ["apache2ctl", "-D", "FOREGROUND"] This image uses Debian’s Apache installation and compiles PHP with its Apache module interface. The exact PHP version and the expected archive checksum are supplied during the build. Checksum verification helps prevent an incorrect or modified source archive from being used accidentally. Build note: Source compilation can require environment-specific dependencies or adjustments. Confirm the resulting Apache module and PHP version before treating the image as a valid reference environment. The steps below establish runtime and patch verification, not independent proof of RCE. Step 3: Create the runtime inspection script Create site/runtime.php: <?php header('Content-Type: application/json'); echo json_encode([ 'php_version' => PHP_VERSION, 'sapi' => PHP_SAPI, 'worker_pid' => getmypid(), 'memory_limit' => ini_get('memory_limit'), 'upload_progress' => ini_get( 'session.upload_progress.enabled' ) ], JSON_PRETTY_PRINT); This script displays information about the PHP runtime handling an HTTP request. It does not contain an exploit payload. Its purpose is to confirm that Apache executes PHP and to inspect relevant runtime settings. 5. Building the Affected PHP Environment We will first compile PHP 8.4.26. The SHA-256 checksum below corresponds to the official PHP 8.4.26 .tar.xz source archive. Run: docker build \ --build-arg PHP_VERSION=8.4.26 \ --build-arg PHP_SHA256=32a2de53862ad44ed4a5005244ce4f1b50c271e74dced215449a4443b40569f1 \ -t php2shell:affected . The image build will download and compile PHP from source. After the build completes, check the installed version: docker run --rm \ php2shell:affected php -v The reported version should identify PHP 8.4.26. If it reports a different version, stop and investigate before continuing. Now start the Apache container: docker run -d \ --name php2shell-affected \ --memory=512m \ -p 127.0.0.1:8081:80 \ php2shell:affected The local laboratory endpoint is: http://127.0.0.1:8081/runtime.php Verify the response: curl -fsS http://127.0.0.1:8081/runtime.php The response should contain a JSON object identifying PHP 8.4.26, the Apache SAPI, and the active worker’s process ID. Verify Apache’s loaded modules: docker exec php2shell-affected \ apache2ctl -M Confirm that the PHP module is loaded and that Apache uses the prefork MPM. This step is important because a CLI PHP version does not establish which PHP runtime serves HTTP traffic. An installation can contain multiple PHP versions or different execution environments. 6. Understanding the Request Lifecycle The vulnerabilities involve PHP’s request initialization, state management, and shutdown behavior. Under Apache mod_php, the PHP interpreter operates within Apache worker processes. The simplified request lifecycle is: Incoming HTTP request | v Apache worker receives request | v PHP request initialization | v Request parsing and PHP execution | v PHP request shutdown | v Worker remains available for subsequent requests CVE-2026-109618 concerns certain unsafe exits from memory allocation failures during request processing. CVE-2026-109619 concerns internal state that can remain accessible after request-owned memory is released. Observing PHP worker behavior We can inspect the worker process handling each ordinary request. Execute: for i in $(seq 1 10); do curl -fsS \ http://127.0.0.1:8081/runtime.php echo done Observe the worker_pid values. Depending on Apache’s scheduling behavior, different requests may be handled by different workers. The same worker may also appear in multiple responses. Worker reuse is normal behavior. It is relevant to CVE-2026-109619 because the demonstrated stale-state mechanism requires the relevant operations to occur in requests handled by the same worker. However, worker reuse alone is not evidence of memory corruption or successful exploitation. The exercise establishes a runtime property. It does not trigger or prove the reported use-after-free vulnerability. Inspecting the configuration Run: docker exec php2shell-affected \ php -i | grep -E \ 'memory_limit|post_max_size|session.upload_progress' These settings are relevant to the attack surfaces described by the maintainers. Pay attention to: memory_limit, which controls normal PHP memory consumption. post_max_size, which limits submitted request body sizes. session.upload_progress.enabled, which controls a session-related feature relevant to documented exploitation paths. Configuration values help describe the environment, but they cannot independently establish whether a vulnerability has been exploited. Remember that the command above reads PHP’s CLI configuration. Confirm request-time values separately using the HTTP script. 7. Examining CVE-2026-109618 The first vulnerability involves PHP’s response to certain out-of-memory conditions. The critical issue is not simply that a PHP process can run out of memory. A normal memory exhaustion error is not automatically a security vulnerability. The problem arises when an allocation failure interrupts execution while internal request data is in an unsafe state. Under affected Apache mod_php configurations, PHP may proceed into shutdown handling that operates on invalid state. The maintainers confirmed that this behavior could be exploited over HTTP without requiring a vulnerability in the application’s own PHP code. What the laboratory establishes At this point, the following properties can be checked: PHP 8.4.26 is installed. Apache executes PHP through mod_php. HTTP requests reach the expected PHP runtime. Relevant runtime configuration values can be inspected. The installed PHP release falls within the upstream affected range. These checks establish the laboratory’s exposure characteristics. They do not independently establish that an out-of-memory request has caused the particular memory corruption described in CVE-2026-109618. A valid vulnerability reproduction would require evidence linking the observed failure to the documented unsafe memory state, rather than merely recording an HTTP error or terminated worker. The PHP maintainers have already confirmed the RCE impact for this vulnerability under Apache mod_php. Source: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w 8. Examining CVE-2026-109619 The second vulnerability involves memory references that survive longer than they should. Consider a PHP worker that handles two separate HTTP requests. During the first request, PHP may store internal state that points to request-owned memory. If that state is not cleared before the memory is released, the worker may retain an invalid reference. When another request reaches the same worker, certain operations can access that reference before normal initialization replaces it. This can result in a use-after-free condition. The official advisory identifies multiple possible state families, including error handling and session lifecycle operations. Why ordinary worker reuse is relevant Unlike a vulnerability that can be completed entirely within one request, the confirmed stale-state scenarios involve operations spanning request boundaries. The producing and consuming operations must reach the same worker. The affected behavior can therefore depend on: Whether a worker processes multiple requests. The order of request operations. Whether particular errors or state transitions occur. The application’s behavior and PHP extensions. Whether the required operations occur before internal state is reset. Simply enabling sessions or making repeated requests is insufficient to prove exploitation. PHP-FPM is a separate case The official advisory confirms session-lifecycle RCE under PHP-FPM in a suitable application configuration. However, the same advisory explains that PHP-FPM handles some startup failures differently from Apache mod_php. An Apache reproduction should therefore not be presented as a universal PHP-FPM exploit. Source: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp 9. Building the Patched PHP Environment Next, we will build PHP 8.4.27. This is the first upstream PHP 8.4 release containing the security fixes for both vulnerabilities. The following checksum comes from the PHP project’s release information. docker build \ --build-arg PHP_VERSION=8.4.27 \ --build-arg PHP_SHA256=dcf93923b0e38e0d5252b25b796520b5a47761a08b3488b6d0b5d1115764d3f0 \ -t php2shell:patched . Verify the version: docker run --rm \ php2shell:patched php -v The reported version should be PHP 8.4.27. Start the patched environment: docker run -d \ --name php2shell-patched \ --memory=512m \ -p 127.0.0.1:8082:80 \ php2shell:patched The patched environment is accessible at: http://127.0.0.1:8082/runtime.php Run: curl -fsS http://127.0.0.1:8082/runtime.php Verify that the reported PHP version is 8.4.27. Also confirm the loaded Apache module: docker exec php2shell-patched \ apache2ctl -M Both environments should use the same general Apache execution model. The primary variable we intend to compare is the upstream PHP patch level. 10. Comparing the Two Environments We now have two independent PHP environments. Property Affected environment Patched environment PHP version 8.4.26 8.4.27 Web server Apache Apache Execution model mod_php mod_php CVE-2026-109618 Affected upstream release Patched upstream release CVE-2026-109619 Affected upstream release Patched upstream release HTTP inspection port 127.0.0.1:8081 127.0.0.1:8082 Run the following commands: echo "Affected runtime:" curl -fsS \ http://127.0.0.1:8081/runtime.php echo echo "Patched runtime:" curl -fsS \ http://127.0.0.1:8082/runtime.php Compare the PHP version, SAPI, and configuration values. The expected security distinction comes from the official PHP release information: 8.4.26 precedes the fixes, while 8.4.27 contains them. Ordinary requests may behave identically on both versions. That is not a failure of the patch comparison. The patches address exceptional internal conditions rather than changing the normal behavior of a simple PHP script. Reviewing Apache logs Inspect logs from the affected environment: docker logs --timestamps \ php2shell-affected Compare with the patched environment: docker logs --timestamps \ php2shell-patched During controlled vulnerability research, logs may help correlate HTTP requests with runtime errors, worker termination, and service restarts. However, neither a PHP warning nor an unexpected process exit proves that one of these CVEs was successfully exploited. Reliable attribution requires a corresponding technical explanation and supporting evidence. 11. How Should Exploit Results Be Interpreted? The distinction between exposure, vulnerability reproduction, and remote code execution is important. Observation What it establishes An affected upstream PHP version is installed Version-based exposure Apache mod_php is active The relevant execution environment An ordinary HTTP request succeeds The PHP application is reachable PHP reports a memory allocation error An allocation or memory-limit failure occurred An Apache worker crashes A worker experienced a failure Debugging shows the documented invalid memory condition Evidence of vulnerability reproduction Controlled evidence demonstrates attacker-directed command execution through the CVE Evidence of successful RCE A process crash can have many causes. An HTTP 500 response can occur because of application errors, permissions, misconfiguration, or resource exhaustion. These symptoms should not automatically be attributed to PHP2Shell. When evaluating a published PoC, examine whether it relies on an additional application vulnerability. For example, a demonstration that also requires an intentionally vulnerable file-inclusion endpoint does not establish that the same exploit works against an arbitrary PHP application. The PHP core vulnerabilities and additional application weaknesses must be distinguished. 12. Checking Production Ubuntu Servers The laboratory uses upstream PHP releases. Production Ubuntu systems often use distribution-maintained packages. Canonical released security fixes for PHP2Shell on October 21, 2026. According to Canonical, the following Ubuntu packages contain fixes. Ubuntu release PHP version Fixed package version Ubuntu 20.04 LTS PHP 7.4 7.4.3-4ubuntu2.29+esm5 Ubuntu 22.04 LTS PHP 8.1 8.1.2-1ubuntu2.28 Ubuntu 24.04 LTS PHP 8.3 8.3.6-0ubuntu0.24.04.13 Ubuntu 26.04 LTS PHP 8.5 8.5.4-0ubuntu1.5 Ubuntu 26.10 PHP 8.5 8.5.9-0ubuntu2.1 Ubuntu 20.04 and older releases require the relevant Extended Security Maintenance entitlement for these fixes. Other Linux distributions may publish patches under their own package versioning schemes. Identify installed PHP packages Run: php -v List installed PHP packages: dpkg -l | grep -E \ '^ii (php[0-9.]|libapache2-mod-php)' Inspect package candidates: apt-cache policy php8.3-common For systems using another PHP branch, adjust the package name accordingly. Identify PHP-FPM services: systemctl list-units --all \ 'php*-fpm.service' On an Apache server, check whether mod_php is active: apache2ctl -M | grep php A PHP runtime may be present even if the command-line interpreter reports another version. Check the actual PHP handler used by each hosted application. Canonical’s official advisory: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available 13. Applying the Security Updates For Ubuntu systems using supported security repositories, refresh the package lists: sudo apt update Upgrade installed packages: sudo apt upgrade Review the proposed package changes before confirming the upgrade, especially on production servers hosting several applications. After upgrading, restart the affected PHP service. For PHP-FPM: sudo systemctl restart php8.3-fpm For Apache mod_php: sudo systemctl restart apache2 Adjust the service name to match your actual PHP version. If the PHP runtime is running inside containers, replace the affected container image and recreate the containers rather than relying on changes made inside an existing container. For production systems, verify application compatibility, confirm that the updated runtime is serving traffic, and perform normal service health checks. Confirm the update On Ubuntu, inspect the installed package version: dpkg-query -W php8.3-common Check the available package: apt-cache policy php8.3-common Compare the installed version against the fixed release published by your distribution. For an upstream PHP installation, confirm that it runs at least the patched release for the relevant branch. Remember that an Ubuntu backport can retain an older upstream PHP version string while containing the security fix. 14. Temporary Mitigations The PHP security team has stated that upgrading is the only complete mitigation. Temporary configuration changes may reduce exposure, but administrators should not treat them as permanent replacements for the security patches. For CVE-2026-109618, the upstream advisory describes disabling PHP’s predictable per-request memory limit as a temporary way to remove one confirmed exploitation condition. However, setting: memory_limit = -1 also removes PHP’s normal per-request memory ceiling. That can create serious availability risks and should not be applied casually, particularly on shared or production hosting systems. For CVE-2026-109619, disabling session upload progress can reduce exposure to specific documented exploitation paths: session.upload_progress.enabled = 0 The setting must be applied at the appropriate startup configuration level and the affected workers restarted. It does not address every stale-state path. Other protections include reducing unnecessary request features, controlling upload sizes, reviewing application errors, limiting worker permissions, and restricting access to sensitive server resources. These are defense-in-depth measures. They do not replace the patches. 15. What About NGINX, WordPress, and Laravel? PHP2Shell is a PHP runtime issue. Applications do not need to contain their own vulnerable PHP code to be affected by the underlying conditions described in the advisories. That includes websites built with WordPress, Laravel, Drupal, or custom PHP frameworks. The precise exploitation conditions still depend on the PHP runtime and application behavior. NGINX with PHP-FPM NGINX normally passes PHP requests to a PHP-FPM service rather than loading the interpreter directly into the web server. The official advisories distinguish PHP-FPM’s request lifecycle from Apache mod_php. This changes some exploitation conditions, but it does not make an unpatched PHP-FPM environment safe. WordPress Updating WordPress core, themes, and plugins remains important. However, PHP2Shell is not resolved merely by installing the latest WordPress version. The PHP interpreter used by WordPress must also receive the appropriate security patch. Laravel and custom applications The same principle applies to Laravel and custom PHP websites. Administrators should identify the runtime actually serving requests, verify the installed package or compiled version, and confirm that affected workers have been restarted after updating. 16. Monitoring for Suspicious Activity Because these vulnerabilities can affect internal memory handling, administrators should not expect one universal log signature that proves attempted exploitation. Useful evidence may include correlated request activity, repeated PHP errors, unexpected worker termination, unusual process behavior, or unauthorized actions performed under the web worker account. Individual observations can have legitimate explanations. For example, a PHP worker restarting does not prove exploitation. Neither does a suspicious filename found under a temporary directory. Investigators should correlate process behavior, access logs, application logs, timestamps, system events, and available memory diagnostics. If a production server is suspected to have been compromised, preserve evidence before deleting suspicious files or restarting services unnecessarily. For a practical introduction to this investigation process, see our related PinoyLinux article: How to Investigate Suspicious Processes and Files on a Linux Server Our earlier investigation of a compromised Zimbra server also demonstrates why suspicious files, processes, and persistence mechanisms should be evaluated together: How We Investigated a Compromised Zimbra Mail Server on Ubuntu These are general incident-response references, not evidence of PHP2Shell exploitation in those incidents. 17. Laboratory Cleanup After completing the exercise, stop and remove the two containers: docker stop \ php2shell-affected \ php2shell-patched docker rm \ php2shell-affected \ php2shell-patched Remove the laboratory images: docker image rm \ php2shell:affected \ php2shell:patched Check that the containers are no longer running: docker ps If the laboratory was created inside a disposable virtual machine, shut down or destroy that VM after retaining any required sanitized test evidence. Do not leave the affected PHP environment running after the exercise. 18. Technical Scope and Limitations This article draws on official PHP security advisories, verified upstream release information, and documented exploitation research. The laboratory procedures focus on identifying affected runtimes, examining their execution environment, observing normal request handling, and comparing vulnerable and patched PHP releases. The ordinary HTTP requests shown in this guide do not constitute an RCE proof of concept. The PHP maintainers have independently confirmed successful exploitation under specific conditions, including Apache mod_php and certain PHP-FPM session-lifecycle scenarios. Other combinations of PHP versions, application behavior, extensions, and execution environments may produce different results. A successful demonstration in one environment should not be generalized to all PHP installations without supporting evidence. For security research, conclusions must be based on the actual observed behavior and the conditions under which it occurred. 19. Key Lessons for Linux Administrators PHP2Shell demonstrates why keeping application code updated is only one part of maintaining a secure Linux web server. The PHP interpreter itself has a significant security role because it processes incoming requests, manages memory, handles application state, and interacts with operating system resources. The official findings establish that vulnerabilities within that runtime can result in remote code execution under documented conditions. Administrators should therefore identify the actual PHP runtimes used by their applications, install the appropriate upstream or vendor security updates, restart affected workers, and verify their package status. For researchers, it is equally important to distinguish a vulnerable software version from a successfully reproduced memory corruption condition, and a memory corruption condition from demonstrated remote code execution. The most useful security research makes those distinctions clear. References The following primary sources provide the vulnerability descriptions, technical limitations, and patch information used in this article. PHP Project, Critical RCE Security Advisory, October 21, 2026 https://www.php.net/archive/2026.php#2026-10-21-5 CVE-2026-109618, RCE via Out-of-Memory Corruption https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w CVE-2026-109619, RCE via Stale Global State https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp Official PHP Downloads and Release Checksums https://www.php.net/downloads.php Canonical, PHP2Shell Vulnerability Fixes Available https://ubuntu.com/blog/php2shell-vulnerability-fixes-available Official PHP Docker Build Reference https://github.com/docker-library/php

[object Object]