Sign inSign up

softjpn/php74-cve-patched

By softjpn

•Updated 2 days ago

PHP 7.4.33 (apache/fpm/cli) with the official backport for CVE-2026-109618 / CVE-2026-109619

Image
0

844

softjpn/php74-cve-patched repository overview

⁠php74-cve-patched

build GHCR Docker Hub license

Drop-in php:7.4-* Docker images with the official fix for the critical PHP RCE vulnerabilities CVE-2026-109618 and CVE-2026-109619.

English | 日本語⁠ | GitHub⁠ | Docker Hub⁠

On 2026-10-21 the PHP project disclosed two unauthenticated remote code execution vulnerabilities⁠ and called the risk highest for Apache mod_php. Fixed releases exist only for PHP 8.2+. For PHP 7.4 the PHP security team published a source backport⁠, but the official php:7.4-* images will never be rebuilt.

This repository builds those images again, with the backport applied, and changes nothing else.

⁠Use it

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

The same images are published to two registries. Use whichever you prefer:

Official imageGitHub Container RegistryDocker Hub
php:7.4-apacheghcr.io/softjapan/php74-cve-patched:7.4-apachesoftjpn/php74-cve-patched:7.4-apache
php:7.4-fpmghcr.io/softjapan/php74-cve-patched:7.4-fpmsoftjpn/php74-cve-patched:7.4-fpm
php:7.4-clighcr.io/softjapan/php74-cve-patched:7.4-clisoftjpn/php74-cve-patched:7.4-cli
- FROM php:7.4-apache
+ FROM softjpn/php74-cve-patched:7.4-apache    # Docker Hub

GHCR has no pull rate limit for public images; Docker Hub applies its usual pull limits⁠ to anonymous pulls.

  • linux/amd64 and linux/arm64
  • Same layout, extensions and helper scripts as the official image: docker-php-ext-install, docker-php-ext-configure, pecl, php.ini-production, ... (CI checks that php -m is identical)
  • apt-get install keeps working: apt points at archive.debian.org (Debian 11 left LTS in 2026-08)

Then rebuild and redeploy your image, and restart every PHP worker.

⁠Am I vulnerable?

php -v prints 7.4.33 before and after the fix, so the version number does not tell you. check-patched.sh 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)
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

It works for any PHP version: 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 and newer count as fixed, and older versions are checked for the backport. Exit code 0 = patched, 1 = vulnerable, which makes it easy to use in CI.

⁠Tags

TagMeaning
7.4-apache, 7.4-fpm, 7.4-cliLatest build. Use these like the official tags
7.4.33-<variant>-cve20261021The build with the 2026-10-21 fix
7.4.33-<variant>-YYYYMMDDA specific build date
latest7.4-apache

Both registries carry the same tags and the same digests.

For production, pin a digest, for example ghcr.io/softjapan/php74-cve-patched:7.4-apache@sha256:... or softjpn/php74-cve-patched:7.4-apache@sha256:.... Get it with docker buildx imagetools inspect softjpn/php74-cve-patched:7.4-apache.

⁠What exactly is changed

Compared with the last official PHP 7.4 Dockerfiles from docker-library/php⁠:

  1. apt uses archive.debian.org (bullseye is no longer on the normal mirrors).
  2. patches/7.4/CVE-2026-109618-109619.patch⁠ is applied to the PHP 7.4.33 source with patch --fuzz=0. The file is byte-identical to upstream commit php/php-src@712e60f⁠; CI checks this on every push and every week.
  3. The build fails unless every SAPI binary (php, php-fpm, libphp7.so) contains the fix.

Every change is marked with php74-cve-patched in the Dockerfiles⁠. The PHP tarball is still checked against the official SHA-256 and GPG signature.

⁠Trust, but verify

  • Images on both registries are built only by GitHub Actions in this 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
    

    The Docker Hub images are signed the same way: replace the image with softjpn/php74-cve-patched:7.4-apache.

  • Or don't use our images at all: build them yourself⁠, or apply the same patch to your own PHP source build.

⁠Extra hardening (optional)

The images do not change any PHP setting. If you want the mitigations from the advisory as well, enable the file shipped in the image:

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

It sets session.upload_progress.enabled = 0 and lower post_max_size / upload_max_filesize. See conf/zz-cve-2026-mitigations.ini⁠.

⁠Examples

⁠Limits: please read

  • This is not a supported PHP. Only CVE-2026-109618 and CVE-2026-109619 are fixed. Other issues fixed after 7.4.33 are not. The long-term fix is upgrading to PHP 8.2+.
  • The OS is not updated. Debian 11 is out of LTS, so scanners such as Trivy will report OS package CVEs. If you need OS updates too, look at a commercial LTS vendor.
  • Not affiliated with the PHP project or Docker. Provided as is, under the MIT License.

⁠Roadmap

  • PHP 8.0 and 8.1 images (the PHP security team published backports for them too)
  • zts and Alpine variants
  • Debian ELTS-based OS updates

Need one of these? Open an issue or 👍 an existing one. That decides what comes next.

⁠Contributing

See CONTRIBUTING.md⁠. Security problems with these images: SECURITY.md⁠.

If this saved you an emergency upgrade, a ⭐ helps other people stuck on PHP 7.4 find it.

Tag summary

Content type

Image

Digest

sha256:318e32eb4…

Size

154.3 MB

Last updated

2 days ago

docker pull softjpn/php74-cve-patched