DEV Community: softjapan

Stopgap fix: patch CVE-2026-109618 / 109619 (PHP RCE) while still on PHP 7.4

softjapan — Fri, 23 Oct 2026 16:20:26 +0000

On 2026-10-21 the PHP project disclosed two unauthenticated remote code execution vulnerabilities (php.net announcement):

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partly initialized, and request cleanup may then treat that invalid data as valid.
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): internal state owned by a request can survive after its memory is freed, and a later request on the same worker may use it.

Every PHP installation that serves web requests is affected: PHP-FPM, Apache mod_php, php-cgi and others. The advisory rates the risk highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs.

Fixed releases exist only for PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 7.4 is end of life, but because the bugs are so severe, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1.

The official Docker images php:7.4-* will not be rebuilt. If your Dockerfile says FROM php:7.4-apache, you stay vulnerable unless you act.

So I rebuilt those images with the backport applied and published them as open source:

👉 https://github.com/softjapan/php74-cve-patched

⚠️ This is a stopgap, not a fix for PHP 7.4.

Only CVE-2026-109618 and CVE-2026-109619 are fixed. Other issues found after 7.4.33 are not.

The base OS, Debian 11 (bullseye), reached end of LTS in 2026-08. OS packages such as OpenSSL and Apache receive no more updates.

These are not official images from the PHP project or Docker.

The real fix is upgrading to PHP 8.2 or newer. Use these images to buy time for that upgrade.

TL;DR

- FROM php:7.4-apache
+ FROM ghcr.io/softjapan/php74-cve-patched:7.4-apache

Change one FROM line (apache / fpm / cli, amd64 / arm64).
Rebuild, redeploy and restart every PHP worker.
Confirm the fix with check-patched.sh.
Plan your upgrade to PHP 8.2+. You are done only after this step.

Step 1: check whether you are vulnerable

The catch: after the backport, php -v still prints 7.4.33. The version number cannot tell you whether you are protected.

This script looks inside the PHP binaries instead:

curl -fsSLO https://raw.githubusercontent.com/softjapan/php74-cve-patched/main/scripts/check-patched.sh
sh check-patched.sh php:7.4-apache            # an image
sh check-patched.sh --container my-web-1      # a running container
sh check-patched.sh --local                   # this machine (VM / bare metal)

The official image:

Image: php:7.4-apache
PHP version: 7.4.33
  VULNERABLE  /usr/lib/apache2/modules/libphp7.so
  VULNERABLE  /usr/local/bin/php
RESULT: VULNERABLE to CVE-2026-109618 / CVE-2026-109619

The patched image:

Image: ghcr.io/softjapan/php74-cve-patched:7.4-apache
PHP version: 7.4.33
  patched     /usr/lib/apache2/modules/libphp7.so
  patched     /usr/local/bin/php
RESULT: PATCHED (backport found in every PHP binary)

PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 and newer count as fixed. Older versions are checked for zend_new_array_singleton, a function the backport adds.
It checks each SAPI binary separately: the CLI, plus libphp7.so (mod_php) and php-fpm, which are what actually serve your requests. That catches a patched CLI next to an unpatched Apache module.
Exit code 0 means patched and 1 means vulnerable, so you can block vulnerable images in CI.

The check is a heuristic. A backport from a distribution or LTS vendor written a different way may show as vulnerable. In that case, check with your vendor.

Step 2: switch images

The same images, with the same tags and digests, are on two registries:

Official image	GHCR	Docker Hub
`php:7.4-apache`	`ghcr.io/softjapan/php74-cve-patched:7.4-apache`	`softjpn/php74-cve-patched:7.4-apache`
`php:7.4-fpm`	`ghcr.io/softjapan/php74-cve-patched:7.4-fpm`	`softjpn/php74-cve-patched:7.4-fpm`
`php:7.4-cli`	`ghcr.io/softjapan/php74-cve-patched:7.4-cli`	`softjpn/php74-cve-patched:7.4-cli`

They work exactly like the official images:

docker-php-ext-install, docker-php-ext-configure, pecl and php.ini-production all work as before.
CI checks that php -m lists the same extensions as the official image.
apt-get install works, because apt now points at archive.debian.org.

Example for Laravel:

FROM ghcr.io/softjapan/php74-cve-patched:7.4-apache

RUN apt-get update && apt-get install -y --no-install-recommends \
        libzip-dev libpng-dev libjpeg-dev libfreetype6-dev \
    && rm -rf /var/lib/apt/lists/* \
    && docker-php-ext-configure gd --with-freetype --with-jpeg \
    && docker-php-ext-install -j"$(nproc)" gd pdo_mysql zip bcmath opcache \
    && a2enmod rewrite

Changing the image is not enough on its own. Containers and workers that are already running keep the old binaries. Rebuild, redeploy and restart every PHP worker, then run check-patched.sh --container <name> against the running container.

What exactly changed

Very little. The images start from the last PHP 7.4 Dockerfiles in docker-library/php (commit 1361ba95) and change three things:

apt uses archive.debian.org. Bullseye has left the regular mirrors, so apt-get update there returns 404.
The backport is applied to the PHP 7.4.33 source with patch -p1 --fuzz=0. If it does not apply cleanly, the build fails.
The build checks the result. If php, php-fpm or libphp7.so is missing the fix, the build fails.

The patch is byte-identical to the upstream commit php/php-src@712e60f. On every push and every week, CI checks two things:

The vendored patch still matches the upstream commit.
The upstream backport branch has no new commits. If it does, CI fails so a new patch can be shipped.

My first internal version re-ran ./configure on top of php:7.4-apache. That approach hard-coded x86_64 options and let the fpm and cli builds drift from each other. Starting from the official Dockerfiles keeps the images compatible with the official ones and makes multi-arch builds straightforward.

Trust, but verify

You probably should not pull a security image from a stranger on faith, so everything here can be checked:

Images are built only by GitHub Actions in the repository, with SBOM and provenance attestations.
Images are signed with cosign (keyless):

cosign verify ghcr.io/softjapan/php74-cve-patched:7.4-apache \
  --certificate-identity-regexp '^https://github.com/softjapan/php74-cve-patched/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Pin a digest (@sha256:...) in production.
Or skip these images and build them yourself. The guide also covers applying the patch with patch -p1 if you build PHP from source without Docker.

Mitigations if you cannot switch right away

The advisory also lists mitigations. It is clear that they only block some attack paths and do not make an installation safe, but they are useful as a bridge until you switch, and as defense in depth afterwards.

CVE-2026-109618 (OOM corruption)

Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache config. Check that no other setting brings back a finite limit.
- Use a container or cgroup memory limit instead, ideally one that kills only the affected worker.
- Do not use RLIMIT_AS or RLIMIT_DATA as a substitute. They can cause the very allocation failure you are trying to avoid.
Lower post_max_size: 8M if you have no file uploads, 32M if you do. Keep upload_max_filesize below post_max_size.
Also limit request size, field count, multipart part count, header count and nesting depth at the web server or proxy, including for requests without a usable Content-Length.

CVE-2026-109619 (stale global state)

Set session.upload_progress.enabled=0 and restart every worker.
- Set it in php.ini, the FPM pool or the server config, which apply before request parsing. ini_set() and .user.ini do not help.
Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding the diagnostics with @ or display_errors does not help.
Fix fatal errors and timeouts that an attacker can trigger.

The images ship an optional file with some of these settings (session.upload_progress.enabled = 0 and lower post_max_size / upload_max_filesize). It is disabled by default, so PHP behaves exactly like the official image. To enable it:

RUN cp /usr/local/share/php74-cve-patched/zz-cve-2026-mitigations.ini "$PHP_INI_DIR/conf.d/"

After the stopgap

One more time: this stops the bleeding. It does not cure the patient.

[ ] Find every PHP 7.4 environment and run check-patched.sh on it.
[ ] Switch images, redeploy and restart the workers.
[ ] Confirm check-patched.sh --container reports PATCHED on the running containers.
[ ] Add the mitigation settings where they make sense.
[ ] Set a plan and a deadline for moving to PHP 8.2+. PHP 8.2 itself reaches end of life on 2026-12-31, so consider 8.3 or newer.
[ ] Tell your team that the OS (Debian 11) is not getting updates either.

Summary

CVE-2026-109618 and CVE-2026-109619 are unauthenticated RCEs. Treat mod_php as top priority.
The official PHP 7.4 Docker images will not be fixed. If you use php:7.4-*, you stay vulnerable.
php74-cve-patched is a stopgap that brings in the official backport with a one-line FROM change.
The real fix is upgrading to PHP 8.2 or newer.

PHP 8.0 / 8.1 images (official backports exist for those too) and Alpine variants are on the roadmap. Open an issue if you need one. And if this saved you an emergency upgrade, a ⭐ on GitHub helps other people stuck on PHP 7.4 find it.

👉 https://github.com/softjapan/php74-cve-patched

References

Set Up a Laravel Backend and Next.js Frontend Development Environment with Docker within 5 minutes

softjapan — Sat, 04 Jan 2025 15:35:19 +0000

Set Up a Laravel Backend and Next.js Frontend Development Environment with Docker within 5 minutes

github

This guide walks you through creating a Laravel backend and a Next.js frontend, all within a Dockerized environment. You can have everything up and running in just a few minutes.

Prerequisites

Docker and Docker Compose installed on your system
Basic knowledge of Laravel and Next.js

- Basic knowledge of command-line usage

1. Clone the Repository

git clone https://github.com/softjapan/laravel-nextjs-dev-environment.git

2. Create the Laravel Backend

By default, this setup uses MySQL. We will skip running migrations at this point and do them later. Other options use default settings.

cd laravel-nextjs-dev-environment
docker run --rm -it -v "$PWD:/app" softjpn/laravel-nodejs-dev laravel new laravel-backend

3. Install Laravel Breeze and Dependencies

We will install Laravel Breeze (API scaffolding) without running migrations at this stage. Migrations will be run later after configuring the .env file and starting the Docker containers.

cd laravel-backend
docker run --rm -it -v "$PWD:/app" softjpn/laravel-nodejs-dev composer require laravel/breeze --dev
docker run --rm -it -v "$PWD:/app" softjpn/laravel-nodejs-dev php artisan breeze:install api

4. Create the Next.js Frontend

cd ..
docker run --rm -it -v "$PWD:/app" softjpn/laravel-nodejs-dev git clone https://github.com/laravel/breeze-next.git next-frontend

5. Install Frontend Dependencies

cd next-frontend
docker run --rm -it -v "$PWD:/app" softjpn/laravel-nodejs-dev npm install

6. Create the Environment Files

These files contain database connection details and other environment variables.

cd ..
cp ./envfiles/laravel-backend/.env ./laravel-backend/.env
cp ./envfiles/next-frontend/.env ./next-frontend/.env

7. Start the Docker Containers

docker compose up -d

8. Run Database Migrations

Once the containers are running and your .env files are in place, apply the migrations:

docker exec -it laravel-backend php artisan migrate

9. Access the Frontend

Open your browser and navigate to:

http://localhost:3000

10. Stop the Docker Containers

When you’re done, shut down the containers:

docker compose down

Screenshot

License

This project is open source and available under the MIT License.

Contributing

Contributions are welcome! Feel free to open a pull request with improvements or suggestions.

Contact

For questions or additional support, please open an issue in this repository.

Enjoy your streamlined Laravel + Next.js development setup!

ChatGPT Client with LINE-Style UI Built with Flutter and Riverpod

softjapan — Wed, 01 Jan 2025 03:00:28 +0000

ChatGPT Client with LINE-Style UI Built with Flutter and Riverpod

This is a ChatGPT client application developed with Flutter and Riverpod, featuring a LINE-inspired chat UI.

It provides real-time, bidirectional communication by integrating with OpenAI’s GPT models.

Features

LINE-Style Chat UI A simple, intuitive design that offers a streamlined user experience
Real-Time Chat with OpenAI GPT Model Utilizes the ChatGPT API to enable natural, human-like conversations
State Management with Riverpod Improves scalability and maintainability by separating application logic from the UI
Responsive Design Adapts seamlessly to various screen sizes, from smartphones to larger devices

Screenshots

Requirements

Flutter 3.19.x or higher
Dart 3.3.x or higher
OpenAI API Key

Setup

Clone the repository

   git clone https://github.com/softjapan/flutter_chatgpt.git

Install dependencies

   flutter pub get

Configure environment variables Create a .env file in the project’s root directory and add the following:

   endpoint='https://api.openai.com/v1/'
   model='gpt-4-turbo-preview'
   aiToken='your-api-key-here'

Run the application

   flutter run

Technologies Used

License

This project is released under the MIT License. Please see the LICENSE file for details.

How to Contribute

Fork this repository
Create a new feature branch

   git checkout -b feature/amazing-feature

Commit your changes

   git commit -m 'Add some amazing feature'

Push the branch to the remote repository

   git push origin feature/amazing-feature

Create a Pull Request

Author

Twitter: FullStack@ITエンジニア

GitHub Repository: https://github.com/softjapan/flutter_chatgpt