security: add govulncheck CI and fix 4 active vulnerabilities

[andrewkroh]

Proposed commit message

security: add govulncheck CI and fix 4 active vulnerabilities

Add a govulncheck GitHub Actions workflow that runs on pull requests and
pushes to main. The workflow uses golang/govulncheck-action to detect
vulnerabilities in the call graph (not just the module graph), so it only
alerts on code paths that are actually reachable.

Upgrade three modules to eliminate all four confirmed vulnerabilities:

- google.golang.org/grpc v1.62.1 → v1.82.1 (GO-2026-6061)
- golang.org/x/net v0.47.0 → v0.55.0 (GO-2026-4918, GO-2026-5026)
- golang.org/x/text v0.32.0 → v0.39.0 (GO-2026-5970)

All four vulnerabilities were reachable through the webhook and GCP
PubSub outputs. See the PR description for per-vulnerability impact
analysis.

Vulnerability impact analysis

All four CVEs were confirmed reachable by govulncheck — meaning the
vulnerable code paths are actually called by this codebase, not just
present in the module graph.

GO-2026-6061 — grpc: xDS RBAC / HTTP/2 transport server (grpc v1.62.1 → v1.82.1)

Impact: Two distinct issues in grpc's HTTP/2 implementation.
Users of the GCP PubSub output (-output=gcppubsub) are affected
because the pubsub client internally uses gRPC over HTTP/2. An attacker
who controls the pubsub endpoint (e.g. via a MITM on an unencrypted or
misconfigured connection) could trigger the transport vulnerability.
The webhook output is also affected via its HTTP client, which gRPC
internally reuses.

Concrete scenario: A process running stream -output=gcppubsub talks
to a malicious or compromised gRPC server; the server sends a crafted
response that exploits the HTTP/2 transport bug, causing stream to crash
or behave incorrectly.

GO-2026-4918 — x/net: infinite loop on bad SETTINGS_MAX_FRAME_SIZE (x/net v0.47.0 → v0.53.0)

Impact: The HTTP/2 transport enters an infinite loop when the server
sends a SETTINGS frame with an invalid MAX_FRAME_SIZE. Users of the
webhook output (-output=webhook) sending data to an HTTP/2 server
are affected. A malicious webhook target can send a single crafted
SETTINGS frame and hang the stream process indefinitely (DoS).

Concrete scenario: stream -output=webhook --addr=https://evil.example
— the server responds with SETTINGS MAX_FRAME_SIZE=0, stream's HTTP/2
client loops forever, consuming 100% CPU and never delivering events.

GO-2026-5026 — x/net/idna: ASCII-only Punycode label not rejected (x/net v0.47.0 → v0.55.0)

Impact: idna.ToASCII fails to reject labels that are purely
ASCII-encoded Punycode (e.g. xn--nxasmq6b.com when that decodes to
something that should be blocked). This is reachable through
http.Client.Do in the webhook output. A crafted webhook URL could
bypass IDNA validation and resolve to an unexpected host, potentially
enabling SSRF or host-confusion attacks in environments where the webhook
URL is user-controlled.

GO-2026-5970 — x/text: infinite loop on invalid input in text normalizer (x/text v0.32.0 → v0.39.0)

Impact: Passing certain malformed byte sequences to norm.Form
functions triggers an infinite loop. This is reachable via
http.Client.Do in the webhook output when Go's net/http stack
normalizes headers or URLs containing non-UTF-8 byte sequences. An
attacker who can inject such a sequence into a header value (e.g. via
event data that gets forwarded as an HTTP header) can hang the stream
process.

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: d13ee4d