fix: ignore CVE-2026-69246 and CVE-2026-54133 for 10.16.4 and 11.0.0

[DeepDiver1975]

Docker CI has been red on master since the 2026-08-09 nightly. Two independent, newly published advisories are matching dependencies vendored inside the pinned ownCloud release tarballs. Nothing in this repo changed.

The scan runs with severity: HIGH,CRITICAL and exit-code: 1, so the step exits 1 and matrix fail-fast cancels the sibling job. That is why only the 10.16.4 job ever reported a failure while 11.0.0 kept showing up as cancelled — and why the second CVE below only became visible once the first was suppressed.

1. CVE-2026-69246 — guzzle (HIGH, CVSS 7.2) — both images

GHSA-v5mv-p594-2x33, "Guzzle: Noncanonical host can bypass host-based checks", published 2026-08-03 21:07 UTC — one day after the last green run on 2026-08-02. Fixed upstream in guzzlehttp/guzzle 7.15.2 / 8.0.1.

Date	Docker CI on master
2026-08-02 18:10	last green run (both jobs, all Trivy targets 0)
2026-08-03 21:07	advisory published
2026-08-09 00:39	first red run — every run since is red

10.16.4 hits it in four bundles:

Bundle	guzzle
lib/composer (core)	7.10.0
apps/graphapi	7.4.5
apps/files_external_dropbox	7.8.1
updater	7.9.2

11.0.0 is affected too, which the perpetually cancelled job had never revealed. Its core lib already ships the fixed 7.15.2, but apps/files_external_dropbox vendors 7.15.1 — so it would have gone red as soon as 10.16.4 stopped shadowing it. Verified by extracting the composer installed.json files from the pinned v11.0.0 tarball. Both matrix entries therefore need the ignore.

2. CVE-2026-54133 — jmespath.php (CRITICAL, CVSS 9.8) — 10.16.4 only

GHSA-pcw8-m77r-2528, "jmespath.php has CompilerRuntime code injection via unescaped function names", published 2026-08-18 20:16 UTC — three hours before yesterday's failing run, whose scanner DB had not yet picked it up. It surfaced only after the guzzle ignore turned those four targets green.

It matches mtdowling/jmespath.php 2.8.0, pulled in by the aws-sdk-php 3.337.3 that files_primary_s3 vendors. Only 10.16.4 is affected — 11.0.0 ships aws-sdk-php 3.388.9 with jmespath.php 2.9.2, already above the fixed 2.9.1, so its ignore file is deliberately left alone.

Despite the 9.8 score, the finding is not reachable in this image:

• JmesPath\Env::createRuntime() returns the unaffected AstRuntime unless JP_PHP_COMPILE is set. It is set nowhere in the Dockerfiles or overlays, so reaching the vulnerable CompilerRuntime at all requires an operator to inject it deliberately.
• Every search() call site in the bundled SDK passes an SDK-internal literal or service-model-derived expression — 'Parts[0].Size', waiter acceptor arguments, paginator output tokens — never caller input, let alone attacker input.
• The advisory itself states the default AstRuntime "is not affected unless JP_PHP_COMPILE is enabled", and that the searched data document alone is insufficient: the attacker must control the expression string.

That reasoning is recorded in the ignore file so the entry is not mistaken for a blanket suppression of a critical.

Why ignores

This repo builds from an immutable, tag-pinned release tarball, so it cannot bump either vendored library. ignore-unfixed does not help — both CVEs are fixed upstream, just not in ownCloud's bundle. The ignores follow the existing precedent in these files for GHSA-27qh-8cxx-2cr5 (aws-sdk-php) and CVE-2026-44167, and the comments record the affected bundles and versions so the entries can be dropped once ownCloud ships the bumps.

These are first mitigations to get the pipeline moving again, not fixes. The guzzle advisory is a genuine host-check bypass; the intent is to carry that bump in a 10.16.5. The jmespath fix is the same one the neighbouring GHSA-27qh-8cxx-2cr5 entry is already waiting on: an aws-sdk-php update, which 11.0.0 has had and 10.16.x has not. There is currently no issue or PR in the owncloud org tracking either.

Verification

Neither suppression could be verified locally — the local Trivy DB is frozen at 2026-06-05, before both advisories, so it does not know either ID. CI is the verification, and it is now green: both Trivy scan steps and both Smoke test steps pass, with every Trivy target reporting 0. Notably the 11.0.0 job completed for the first time since 2026-08-02, confirming nothing else had accumulated behind the fail-fast cancellation. Publish steps are skipped on PRs by design.

Worth flagging

Two independent CVEs landed against dependencies frozen inside a tag-pinned tarball within twelve hours of each other, and each one took the whole publish pipeline down until an ignore was added by hand. That cadence is a property of gating publishes on a scanner whose input this repo cannot change, and it will recur.

🤖 Generated with Claude Code