l3montree-dev / l3montree-dev/devguard

GHSA-vp52-pcj8-j9qc found in golang/google.golang.org/grpc@v1.80.0

Open Beginner friendly
#3,007 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

cvss-severity:high devguard l3montree-cybersecurity/...ard-k8s-image-inventory pkg:oci/devguard-k8s-ima...ch=amd64&tag=main-amd64 pkg:oci/devguard-k8s-ima...ch=arm64&tag=main-arm64 risk:low state:open
Dominant language
Go
Stars
161
Forks
43
Avg merge
1d 8h
Merged PRs (30d)
37

Description

GHSA-vp52-pcj8-j9qc found in golang/google.golang.org/grpc@v1.80.0

[!important]
Risk: 2.26 (Low)
CVSS: 8.7

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.

Affected component

The vulnerability is in pkg:golang/google.golang.org/grpc@v1.80.0, found in artifacts pkg:oci/devguard-k8s-image-inventory?repository_url=ghcr.io/l3montree-dev/devguard-k8s-image-inventory&arch=amd64&tag=main-amd64, pkg:oci/devguard-k8s-image-inventory?repository_url=ghcr.io/l3montree-dev/devguard-k8s-image-inventory&arch=arm64&tag=main-arm64.

Recommended fix

Upgrade to version v1.83.1 or later.

# Update all golang packages
go get -u ./... 
# Update only this package
go get grpc@v1.83.1 
Additional guidance for mitigating vulnerabilities

Visit our guides on devguard.org

See more details...
Path to component
 %%{init: { 'theme':'base', 'themeVariables': {
'primaryColor': '#F3F3F3',
'primaryTextColor': '#0D1117',
'primaryBorderColor': '#999999',
'lineColor': '#999999',
'secondaryColor': '#ffffff',
'tertiaryColor': '#ffffff'
} }}%%
 flowchart TD
Your_application(["Your application"]) --- pkg_golang_google_golang_org_grpc_v1_80_0(["pkg:golang/google.golang.org/grpc\@v1.80.0"])

classDef default stroke-width:2px
Risk Factor Value Description
Vulnerability Depth 1 The vulnerability is in a direct dependency of your project.
EPSS 0.41 % The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
EXPLOIT Not available We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database. There are no script kiddies exploiting this vulnerability.
CVSS-BE 7.9
CVSS-B 8.7 - The vulnerability can be exploited over the network without needing physical access.
- It is easy for an attacker to exploit this vulnerability.
- An attacker does not need any special privileges or access rights.
- No user interaction is needed for the attacker to exploit this vulnerability.

More details can be found in DevGuard


Interact with this vulnerability

You can use the following slash commands to interact with this vulnerability:

👍 Reply with this to acknowledge and accept the identified risk.
/accept I accept the risk of this vulnerability, because ...
⚠️ Mark the risk as false positive: Use one of these commands if you believe the reported vulnerability is not actually a valid issue.
/component-not-present The vulnerable component is not included in the artifact.
/vulnerable-code-not-present The component is present, but the vulnerable code is not included or compiled.
/vulnerable-code-not-in-execute-path The vulnerable code exists, but is never executed at runtime.
/vulnerable-code-cannot-be-controlled-by-adversary Built-in protections prevent exploitation of this vulnerability.
/inline-mitigations-already-exist The vulnerable code cannot be controlled or influenced by an attacker.
🔁 Reopen the risk: Use this command to reopen a previously closed or accepted vulnerability.
/reopen ... 

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by checking the Go dependency configuration for google.golang.org/grpc and run the targeted update command shown in the issue. Done means the project uses gRPC v1.83.1 or later and the vulnerability is no longer reported for the affected artifacts.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, grpc
Domain
backend, security
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.