fix(worker): accept the cosign x/text DoS until upstream rebuilds - #538
Merged
Conversation
CVE-2026-56852 landed in Trivy's database and turned the required image-scan gate red on every branch. It is a denial of service in golang.org/x/text's `norm.Iter`, reached through the cosign binary the worker image carries for SBOM signing. There is nothing to bump to. The fix is x/text 0.39.0, and cosign v3.1.2 — released 2026-07-17, the newest upstream build — still pins `golang.org/x/text v0.38.0 // indirect`, as does the v3.1.1 we ship. That is category 2 of the .trivyignore policy: patched upstream, not yet in a release of the vendored tool. The reach analysis is in the entry, and the short version is that the only thing cosign parses here is a file the worker wrote seconds earlier. It runs as a CLI, once per scan, over the portal's own CycloneDX SBOM; no untrusted text is normalised, and x/text is an indirect dependency our invocation does not feed. The DoS itself is bounded even if that reasoning is wrong: `sign_blob` runs under COSIGN_TIMEOUT_SECONDS (120s by default), after which signing is skipped and recorded, so a spinning subprocess cannot take the scan budget with it. Re-evaluate on the next cosign release built with x/text >= 0.39.0, or 2026-10-29, whichever comes first — the entry says how to check.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CVE-2026-56852 was published into Trivy's database and turned
image-scan (worker)— a required check — red on every branch, including PRs that touch nothing near the image. First seen on #537, whose diff contains no Dockerfile and no dependency change.Why not bump
The finding is
golang.org/x/text v0.38.0insideusr/local/bin/cosign. The fixed version is 0.39.0, and no cosign release is built against it:v3.1.2 (2026-07-17) is the newest upstream release, so bumping
COSIGN_VERSIONmoves the pin without clearing the finding. That is category 2 of the.trivyignorepolicy — patched upstream, not yet in a release of the vendored tool — the same situation as the grpc entry directly above it.Reach
cosign sign-blobis invoked as a CLI, once per scan, over a blob the worker itself just wrote: the portal-generated CycloneDX SBOM (integrations/cosign.py). No untrusted text is normalised, and x/text is an indirect dependency of cosign that our invocation gives nothing to.The vulnerability is a denial of service —
norm.Iterspinning on malformed UTF-8 — with no disclosure and no execution. Even granting reachability, the blast radius is one subprocess:sign_blobruns underCOSIGN_TIMEOUT_SECONDS(120s default,core/config.py), after which the signing step is skipped and recorded, so a hung cosign cannot eat the scan budget.Expiry
The entry carries the check command and a re-evaluation date: the next cosign release built with x/text >= 0.39.0, or 2026-10-29, whichever is sooner. A rebuild drops the finding automatically once upstream ships one.