Request
Two things for the 8.2 line:
- 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.
- 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:
| Advisory |
Dependency |
v8.2.0 (released) |
Fixed in |
stable-8.2 today |
| CVE-2026-56854 (CRITICAL) |
golang.org/x/crypto |
v0.54.0 |
0.55.0 |
v0.55.0 ✅ |
| CVE-2026-46603 (HIGH) |
golang.org/x/image |
v0.44.0 |
0.45.0 |
v0.45.0 ✅ |
| CVE-2026-84304 (HIGH) |
google.golang.org/grpc |
v1.82.1 |
1.83.1 |
v1.83.0 ❌ |
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:
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
| Line |
Latest release |
Affected by the three above? |
| 8.0 |
v8.0.8 (2026-08-21) |
no — ships x/crypto v0.55.0, x/image v0.45.0, grpc v1.83.1 |
| 8.1 |
v8.1.0 (2026-07-06) |
yes, all three — see #12810 |
| 8.2 |
v8.2.0 (2026-08-10) |
yes, all three — this issue |
| master |
— |
no |
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.
Request
Two things for the 8.2 line:
google.golang.org/grpcfrom v1.83.0 to v1.83.1 onstable-8.2. This is the oneadvisory in this report that is not yet fixed on the branch.
v8.2.0(2026-08-10) is the only 8.2 release and it carriesthe
latesttag, so every fix already merged onstable-8.2is currently unreachable foranyone tracking 8.2.
Why
Our Trivy gate in owncloud-docker/ocis scans the
ocisbinary inside the image it just built. Three advisories currently apply, and the released
v8.2.0is below the fix version for all three:
v8.2.0(released)stable-8.2todaygolang.org/x/cryptogolang.org/x/imagegoogle.golang.org/grpcEvery version above was read directly from
go.modat the respective ref, not inferred.golang.org/x/crypto/ssh: authentication bypass due to unenforcedsource-address restrictions
golang.org/x/image/vp8l: denial of service via excessive memory allocationWhat is already done, and the one gap
stable-8.2picked up two of the three fixes as normal maintenance, so most of this is just arelease-timing ask:
chore: [stable-8.2] bump go and web packages, 2026-08-12) took grpc v1.82.1 → v1.83.0security: bump golang.org/x/image to v0.45.0, 2026-08-18) took x/image v0.44.0 → v0.45.0chore(deps): bump golang.org/x/mod to v0.40.0, 2026-08-26) also took x/crypto v0.54.0 → v0.55.0The 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.2is one patch short. For comparison,master,stable-8.0andstable-8.1all 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.1is fully fixed, just never tagged); I have added these threeadvisories 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,:8and:latestcannot bepublished green while
v8.2.0is the build input. The only way to keep publishing them would beto 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
latesttag. That file iscurrently 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:
The 8.2 leg of that same run never reached its Trivy step — our build matrix had
fail-fastatits default, so the 8.1 failure cancelled it. The 8.2 exposure above is therefore derived from
go.modatv8.2.0rather than from an observed scan. I am fixing thefail-fastbehaviour onour 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/sshinparticular 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.mdasks that vulnerabilities not be filed as public issues, and I want to be explicitthat 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.2tag handling around itinstead.