Repository navigation
Request 8.1.1 patch release: four HIGH CVEs fixed on stable-8.1 but unreleased #12810
Description
Activity
Should be released now, right? Close? @2403905
Should be released now, right? Close? @2403905
Right. Confused it with this one - owncloud-docker/ocis#40 (8.0.8)
Three further advisories now apply to
v8.1.0, taking this from four to seven, and one of the
new ones is CRITICAL. As before,stable-8.1already carries every fix — the ask is unchanged,
just more urgent.Advisory Dependency v8.1.0(released)Fixed in stable-8.1todayCVE-2026-56854 (CRITICAL) golang.org/x/cryptov0.52.0 0.55.0 v0.55.0 ✅ CVE-2026-46603 (HIGH) golang.org/x/imagev0.43.0 0.45.0 v0.45.0 ✅ CVE-2026-84304 (HIGH) google.golang.org/grpcv1.81.1 1.83.1 v1.83.1 ✅ - 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
Note that CVE-2026-84304 is a second grpc advisory on top of the GHSA-hrxh-6v49-42gf row in the
original table:stable-8.1was on v1.83.0 when I filed this, which cleared that one, and has
since moved to v1.83.1, which clears this one too. Versions above were read fromgo.modat each
ref.Evidence — the 8.1 leg of
run 34207664511
(amd64; the arm64 leg is identical):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.1This gate has been red since 2026-09-02 (CVE-2026-56854 and CVE-2026-84304 in run
33599994938, CVE-2026-46603 joining later the same day in run33682286181); the last green
Docker CI run was33287805400on 2026-08-30. Because the 8.1 leg is part of a shared build
matrix, it has been failing every unrelated PR in that repo too — the run linked above is a
Renovatedocker.io/golangbump.I have deliberately not added these three to
v8/8.1/.trivyignore
yet — the existing four suppressions are already more than I would like to ship, and a CRITICAL is
not something I want to paper over silently.Related: the same three advisories also apply to the released
v8.2.0, which carries thelatest
tag. I have filed that separately as #12903, because unlike 8.1 it needs an actual dependency bump
first (stable-8.2is still on grpc v1.83.0, one patch short of the v1.83.1 fix).@2403905 — is an 8.1.1 still on the table, or should we plan on retiring the
8.1image tag?
Either answer works for us; the current state is just the one we cannot act on.- CVE-2026-56854 —
- added a commit that references this issue
on Sep 15, 2026 Update from run 34955346272 (2026-09-15)
A fresh Trivy scan of the still-unreleased
v8.1.0image (amd64) surfaces one more advisory on top of the four already listed above:Advisory Dependency v8.1.0 (released) Fixed in stable-8.1todayCVE-2026-84445 (HIGH) — new google.golang.org/grpcv1.82.1 1.82.2, 1.83.2, or 1.85.0-dev v1.83.2 ✅ Same story as the other four:
stable-8.1already carries the fix (v1.83.2, same bump that fixed the grpc advisory already in the table above), it just hasn't reached a release. This doesn't change the ask — it just makes it a 5-advisory case instead of 4.(Version read directly from
go.modonstable-8.1, not inferred.)Restating the original request: please cut 8.1.1 from
stable-8.1.
Request
Please consider cutting an 8.1.1 patch release from
stable-8.1.Why
stable-8.1already contains the fixes for four HIGH-severity advisories, but none of themhave reached a released artifact: v8.1.0 (2026-07-06) is still the only 8.1 release.
Anyone tracking the 8.1 line therefore runs a binary with all four, even though the 8.0 and
8.2 lines are clean (8.0.7 and 8.2.0 both ship the fixed dependency set).
Versions below were read directly from
go.modat each ref:stable-8.1todaygolang.org/x/netgolang.org/x/textgoogle.golang.org/grpcgithub.com/go-git/go-git/v5Nothing to fix on the dependency side
This is purely a release-cadence request — the work is already done. #12774
("chore: [stable-8.1] bump go packages", merged 2026-08-12) bumped every affected module,
and the branch is clearly maintained (backports through 2026-08-14, plus #12807 bumping
golang.org/x/imagetoday). The fixes just need a tag.Downstream impact
I maintain the container images in owncloud-docker/ocis.
Our Trivy gate scans the built
ocisbinary, so to keep publishingowncloud/ocis:8.1atall we have to carry all four advisories as suppressions in
v8/8.1/.trivyignore(most recently CVE-2026-46600, in owncloud-docker/ocis#37 — it was breaking our nightly
build). Those entries are the only reason the 8.1 image is green, and they are exactly the
kind of suppression we would rather not ship. An 8.1.1 would let us drop all four.
For reference, the same scan on the 8.0.7 and 8.2.0 images is clean, and
masteris cleantoo — 8.1 is the only line where fixes are sitting unreleased.
If 8.1 is not a maintained line
If the intent is that 8.1 users move to 8.2 rather than receive patches, please just say so
and close this — that is a perfectly good answer. We would then retire the
8.1image taginstead of maintaining the suppression list.
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: every advisory here is already public, sits in a
public third-party dependency, and is already fixed on a public branch. Nothing
undisclosed is revealed, and the actual ask is about release timing. Happy to move this to
security.owncloud.com if you would prefer.