Critical PHP Vulnerability: PHP2Shell
1. Security overview
Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affect PHP's core runtime. They have been associated with the name PHP2Shell and carry a CVSS v4.0 severity score of 9.2. Successful exploitation could enable remote code execution without authentication or expose sensitive process memory.
2. Potential business impact
Remote code execution: Attackers may execute commands under the privileges of the PHP process.
Sensitive data exposure: Process memory may contain credentials, session information, API keys or other secrets.
Application compromise: Websites, APIs and PHP-based applications could be affected.
Further system compromise: An attacker may attempt to move laterally or access other systems, depending on permissions and network controls.
These are potential impacts, not confirmation that every vulnerable server has been compromised
3. Which systems require attention?
The PHP project identifies web-facing installations using PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as potentially affected. Apache mod_php is highlighted as particularly concerning because an exploit may trigger the vulnerability before application code runs.
Other products may bundle PHP internally, including containers, content management systems and network appliances. Check vendor advisories rather than assuming that a product is safe because you do not manage PHP directly.
4. Fixed PHP versions
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35
These releases were published on 21 October 2026. PHP 8.1 and older are no longer supported by the upstream PHP project; check whether your operating-system vendor supplies a backported fix or plan an upgrade to a supported branch.
5. Recommended incident-response actions
1. Inventory: Identify PHP versions across production servers, containers, websites and appliances.
2. Prioritize: Patch internet-facing services first.
3. Remediate: Install the appropriate security update and restart or redeploy affected runtimes.
4. Verify: Confirm that the running PHP workers and container images use patched code.
5. Investigate: Review web server, application and endpoint logs for suspicious requests, unexpected processes, modified files and unusual outbound connections.
6. Contain: If immediate patching is impossible, consider isolating exposed applications from public networks until remediation is complete.
Check logs for suspicious activity:
sudo journalctl --since "24 hours ago" | grep -Ei 'php|segfault|out of memory|oom'
For Ubuntu/Debian Apache:
sudo tail -n 200 /var/log/apache2/error.log
For Nginx:
sudo tail -n 200 /var/log/nginx/error.log
Detect your Oracle Linux / Rocky / RHEL environment:
cat /etc/os-release
uname -r
php -v
command -v php
php-fpm -v 2>/dev/null
rpm -qa | grep -Ei '^(php|php-fpm|php83|php8[0-9])'
dnf module list php
Check which PHP-FPM service is active and which binary it runs:
sudo systemctl --type=service --all | grep -i php
sudo systemctl status php-fpm --no-pager
sudo nginx -T 2>&1 | grep -nE 'fastcgi_pass|php-fpm'
Comments
Post a Comment