8.2 line: three CVEs in released v8.2.0; stable-8.2 still short of the grpc fix #12903

Request

Two things for the 8.2 line:

1. Bump google.golang.org/grpc from v1.83.0 to v1.83.1 on stable-8.2. This is the one
   advisory in this report that is not yet fixed on the branch.
2. Cut an 8.2.1 patch release. v8.2.0 (2026-08-10) is the only 8.2 release and it carries
   the latest tag, so every fix already merged on stable-8.2 is currently unreachable for
   anyone tracking 8.2.

Why

Our Trivy gate in owncloud-docker/ocis scans the ocis
binary inside the image it just built. Three advisories currently apply, and the released v8.2.0
is below the fix version for all three:

Every version above was read directly from go.mod at the respective ref, not inferred.

• CVE-2026-56854 — golang.org/x/crypto/ssh: authentication bypass due to unenforced
  source-address restrictions
• CVE-2026-46603 — golang.org/x/image/vp8l: denial of service via excessive memory allocation
• CVE-2026-84304 — gRPC-Go, affecting versions prior to 1.83.1

What is already done, and the one gap

stable-8.2 picked up two of the three fixes as normal maintenance, so most of this is just a
release-timing ask:

• chore: [stable-8.2] bump go and web packages #12775 (chore: [stable-8.2] bump go and web packages, 2026-08-12) took grpc v1.82.1 → v1.83.0
• security: bump golang.org/x/image to v0.45.0 #12806 (security: bump golang.org/x/image to v0.45.0, 2026-08-18) took x/image v0.44.0 → v0.45.0
• chore(deps): bump golang.org/x/mod to v0.40.0 #12848 (chore(deps): bump golang.org/x/mod to v0.40.0, 2026-08-26) also took x/crypto v0.54.0 → v0.55.0

The gap is grpc. The bump in #12775 landed on v1.83.0, and CVE-2026-84304 is only fixed in
v1.83.1 — so stable-8.2 is one patch short. For comparison, master, stable-8.0 and
stable-8.1 all already sit on v1.83.1.

How the other lines compare

8.0 is the only line whose newest release is clean. 8.1 is a pure release-cadence problem already
tracked in #12810 (stable-8.1 is fully fixed, just never tagged); I have added these three
advisories to that thread. 8.2 is filed separately because it needs an actual dependency bump
first.

Downstream impact

Our Trivy gate scans the built binary, so owncloud/ocis:8.2, :8 and :latest cannot be
published green while v8.2.0 is the build input. The only way to keep publishing them would be
to carry all three advisories as suppressions in
v8/8.2/.trivyignore,
which is exactly the kind of thing we would rather not ship on the latest tag. That file is
currently empty and we would like to keep it that way.

One caveat on the evidence: the failure we can point at is the 8.1 leg of
run 34207664511,
which reports exactly these three advisories against the 8.1.0 binary:

usr/bin/ocis (gobinary)
Total: 3 (HIGH: 2, CRITICAL: 1)

golang.org/x/crypto     CVE-2026-56854  CRITICAL  v0.52.0  -> 0.55.0
golang.org/x/image      CVE-2026-46603  HIGH      v0.43.0  -> 0.45.0
google.golang.org/grpc  CVE-2026-84304  HIGH      v1.81.1  -> 1.83.1

The 8.2 leg of that same run never reached its Trivy step — our build matrix had fail-fast at
its default, so the 8.1 failure cancelled it. The 8.2 exposure above is therefore derived from
go.mod at v8.2.0 rather than from an observed scan. I am fixing the fail-fast behaviour on
our side so the 8.2 leg reports its own status, and will post that scan here once it runs.

On reachability

Trivy resolves module versions from the Go binary's build metadata and does not do reachability
analysis, so it does not claim any of this is exploitable in oCIS — golang.org/x/crypto/ssh in
particular may well never be reached. That does not change the gate's behaviour, though, and the
two honest ways out are a version bump or a published VEX statement (Trivy suggests the latter
itself in the scan output). A bump seems much simpler here, especially as two of the three are
already done.

A note on the channel

SECURITY.md asks that vulnerabilities not be filed as public issues, and I want to be explicit
that I do not think this is one: all three advisories are already public, all three sit in public
third-party dependencies, two are already fixed on a public branch, and the actual ask is a
one-line dependency bump plus release timing. Nothing undisclosed is revealed here. Happy to move
this to security.owncloud.com if you would prefer.

If 8.2 is not receiving patch releases

If the intent is that 8.2 users wait for the next feature release rather than an 8.2.1, please
just say so — that is a fine answer, and we would plan the latest/8.2 tag handling around it
instead.