xk6: bump grpc-go to v1.83.1 for GHSA-vp52-pcj8-j9qc

[Copilot]

Tl;dr: Upgrade google.golang.org/grpc in long-running-test-arch/xk6 from v1.83.0 to patched v1.83.1 to resolve CVE-2026-84304 / GHSA-vp52-pcj8-j9qc.

Context:

The alert targets gRPC-Go receive-path memory exhaustion via fragmented inbound HTTP/2 DATA frames. This change applies the lowest patched version (v1.83.1) with minimal blast radius in the affected Go module.

• Dependency remediation

  • Updated /long-running-test-arch/xk6/go.mod:
    • google.golang.org/grpc v1.83.0 → v1.83.1 (indirect)
  • Refreshed /long-running-test-arch/xk6/go.sum with v1.83.1 checksums via Go tooling.

• Reachability assessment (GHSA-vp52-pcj8-j9qc)

  • Module usage is outbound OTLP metrics export (otlpmetricgrpc.New(...) in long-running-test-arch/xk6/k6_otel.go).
  • No gRPC server/listener or inbound stream handling was found in this module.
  • Assessment: vulnerable inbound fragmentation path is not clearly reachable here; upgrade is primarily scanner-driven hardening.
  • Confidence: High.

// long-running-test-arch/xk6/go.mod
google.golang.org/grpc v1.83.1 // indirect

Test Plan:

• cd long-running-test-arch/xk6 && go test ./...
• cd long-running-test-arch/xk6 && go list -m google.golang.org/grpc (confirms v1.83.1)

Test services data

1. e-1712644058766987264
2. e-1712643928659124224
3. e-1742334541200846848
4. e-1777406072376840192

Original prompt

---

This section details the Dependabot vulnerability alert you should resolve

<alert_title>gRPC-Go: Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation</alert_title>
<alert_description>### Impact
An unauthenticated remote attacker can initiate a gRPC stream and purposefully fragment their payload into millions of tiny (e.g., 1-byte) HTTP/2 DATA frames. Even if the total payload volume falls within the configured connection and stream flow-control windows, each independent fragment incurs memory overhead due to internal tracking structures and queue allocation.

Repeated fragmentation massively inflates the heap space consumed by the stream. An attacker multiplexing multiple concurrent streams can exhaust the memory bounds of the runtime, forcing a runtime panic or OutOfMemory condition and leading to a remote Denial of Service (DoS).

Patches

The change to fix this issue is merged in master and a patch release, 1.83.1, has been published that contains this fix.

Workarounds

This vulnerability is mitigated by implementing receive buffer compaction. Consecutive small data buffers are automatically coalesced into larger buffers from a shared pool once the overhead is perceived to be excessive relative to actual payload data, drastically minimizing per-frame memory overheads.

This behavior is enabled by default. A temporary escape hatch is provided via the environment variable GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION=false to disable the feature if unforeseen issues arise, but it will be removed in a future release.</alert_description>

high
GHSA-vp52-pcj8-j9qc, CVE-2026-84304
google.golang.org/grpc
go
<vulnerable_versions>= v1.83.0</vulnerable_versions>
<patched_version>1.83.1</patched_version>
<manifest_path>long-running-test-arch/xk6/go.mod</manifest_path>

https://github.com/grpc/grpc-go/security/advisories/GHSA-vp52-pcj8-j9qc https://nvd.nist.gov/vuln/detail/CVE-2026-84304 https://github.com/grpc/grpc-go/pull/9331 https://github.com/grpc/grpc-go/pull/9333 https://github.com/grpc/grpc-go/commit/7354d9c8debb4bcf2225bf429857078de310c176 https://github.com/grpc/grpc-go/commit/8cfeca0e1ee5ea0980dcc320e20240fa1079ec77 https://github.com/grpc/grpc-go/releases/tag/v1.83.1 https://github.com/advisories/GHSA-vp52-pcj8-j9qc

<task_instructions>Resolve this alert by updating the affected package to a non-vulnerable version. Prefer the lowest non-vulnerable version (see the patched_version field above) over the latest to minimize breaking changes. Include a Reachability Assessment section in the PR description. Review the alert_description field to understand which APIs, features, or configurations are affected, then search the codebase for usage of those specific items. If the vulnerable code path is reachable, explain how (which files, APIs, or call sites use the affected functionality) and note that the codebase is actively exposed to this vulnerability. If the vulnerable code path is not reachable, explain why (e.g. the affected API is never called, the vulnerable configuration is not used) and note that the update is primarily to satisfy vulnerability scanners rather than to address an active risk. If the advisory is too vague to determine reachability (e.g. 'improper input validation' with no specific API named), state that reachability could not be determined and explain why. Include a confidence level in the reachability assessment (e.g. high confidence if the advisory names a specific API and you confirmed it is or is not called, low confidence if the usage is indirect and hard to trace). If no patched version is available, check the alert_description field for a Workarounds section — the advisory may describe configuration changes or usage patterns that mitigate the vulnerability without a version update. If a workaround is available, apply it and leave a code comment referencing the advisory identifier explaining it is a temporary mitigation. If neither a patch nor a workaround is available, explain in the PR description why the alert cannot be resolved automatically so a human reviewer can take over. Inspect the repository to determine which package manager is used (e.g. lock files, config files, build scripts) and use that tooling to perform the update — do not edit lock files directly. If the version constraint in the manifest (e.g. package.json, Gemfile, pyproject.toml) caps the version below the fix, update the constraint first. For transitive dependencies, determine whether it is simpler to update the direct dependency that pulls in the vulnerable package or to update the transitive dependency directly, and choose the least disruptive approach. If upgrading to fix the vulnerability forces a major version bump or known breaking changes, review the change...

• Resolves solarwinds/apm-java alert Clean up the repo #12

[Copilot]

🟡 Changes recommended

The vulnerable google.golang.org/grpc v1.83.0 still appears in go.sum, which may keep security/vulnerability checks failing despite the go.mod bump.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR upgrades the long-running-test-arch/xk6 Go module’s google.golang.org/grpc dependency from v1.83.0 to v1.83.1 to address GHSA-vp52-pcj8-j9qc / CVE-2026-84304 with minimal change scope in the xk6 OTLP exporter module.

Changes:

• Bump google.golang.org/grpc (indirect) to v1.83.1 in go.mod.
• Update go.sum with v1.83.1 checksums.

File summaries

File	Description
long-running-test-arch/xk6/go.mod	Pins google.golang.org/grpc to the patched v1.83.1 (indirect) for the xk6 module.
long-running-test-arch/xk6/go.sum	Adds checksum entries for google.golang.org/grpc v1.83.1 (but currently retains v1.83.0 entries as well).

Review details

• Files reviewed: 1/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.