Critical PHP Flaws: How to Update PHP 8.3, 8.4 and 8.5

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.

PolicyMaker: A Lightweight PHP Tool to Create Privacy Policy Pages for Android Apps

PolicyMaker is a lightweight web application for creating, managing, publishing, and displaying privacy policies for Android mobile applications. It is built using PHP and SQLite, so it does not need a heavy database server or complex deployment setup. The project is available on GitHub – https://github.com/mypapit/policymaker

PolicyMaker Dashboard

PolicyMaker Wizard

The main idea behind PolicyMaker is simple. Many Android developers need a public privacy policy page, especially when publishing applications to app stores. Instead of manually writing and formatting the same policy structure again and again, PolicyMaker provides an administrator-only wizard that helps generate structured privacy policy text from simple inputs.

The wizard supports yes/no choices, radio buttons, checkboxes, and text fields. It can collect details such as application name, package name, website, effective date, personal data collection, analytics, advertising, permissions, service providers, data retention, security, user rights, and children’s privacy.

PolicyMaker is useful for small developers, indie Android publishers, educators, and small organizations that manage several simple mobile apps. It is not meant to be a large enterprise compliance platform. Its strength is that it is small, direct, and easy to host. It only requires PHP 8.3 or newer with SQLite/PDO SQLite support. The installer creates the SQLite database and generates the first administrator password.

The public policy pages also include Schema.org JSON-LD metadata, which helps make the policy page more structured for search engines

PolicyMaker is licensed under the BSD 2-Clause license. This makes it practical for developers who want a small self-hosted privacy policy system that can be modified and deployed with minimal restriction.

This blog now runs on PHP 7!

Hi all,

I’m proud to announce to all the after several tinkering, this blog now runs on PHP 7 ! PHP 7 is the latest iteration of the popular general-purpose scripting language that is suited to web development.

PHP7 is touted to perform up to TWO TIMES faster than PHP5.

Here are the performance benchmark run by Kinsta has shown that PHP7 has significantly improved performance when compared to PHP 5.6.


  • WordPress 4.3.1 HHVM RepoAuthoritative benchmark result: 375.48 trans/sec
  • WordPress 4.3.1 HHVM benchmark result: 357.69 trans/sec
  • WordPress 4.3.1 PHP 7.0 benchmark result: 306.24 trans/sec
  • WordPress 4.3.1 PHP 5.6.16 benchmark result: 106.45 trans/sec

* Retrieved from Kinsta: The Definitive PHP 7.0 & HHVM Benchmark

Next I’ll update you with the guide on howto run and execute PHP7 and PHP5 side-by-side to cater for multiple websites.

Stay tuned, and expect more posts and updates from this venerable blog anyday now :p

Easyrec – Integrate Recommender Engine in your website – open source

Easyrec is an open source recommender engine which can be trained and customized to provide personalized recommendations using REStful Web Service.

easyrec-engine
Easyrec exposes its functionality through REST API which provides several interaction types:

Actions

  1. view
  2. buy
  3. sendaction

Recommedations

  1. other users also viewed
  2. other users also bought
  3. items rated good by other users
  4. recommendations for user
  5. related items
  6. action history for user

Community Rankings

  1. most viewed items
  2. most bought items
  3. most rated items
  4. best rated items
  5. worst rated items

The list of recommendations is returned in XML and JSON notation to be further processed by your web application.

Easyrec API can be accessed from its main website http://easyrec.org/ or could be installed alongside with the web application on your own server. Easyrec require at least Java 1.5 and MySQL server for its functionality.

Download easyrect from: http://easyrec.org/recommendation-engine

How to Optimize and speed up PHP with OPCache

PHP 5.5 and 5.6 comes with OPCache. OPCache speeds up PHP execution by storing precompile bytecode of PHP in shared memory. Taking advantage of fast memory operations compared to hard disk operation, OPCache eliminates the process of having to read PHP scripts from the disk each time whenever a script must be executed.

In short, OPCache saves the time needed to serve PHP-powered websites!

How to enable OPCache?
This tutorial is written from Ubuntu 14.04 LTS standpoint – using php5-fpm, but it should also work for other Linux distro.

  1. First edit ‘/etc/php5/fpm/php.ini‘ file.
  2. Find “opcache” section in the PHP ini.
  3. Uncomment and change opcache.enable to opcache.enable=1
  4. Do the same for >opcache.memory_consumption, changed its value from 64 to 128 (or 256)
  5. Change opcache.interned_strings_buffer from 4 to 16
  6. Changed the opcache.max_accelerated_files to 8192

Activate OPCache with php5enmod command.

sudo php5enmod opcache

Save file and restart php5-fpm.

sudo service php5-fpm restart

PHP OPCache should be running on your server now. Here’s a reference of /etc/php/fpm/php.ini file in Ubuntu 14.04 LTS.

[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=1

; Determines if Zend OPCache is enabled for the CLI version of PHP
opcache.enable_cli=0

; The OPcache shared memory storage size.
opcache.memory_consumption=128

; The amount of memory for interned strings in Mbytes.
opcache.interned_strings_buffer=16

; The maximum number of keys (scripts) in the OPcache hash table.
; Only numbers between 200 and 100000 are allowed.
opcache.max_accelerated_files=8192

BONUS: How to verify whether PHP OPCache is running ??
You can verify whether OPCache is running by using opcache-status by Rasmus Lerdorf. Just drop the script in one of your web directory and browse. If you’re not a Git fan, I’ve also have taken the liberty of mirroring the download: opcache-status.zip

opcache-status screenshot
opcache-status-ss

How to convert between sqlite2 and sqlite3 database

Here’s a short guide on how to convert between sqlite2 to sqlite3 database file:

sqlite2 /path/to/mysqlite2.db .dump > backupfile
sqlite3 /path/to/mynewsqlite3.db < backupfile

Using the same method, you can convert sqlite3 db to sqlite2 db too!

p/s: Why you need to convert? because embedded device (read: iPhone and Android) only supports sqlite3 database, while PHP 5 by default supports sqlite2 database.

Thus, this method provide a convenient way to convert between the two different version of sqlite db format.

Recommended Reading