Tag: hacking

Updated 22 October 2026. Commands below target Ubuntu/Debian package installations.

PHP has released emergency fixes for CVE-2026-109618 and CVE-2026-109619, both rated critical at CVSS 9.2. They can allow unauthenticated remote code execution. One involves unsafe out-of-memory cleanup; the other involves stale internal state across requests. Apache mod_php has a demonstrated attack before application code runs. PHP-FPM also requires patching. See the official announcement.

1. Check and update PHP

Back up your database, application files and configuration. Identify every runtime:

php -v
php --ini
dpkg -l 'php*' 'libapache2-mod-php*'

The CLI version may differ from the website. Check each virtual host, FPM pool, container and hosting panel.

Branch	First fixed upstream version
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Install these or later supported security releases. For PHP 8.3-FPM:

sudo apt update
apt-cache policy php8.3-common php8.3-fpm
sudo apt upgrade
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm

Substitute 8.4 or 8.5 for your installed branch. Review package upgrades, including extensions. If Apache uses mod_php:

sudo apache2ctl configtest
sudo systemctl restart apache2

Check vendor backports. Ubuntu fixes include 8.3.6-0ubuntu0.24.04.13 for 24.04 and 8.5.4-0ubuntu1.5 for 26.04. Compare complete revisions against Ubuntu’s security notice. Other repositories need their own advisories. An older-looking version can contain the fix.

Confirm the web runtime afterward and test login, uploads and database access. Updating WordPress or OJS alone does not update PHP.

2. Update containers separately

Host updates do not patch container PHP. Confirm a patched image exists, then replace app with your Compose service:

docker compose pull app
docker compose up -d --no-deps app
docker compose exec app php -v

Custom images require an updated base image and rebuild. Preserve persistent data. Shared-hosting users should request the exact patched revision.

3. Limit requests before PHP

In Nginx’s relevant server block:

client_max_body_size 8m;

Or inside the Apache virtual host:

LimitRequestBody 8388608

See the Nginx and Apache documentation. These impose an 8 MiB body limit. Adjust for legitimate uploads. In the active web runtime’s php.ini:

post_max_size = 8M
upload_max_filesize = 6M
max_file_uploads = 5
max_input_vars = 1000
max_input_nesting_level = 32
session.upload_progress.enabled = 0

Typical Ubuntu paths are /etc/php/8.3/fpm/php.ini for FPM and /etc/php/8.3/apache2/php.ini for mod_php. Adjust the branch number. php --ini reports CLI configuration only.

Test these example values. Disable file uploads if unused. Apply upload-progress settings at startup, then restart workers; application code and FPM .user.ini are too late for the confirmed early path.

Test Nginx with sudo nginx -t before reloading, or Apache with sudo apache2ctl configtest. These limits reduce exposure; they do not fix either CVE.

4. Emergency mitigation while patching

Prefer removing public PHP access and serving a static maintenance page. A PHP maintenance plugin still invokes PHP.

The OOM advisory recommends this incomplete emergency measure in the relevant FPM pool, such as /etc/php/8.3/fpm/pool.d/www.conf:

php_admin_value[memory_limit] = -1

This removes one controllable OOM trigger but permits unlimited per-request PHP memory, increasing denial-of-service risk. Use frontend limits and suitable cgroup/container boundaries. Underlying allocation failures remain dangerous; do not substitute RLIMIT_AS or RLIMIT_DATA. Audit overrides and restart all workers. Restore suitable finite PHP limits after patching.

For PHP 8.5, also set fatal_error_backtraces=0 in startup configuration. Remove invalid or obsolete per-request INI settings. These address specific stale-state paths only. Hiding warnings provides no protection.

5. Retire public PHP 7.4 applications

PHP 7.4 reached upstream end of life on 28 November 2022. Retire unused applications or migrate them to supported PHP. Legacy source patches and vendor fixes exist, but require explicit verification and should support temporary migration arrangements.

Remove forgotten subdomains, restrict administration through VPN/access policies, and keep FPM off public port 9000. Review logs, unexpected files, accounts and scheduled tasks. Patching does not remove existing backdoors. If compromise is suspected, isolate the system and preserve evidence. Follow NCSC guidance.