Repository navigation
fix(security): require PHP 8.5.12 for CVE-2026-109618 / CVE-2026-109619 - #1598
Merged
Merged
Conversation
rumblefrog
requested changes
Oct 21, 2026
Member
There was a problem hiding this comment.
I think we should drop the installer change. While yes we want to have folks update their PHP, the change in installer sounds like a new minimum even though nothing enforces it, especially for existing installs, and we still only require 8.5 in our composer manifest.
Contributor
Author
There was a problem hiding this comment.
Agreed, dropped in 24f678a. The wizard is back to the plain 8.5 check.
|
|
||
| - **PHP 8.5 or newer.** This is checked by the install wizard's | ||
| "System check" step. | ||
| - **PHP 8.5.12 or newer for production.** Older 8.5 releases have two |
Member
There was a problem hiding this comment.
Ditto, can drop, otherwise we'll need to clear this out in the future.
Contributor
Author
There was a problem hiding this comment.
Dropped in 24f678a. I also reworded the Docker "Upgrading" note so it no longer names a PHP version, for the same reason.
PHP 8.5.12 fixes two critical unauthenticated RCE bugs (OOM corruption and stale global state). The production image runs mod_php, the deployment the PHP security team rates highest risk. - Dockerfile.prod: fail the build when the floating php:8.5-apache base is below 8.5.12 (PHP_MIN_VERSION build arg), so a stale cache or lagging mirror can't publish a vulnerable runtime. - docker-image.yml: pull: true so buildx always re-resolves the base. - prod-php.ini: session.upload_progress.enabled=0 and fatal_error_backtraces=0, the advisory's mitigations for the CVE-2026-109619 paths. The panel uses neither. - Install wizard: warn (not block) below 8.5.12, since distros may backport the fix. - Docs: prerequisites + Docker upgrade notes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review feedback: the wizard warning read like a new minimum that nothing enforces (composer still requires 8.5), and versioned prose would need clearing later. The Docker build floor and php.ini mitigations stay. Reword the Docker upgrade note so it doesn't name a PHP version. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
rumblefrog
force-pushed
the
fix/php-cve-2026-109618
branch
from
October 21, 2026 22:32
24f678a to
3364e03
Compare
rumblefrog
approved these changes
Oct 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PHP published an urgent security advisory today (php.net, 2026-10-21): CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) and CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), two critical unauthenticated remote code execution bugs fixed in PHP 8.5.12. The PHP team rates the risk highest for
mod_php, which is what the production image runs (php:8.5-apache).This PR keeps the published image from shipping a vulnerable PHP and applies the advisory's mitigations. Nothing else.
docker/Dockerfile.prod: the runtime stage fails the build when PHP is belowPHP_MIN_VERSION(default8.5.12). Thephp:8.5-apachetag floats, so a stale cache or a lagging mirror would otherwise publish an unpatched image without anyone noticing..github/workflows/docker-image.yml:pull: trueonbuild-push-actionso buildx always re-resolves the base image.docker/php/prod-php.ini:session.upload_progress.enabled = 0andfatal_error_backtraces = 0, the advisory's mitigations for the confirmed CVE-2026-109619 paths. The panel uses neither. They have to be set before request parsing (not viaini_set()), hence the ini file.Heads-up
At the time of writing, Docker Hub's
php:8.5-apachestill resolves to 8.5.11. Until the official image is rebuilt, the:main/ tag builds will fail on purpose at the floor check rather than publish a vulnerable image. Re-rundocker-image.ymlonce Docker Hub ships 8.5.12, and it may be worth cutting a release afterwards so:latestpicks up the patched PHP.Test plan
php:8.5-apache(8.5.11): fails with floor8.5.12, passes with floor8.5.0prod-php.inimounted in the base image: both directives read0docker-image.ymlgreen once Docker Hub publishes 8.5.12@rumblefrog @maxijabase: time-sensitive security fix, could you take a look? The CVEs are already public, so a regular PR seemed fine.
🤖 Generated with Claude Code