Security rebuild of published images after PHP 8.5.12 (or patch-level base pin) #334

Context

PHP 8.5.12 was released on 21 Oct 2026 as a security release, fixing two RCEs: CVE-2026-109618 (longjmp() on OOM leaves request memory uninitialized, and the following cleanup reads or branches on it) and CVE-2026-109619 (global state left pointing into freed request memory). Both are CVSS v4.0 9.2. Affected: 8.2 <8.2.35, 8.3 <8.3.36, 8.4 <8.4.27, 8.5 <8.5.12.

Observation

The runtime image is php:apache (mod_php), so the PHP core fix is the relevant one. The base comes from a major.minor ref only — the workflow passes APP_IMAGE=php:${{ php-version }}-apache and BUILDER_IMAGE=php:${{ php-version }}-cli-alpine, with php-version defaulting to 8.5. No patch level is pinned anywhere, and .github/dependabot.yml only tracks github-actions, so nothing bumps these on its own. Published images therefore reflect whenever they were last built:

• glpi/glpi:12.0.0 (2026-10-18) — PHP_VERSION=8.5.11
• glpi/glpi:11.0.11 (2026-10-18) — 8.5.11
• glpi/glpi:10.0.28 (2026-10-04) — 8.5.11

All predate the fix. As of writing, php:8.5-apache and php:8.5-cli-alpine still resolve to 8.5.11 and php:8.5.12-apache is not published yet, so this is not actionable until that base lands.

Ask

Once php:8.5.12 is available, a workflow_dispatch run with no-cache: true for the current release tags would be the lightest fix. If you prefer reproducibility instead, the alternative is pinning APP_IMAGE/BUILDER_IMAGE to patch-level tags. Happy to hear which you prefer — no preference assumed.

One question (not a bug report)

glpi/glpi:10.0.28 also reports PHP 8.5.11, while GLPI 10.0.x supports PHP 8.1–8.3. Is the 10.0 branch intentionally built on 8.5, or a side effect of the major.minor default?