PHP 8.5.9 is a runtime patch contract, not an app deploy

A green application deploy is a weak answer to a PHP security release.

PHP 8.5.9 is already visible as source truth: the php-8.5.9 NEWS entry is dated 30 Jul 2026, the distribution tarball at https://www.php.net/distributions/php-8.5.9.tar.gz returns HTTP 200, and the PGSQL section records a fix for GHSA-7qpv-r5mr-78m4 — SQL injection via E'...' backslash breakout, tracked as CVE-2026-17543. At the same time, the public php.net releases JSON endpoint still presents 8.5.8 (02 Jul 2026) as the current 8.x announcement row, and the main ChangeLog page has not yet absorbed 8.5.9. That lag is not a reason to ignore the patch. It is a reason to treat the release as a runtime inventory problem instead of an “npm-style bump” you fold into the next app ship. [Source: https://raw.githubusercontent.com/php/php-src/php-8.5.9/NEWS] [Source: https://www.php.net/releases/index.php?json]

If your product is a Laravel app on pgsql, the vulnerable surface is not “some controller you forgot to review.” It is the PHP binary that still accepts traffic, runs queue workers, executes scheduled commands, and builds CI images. The question is not whether the changelog demos cleanly. The question is whether the fix survives handoff across every surface that still claims to be production.

What 8.5.9 actually fixed (primary sources only)

Do not rewrite security releases from social summaries. Read the NEWS entry for the tag you will install.

From the 30 Jul 2026, PHP 8.5.9 NEWS block on php-src tag php-8.5.9, the security-relevant lines that matter for most Laravel + PostgreSQL shops include:

[Source: https://raw.githubusercontent.com/php/php-src/php-8.5.9/NEWS]

That table is deliberately incomplete as a full CVE encyclopedia. NEWS also lists many non-security bugfixes (Opcache, ODBC, Date, Reflection, Zip, and more). For operations, the first decision is not “memorize every line.” It is “which of these touch the binaries and extensions we actually load in production?”

For a typical Laravel SaaS on PostgreSQL:

• pgsql / PDO_PGSQL path makes CVE-2026-17543 the headline. Laravel’s database layer sits on top of PHP’s PostgreSQL extensions and the server’s libpq stack. An application that “only uses Eloquent” still runs inside a PHP process that includes those extensions if they are compiled/enabled.
• GD matters if you process uploads, generate invoices, or resize images in PHP rather than in a side service.
• Phar matters for packaging, some CI utilities, and any path that still opens phar streams.
• BCMath matters if money or high-precision math touches bccomp() in app or vendor code.

Staged release discipline: tag and tarball before marketing UI

On 2026-07-30, a practical verification pass looked like this:

1. NEWS for tag php-8.5.9 is present and dated 30 Jul 2026.
2. GET https://www.php.net/distributions/php-8.5.9.tar.gz returns HTTP 200 with a gzip payload (CDN cache hit observed; Last-Modified on the object can predate the NEWS header date because packaging and announcement are different steps).
3. https://www.php.net/releases/index.php?json still advertises 8.5.8 as the current major-line announcement payload.
4. The public ChangeLog HTML snapshot checked in the same window did not yet contain the string 8.5.9.

That pattern is a staged security release: source and tarball move first; some website surfaces lag. Teams that only watch the pretty downloads page will patch late. Teams that only watch Twitter will patch the wrong hosts. Teams that inventory binaries will know which machines still answer with 8.5.8.

Source php-src NEWS for php-8.5.9

Source php.net releases JSON

Why Laravel deploys lie about PHP security

Laravel deploy culture optimizes for application artifacts: Git SHA, composer.lock, config cache, route cache, migrated schema, restarted PHP-FPM or Octane workers. Those are necessary. None of them are a PHP security release.

Consider a common topology:

The failure mode is boring and expensive: web pods move to 8.5.9 on Monday, workers stay on Friday’s AMI until the next packer rebuild, and CI keeps using a cached php:8.5-cli layer from two weeks ago. Your app repo is “secure.” Your runtime estate is not.

This is the same discipline as artifact-backed cron health elsewhere on this site: exit codes and green dashboards are not proof until the artifact you care about is inspected. See /blog/your-cron-job-is-not-healthy-until-the-artifact-proves-it/ and the broader hub at /developer-tools/.

Build a runtime inventory before you argue about frameworks

Start with a spreadsheet or a tiny YAML file owned by whoever can actually rebuild images. Name surfaces, not vibes.

 1# runtime-inventory/php-surfaces.yaml
 2# Owner: [email protected]
 3# Purpose: prove which binaries must move for PHP 8.5.9
 4surfaces:
 5  - id: ci-php-cli
 6    kind: container-image
 7    ref: ghcr.io/example/ci-php:8.5
 8    rebuild: ".github/workflows/build-ci-php.yml"
 9    verify: "php -v && php -m | rg -i 'pdo_pgsql|pgsql|gd|phar|bcmath'"
10  - id: app-fpm
11    kind: container-image
12    ref: ghcr.io/example/app-fpm:prod
13    rebuild: "deploy/docker/fpm.Dockerfile"
14    verify: "php -v"
15  - id: queue-worker
16    kind: container-image
17    ref: ghcr.io/example/app-worker:prod
18    rebuild: "deploy/docker/worker.Dockerfile"
19    verify: "php -v"
20  - id: scheduler-host
21    kind: vm
22    ref: "prod-scheduler-1"
23    rebuild: "packer/scheduler.pkr.hcl"
24    verify: "php -v"
25  - id: prod-bastion
26    kind: vm
27    ref: "bastion-1"
28    rebuild: "ansible/bastion.yml"
29    verify: "php -v || true"
30target_version: "8.5.9"
31advisory_focus:
32  - "CVE-2026-17543"
33  - "CVE-2026-17544"
34  - "CVE-2026-9672"
35  - "CVE-2026-7260"

Then generate an evidence file your incident channel can paste. Do not trust chat memory.

 1#!/usr/bin/env bash
 2# scripts/php-runtime-evidence.sh
 3set -euo pipefail
 4
 5OUT="${1:-/tmp/php-runtime-evidence.txt}"
 6TARGET="${TARGET_PHP:-8.5.9}"
 7{
 8  echo "# PHP runtime evidence"
 9  echo "collected_at=$(date -Is)"
10  echo "target=${TARGET}"
11  echo
12  echo "## local"
13  php -v
14  php -r 'echo PHP_VERSION, PHP_EOL;'
15  php -m | tr '[:upper:]' '[:lower:]' | sort | rg '^(pdo_pgsql|pgsql|gd|phar|bcmath)$' || true
16  echo
17  echo "## composer platform (if present)"
18  if [[ -f composer.lock ]]; then
19    php -r '
20      $lock = json_decode(file_get_contents("composer.lock"), true);
21      echo "platform.php=" . ($lock["platform"]["php"] ?? "(unset)") . PHP_EOL;
22      foreach (($lock["platform-dev"] ?? []) as $k => $v) {
23        if (str_starts_with($k, "php")) echo "platform-dev.$k=$v\n";
24      }
25    '
26  fi
27} | tee "$OUT"
28
29echo "Wrote $OUT"

For container estates, evidence must include the image digest, not only a floating tag:

 1#!/usr/bin/env bash
 2# scripts/php-image-probe.sh
 3set -euo pipefail
 4IMAGE="${1:?image ref required}"
 5
 6digest="$(crane digest "$IMAGE" 2>/dev/null || skopeo inspect "docker://${IMAGE}" --format '{{.Digest}}')"
 7version="$(docker run --rm --entrypoint php "$IMAGE" -r 'echo PHP_VERSION;')"
 8
 9printf 'image=%s\ndigest=%s\nphp_version=%s\n' "$IMAGE" "$digest" "$version"
10
11if [[ "$version" != 8.5.9* ]]; then
12  echo "FAIL: expected PHP 8.5.9.x, got $version" >&2
13  exit 2
14fi

Map CVE-2026-17543 to the Laravel + pgsql boundary

Laravel documents PostgreSQL as a first-class database connection via the pgsql driver configuration. Your app code talks to Illuminate; Illuminate talks to PDO; PDO talks to the PHP extension and the linked client libraries. [Source: https://laravel.com/docs/13.x/database]

The NEWS fix is in PGSQL: SQL injection via E'...' backslash breakout. You do not need a public proof-of-concept on the public internet to justify patching. You need a sober boundary map:

1. Do we enable pgsql or pdo_pgsql in production PHP? If yes, the binary is in scope.
2. Do any code paths build escape-heavy SQL strings instead of bound parameters? Prefer bindings everywhere; still patch the runtime.
3. Do reporting tools, admin scripts, or legacy packages use PostgreSQL escape string modes? Inventory vendor code that touches pg_* or raw escape helpers.
4. Do read replicas / analytics sidecars run a different PHP for ETL jobs that still speak Postgres?

 1<?php
 2// app/Console/Commands/PhpRuntimeReportCommand.php
 3namespace App\Console\Commands;
 4
 5use Illuminate\Console\Command;
 6
 7final class PhpRuntimeReportCommand extends Command
 8{
 9    protected $signature = 'ops:php-runtime-report {--json : Emit JSON}';
10    protected $description = 'Emit PHP version and security-relevant extension presence for inventory';
11
12    public function handle(): int
13    {
14        $extensions = ['pdo_pgsql', 'pgsql', 'gd', 'phar', 'bcmath'];
15        $present = [];
16        foreach ($extensions as $ext) {
17            $present[$ext] = extension_loaded($ext);
18        }
19
20        $payload = [
21            'php_version' => PHP_VERSION,
22            'php_sapi' => PHP_SAPI,
23            'uname' => php_uname('a'),
24            'extensions' => $present,
25            'pdo_drivers' => \PDO::getAvailableDrivers(),
26            'default_connection' => config('database.default'),
27            'default_driver' => config('database.connections.'.config('database.default').'.driver'),
28        ];
29
30        if ($this->option('json')) {
31            $this->line(json_encode($payload, JSON_PRETTY_PRINT));
32            return self::SUCCESS;
33        }
34
35        $this->table(['Key', 'Value'], [
36            ['php_version', $payload['php_version']],
37            ['php_sapi', $payload['php_sapi']],
38            ['default_connection', $payload['default_connection']],
39            ['default_driver', $payload['default_driver']],
40            ['pdo_pgsql', $present['pdo_pgsql'] ? 'yes' : 'no'],
41            ['pgsql', $present['pgsql'] ? 'yes' : 'no'],
42            ['gd', $present['gd'] ? 'yes' : 'no'],
43            ['phar', $present['phar'] ? 'yes' : 'no'],
44            ['bcmath', $present['bcmath'] ? 'yes' : 'no'],
45        ]);
46
47        return self::SUCCESS;
48    }
49}

Wire a read-only ops route only behind admin auth or private network controls if you need HTTP probes from your mesh. Prefer SSH/kubectl exec evidence during an incident; HTTP surfaces become attack surface if left public.

1<?php
2// routes/ops.php — loaded only when APP_ENV !== production public edge
3use App\Http\Controllers\Ops\PhpRuntimeController;
4use Illuminate\Support\Facades\Route;
5
6Route::middleware(['auth:ops', 'can:viewOps'])
7    ->get('/ops/php-runtime', PhpRuntimeController::class);

 1<?php
 2// app/Http/Controllers/Ops/PhpRuntimeController.php
 3namespace App\Http\Controllers\Ops;
 4
 5use Illuminate\Http\JsonResponse;
 6
 7final class PhpRuntimeController
 8{
 9    public function __invoke(): JsonResponse
10    {
11        return response()->json([
12            'php_version' => PHP_VERSION,
13            'sapi' => PHP_SAPI,
14            'extensions' => [
15                'pdo_pgsql' => extension_loaded('pdo_pgsql'),
16                'pgsql' => extension_loaded('pgsql'),
17                'gd' => extension_loaded('gd'),
18                'phar' => extension_loaded('phar'),
19                'bcmath' => extension_loaded('bcmath'),
20            ],
21        ]);
22    }
23}

Dockerfile and base-image contracts that actually move the binary

Floating FROM php:8.5-fpm without a digest is how estates drift. Pin what you can, rebuild when NEWS demands it, and fail CI when PHP_VERSION is wrong.

 1# deploy/docker/fpm.Dockerfile
 2# Pin the base digest your platform team approved after verifying php -v == 8.5.9*
 3ARG PHP_BASE=php:8.5-fpm-bookworm@sha256:REPLACE_AFTER_VERIFY
 4FROM ${PHP_BASE}
 5
 6# Fail the build if the base lied
 7RUN php -r 'if (!str_starts_with(PHP_VERSION, "8.5.9")) { fwrite(STDERR, "PHP ".PHP_VERSION." != 8.5.9.x\n"); exit(1);} '
 8
 9# Only install extensions you actually need; each one expands CVE surface
10RUN docker-php-ext-install pdo_pgsql pcntl opcache \
11    && docker-php-ext-enable opcache
12
13WORKDIR /var/www/html
14COPY --chown=www-data:www-data . .
15USER www-data

In CI, separate “application tests” from “runtime contract tests”:

 1# .github/workflows/php-runtime-contract.yml
 2name: php-runtime-contract
 3on:
 4  workflow_dispatch:
 5  schedule:
 6    - cron: "15 1 * * *"
 7jobs:
 8  probe-images:
 9    runs-on: ubuntu-latest
10    strategy:
11      matrix:
12        image:
13          - ghcr.io/example/ci-php:8.5
14          - ghcr.io/example/app-fpm:prod
15          - ghcr.io/example/app-worker:prod
16    steps:
17      - uses: actions/checkout@v4
18      - name: Probe PHP version inside image
19        run: |
20          set -euo pipefail
21          docker pull "${{ matrix.image }}"
22          v="$(docker run --rm --entrypoint php "${{ matrix.image }}" -r 'echo PHP_VERSION;')"
23          echo "php_version=$v"
24          case "$v" in
25            8.5.9*) echo "ok" ;;
26            *) echo "unexpected PHP $v"; exit 2 ;;
27          esac

If you build PHP from the official tarball during a staged window — before your distro package catches up — record the URL and checksum in the runbook. Prefer distro/security packages when they exist; when you must use php.net/distributions, verify the object you downloaded.

1#!/usr/bin/env bash
2# scripts/fetch-php-859-tarball.sh
3set -euo pipefail
4URL="https://www.php.net/distributions/php-8.5.9.tar.gz"
5OUT="${1:-/tmp/php-8.5.9.tar.gz}"
6curl -fsSL "$URL" -o "$OUT"
7# Record size + sha256 in the ticket; do not trust a chat paste
8sha256sum "$OUT" | tee /tmp/php-8.5.9.tar.gz.sha256
9file "$OUT"

A close-the-loop checklist you can run Monday

Use this as an incident checklist, not as inspiration.

1. Freeze the claim

Write one sentence in the ticket:

PHP 8.5.9 includes CVE-2026-17543 (PGSQL E'...' backslash breakout per php-src NEWS). We will mark this closed only when every production PHP surface that loads pgsql/pdo_pgsql reports 8.5.9.x.

2. Enumerate surfaces

Web FPM/Octane, workers, scheduler, CI images, local dev shared runners, bastion/debug hosts, any Lambda/sidecar still embedding PHP.

3. Collect evidence

For each surface: php -v, image digest or package version, owner, rebuild path, timestamp.

4. Rebuild from the outside in

1. CI image first (so tests run on the target runtime).
2. App base image.
3. Worker/scheduler images.
4. VMs/packer images.
5. Only then cut production traffic.

5. Verify after rollout

Do not trust the deploy UI alone. Exec into a live pod/host:

1kubectl exec deploy/app-fpm -- php -r 'echo PHP_VERSION, PHP_EOL;'
2kubectl exec deploy/queue-worker -- php -r 'echo PHP_VERSION, PHP_EOL;'
3ssh scheduler-1 'php -r "echo PHP_VERSION, PHP_EOL;"'

6. Regression smoke for Laravel + pgsql

Keep this boring:

• migrate status on a staging clone
• login + one authenticated write path
• one queue job that touches Postgres
• one scheduler command
• extension presence check from ops:php-runtime-report

7. Record the lag

If php.net announcement UI still shows 8.5.8 while production is already on 8.5.9, write that down. Future you will thank present you when someone claims “official site says we should still be on 8.5.8.”

How this connects to the rest of your maintenance system

Runtime patching is not a special snowflake. It is one more contract next to:

• dashboard chart adoption contracts — a package bump is not a product decision until license, fixtures, and rollback are explicit
• schema changes AI agents must not freestyle — expand/contract discipline before contraction
• rollback paths for AI-authored code — recovery evidence before merge
• Laravel/Vue SaaS operating notes — where multi-surface maintenance shows up in real products
• AI agent operations hub — if agents propose infra changes, they still owe inventories and verify steps

If coding agents help open the PR that bumps a base image, force them through the same map: named surfaces, digests, php -v evidence, and a rollback digest. A model that rewrites a Dockerfile without listing worker/scheduler siblings is drafting theater.

What you should do Monday morning

1. Open the primary NEWS for php-8.5.9 and paste the PGSQL / BCMath / GD / Phar security lines into your ticket. No secondary blog paraphrase as source of truth.
2. Create php-surfaces.yaml (or a spreadsheet) with web, worker, scheduler, CI, bastion rows. Blank owner = blocked.
3. Probe live versions with php -r 'echo PHP_VERSION;' on each surface. Store stdout in the ticket.
4. Rebuild CI image first, then app/worker images, pinning digests after verification.
5. Run Laravel smoke on staging: auth write path, one queue job, one schedule command, ops:php-runtime-report --json.
6. Roll production only when probes match 8.5.9.x everywhere that serves or processes production data.
7. Close the CVE ticket only after evidence files exist — not after a single green Deploy comment.
8. Schedule a 48h follow-up to re-check any autoscaling templates or launch templates that can recreate old AMIs.

Further reading

Source php-src NEWS — PHP 8.5.9 (includes CVE-2026-17543)

Source php.net releases JSON (announcement surface; may lag tarball)

Source Laravel database configuration (pgsql driver)

Internal hubs worth keeping open while you patch:

• /developer-tools/
• /laravel-vue-saas/
• /start-here/

PHP security releases reward teams that treat the binary as a product dependency with multiple install sites. Laravel application deploys remain necessary. They are not sufficient. CVE-2026-17543 closes when the inventory closes — CI image, base container, worker, scheduler, and the host that still answers php -v with yesterday’s build.