Vulnerability-Lookup

Vulnerability from cleanstart

Published

2026-08-13 12:10

Modified

2026-08-14 05:57

Summary

Security fixes in cosign 3.1.2-r1

Details

Package cosign version 3.1.2-r1 fixes 9 vulnerabilities: CVE-2026-54787, ghsa-hrxh-6v49-42gf, ghsa-259r-337f-4rfw, CVE-2026-49835, ghsa-9c54-x2g4-v92j...

References

URL

Type

https://github.com/sigstore/cosign

WEB

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Alpine",
        "name": "cosign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2-r1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.1.2-r1"
      ]
    }
  ],
  "credits": [],
  "database_specific": {},
  "details": "Package cosign version 3.1.2-r1 fixes 9 vulnerabilities: CVE-2026-54787, ghsa-hrxh-6v49-42gf, ghsa-259r-337f-4rfw, CVE-2026-49835, ghsa-9c54-x2g4-v92j...",
  "id": "CLEANSTART-2026-SK52724",
  "modified": "2026-08-14T05:57:58Z",
  "published": "2026-08-13T12:10:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign"
    }
  ],
  "related": [],
  "schema_version": "1.7.3",
  "summary": "Security fixes in cosign 3.1.2-r1",
  "upstream": [
    "CVE-2026-54787",
    "ghsa-hrxh-6v49-42gf",
    "ghsa-259r-337f-4rfw",
    "CVE-2026-49835",
    "ghsa-9c54-x2g4-v92j",
    "CVE-2026-49834",
    "ghsa-9vcr-p3rj-q5q6",
    "CVE-2026-48702",
    "ghsa-47q9-m4ww-924m"
  ]
}

CVE-2026-48702 (GCVE-0-2026-48702)

Vulnerability from cvelistv5 – Published: 2026-08-13 13:14 – Updated: 2026-08-13 15:16

Title

Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic

Summary

Rekor is a software supply chain transparency log. Starting in version 0.3.0 and prior to version 1.5.2, the `Package.Unmarshal()` function in `pkg/types/alpine/apk.go` decompresses the signature and control gzip members of an APK file into in-memory buffers without bounding the total decompressed size. The existing `max_apk_metadata_size` check (default 1MB) is only applied to individual tar entry header sizes after decompression completes, so it does not prevent a decompression bomb from consuming unbounded heap memory. An attacker can craft a gzip stream that compresses at a ~1000:1 ratio (e.g., 2MB compressed zeros → 2GB decompressed). When submitted as spec.package.content in an Alpine `ProposedEntry`, the server decompresses the full payload into memory during request processing, triggering a fatal Go runtime out-of-memory error or OS OOM-kill that cannot be caught by the server's recover() middleware. This is reachable via two unauthenticated endpoints, `POST /api/v1/log/entries (createLogEntry)` and `POST /api/v1/log/entries/retrieve (searchLogQuery)`. Both invoke `V001Entry.Canonicalize()` → `fetchExternalEntities()` → `apk.Unmarshal(packageData)`, which performs the unbounded decompression. Version 1.5.2 patches the issue. There is no effective workaround. Setting `max_request_body_size` reduces but does not eliminate exposure due to the ~1000:1 compression ratio (a 1MB body limit still allows ~1GB heap allocation). Setting `max_apk_metadata_size` has no effect on this vulnerability since the check is applied after decompression.

Severity

7.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

SSVC

Exploitation: none Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-08-13 15:12 UTC

CWE

CWE-770 - Allocation of Resources Without Limits or Throttling

Assigner

GitHub_M

References

1 reference

URL	Tags
https://github.com/sigstore/rekor/security/adviso…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
sigstore	rekor	Affected: >= 0.3.0, < 1.5.2

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-48702",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-13T15:12:38.632066Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-13T15:16:26.293Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "rekor",
          "vendor": "sigstore",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 0.3.0, \u003c 1.5.2"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Rekor is a software supply chain transparency log. Starting in version 0.3.0 and prior to version 1.5.2, the `Package.Unmarshal()` function in `pkg/types/alpine/apk.go` decompresses the signature and control gzip members of an APK file into in-memory buffers without bounding the total decompressed size. The existing `max_apk_metadata_size` check (default 1MB) is only applied to individual tar entry header sizes after decompression completes, so it does not prevent a decompression bomb from consuming unbounded heap memory. An attacker can craft a gzip stream that compresses at a ~1000:1 ratio (e.g., 2MB compressed zeros \u2192 2GB decompressed). When submitted as spec.package.content in an Alpine `ProposedEntry`, the server decompresses the full payload into memory during request processing, triggering a fatal Go runtime out-of-memory error or OS OOM-kill that cannot be caught by the server\u0027s recover() middleware. This is reachable via two unauthenticated endpoints, `POST /api/v1/log/entries (createLogEntry)` and `POST /api/v1/log/entries/retrieve (searchLogQuery)`. Both invoke `V001Entry.Canonicalize()` \u2192 `fetchExternalEntities()` \u2192 `apk.Unmarshal(packageData)`, which performs the unbounded decompression. Version 1.5.2 patches the issue. There is no effective workaround. Setting `max_request_body_size` reduces but does not eliminate exposure due to the ~1000:1 compression ratio (a 1MB body limit still allows ~1GB heap allocation). Setting `max_apk_metadata_size` has no effect on this vulnerability since the check is applied after decompression."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-13T13:14:19.324Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m"
        }
      ],
      "source": {
        "advisory": "GHSA-47q9-m4ww-924m",
        "discovery": "UNKNOWN"
      },
      "title": "Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-48702",
    "datePublished": "2026-08-13T13:14:19.324Z",
    "dateReserved": "2026-05-22T18:47:27.754Z",
    "dateUpdated": "2026-08-13T15:16:26.293Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-49834 (GCVE-0-2026-49834)

Vulnerability from cvelistv5 – Published: 2026-07-17 19:20 – Updated: 2026-07-17 19:42

Title

sigstore-go: Multi-log threshold bypass via single compromised log

Summary

sigstore-go is a Go library for Sigstore signing and verification. Prior to 1.2.0, a verifier configured with WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1) counts verified witnesses per entry or per validation path rather than per log authority, allowing a single compromised transparency log or CT log to satisfy multi-log threshold requirements and defeat the multi-log policy. This issue is fixed in version 1.2.0.

Severity

5.9 (Medium)


                        
                          CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-07-17 19:42 UTC

CWE

CWE-347 - Improper Verification of Cryptographic Signature

Assigner

GitHub_M

References

4 references

URL	Tags
https://github.com/sigstore/sigstore-go/security/…	x_refsource_CONFIRM
https://github.com/sigstore/sigstore-go/pull/633	x_refsource_MISC
https://github.com/sigstore/sigstore-go/commit/db…	x_refsource_MISC
https://github.com/sigstore/sigstore-go/releases/…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
sigstore	sigstore-go	Affected: < 1.2.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-49834",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-17T19:42:04.325650Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-17T19:42:17.005Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "sigstore-go",
          "vendor": "sigstore",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.2.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "sigstore-go is a Go library for Sigstore signing and verification. Prior to 1.2.0, a verifier configured with WithTransparencyLog(N\u003e1) or WithSignedCertificateTimestamps(N\u003e1) counts verified witnesses per entry or per validation path rather than per log authority, allowing a single compromised transparency log or CT log to satisfy multi-log threshold requirements and defeat the multi-log policy. This issue is fixed in version 1.2.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.9,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-347",
              "description": "CWE-347: Improper Verification of Cryptographic Signature",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-17T19:20:06.140Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6"
        },
        {
          "name": "https://github.com/sigstore/sigstore-go/pull/633",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/sigstore-go/pull/633"
        },
        {
          "name": "https://github.com/sigstore/sigstore-go/commit/dbb07e62623edd5b175fb9dd5a41dcb85a159207",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/sigstore-go/commit/dbb07e62623edd5b175fb9dd5a41dcb85a159207"
        },
        {
          "name": "https://github.com/sigstore/sigstore-go/releases/tag/v1.2.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/sigstore-go/releases/tag/v1.2.0"
        }
      ],
      "source": {
        "advisory": "GHSA-9vcr-p3rj-q5q6",
        "discovery": "UNKNOWN"
      },
      "title": "sigstore-go: Multi-log threshold bypass via single compromised log"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-49834",
    "datePublished": "2026-07-17T19:20:06.140Z",
    "dateReserved": "2026-06-01T18:50:36.056Z",
    "dateUpdated": "2026-07-17T19:42:17.005Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-49835 (GCVE-0-2026-49835)

Vulnerability from cvelistv5 – Published: 2026-07-17 18:16 – Updated: 2026-07-17 19:45

Title

Sigstore Timestamp Authority: OOM due to unbounded metric label cardinality

Summary

Sigstore Timestamp Authority is a service for issuing RFC 3161 timestamps. Prior to 2.1.0, the global wrapMetrics middleware records raw HTTP request path r.URL.Path and raw HTTP request method r.Method as Prometheus labels for latency and request count metric vectors before routing, allowing an unauthenticated remote attacker to issue requests with random paths such as /api/v1/timestamp/<uuid> or random HTTP methods and create unbounded permanent time-series entries that exhaust memory. This issue is fixed in version 2.1.0.

Severity

5.9 (Medium)


                        
                          CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-07-17 19:45 UTC

CWE

CWE-770 - Allocation of Resources Without Limits or Throttling

Assigner

GitHub_M

References

3 references

URL	Tags
https://github.com/sigstore/timestamp-authority/s…	x_refsource_CONFIRM
https://github.com/sigstore/timestamp-authority/c…	x_refsource_MISC
https://github.com/sigstore/timestamp-authority/r…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
sigstore	timestamp-authority	Affected: < 2.1.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-49835",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-17T19:45:33.792018Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-17T19:45:44.026Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "timestamp-authority",
          "vendor": "sigstore",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 2.1.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Sigstore Timestamp Authority is a service for issuing RFC 3161 timestamps. Prior to 2.1.0, the global wrapMetrics middleware records raw HTTP request path r.URL.Path and raw HTTP request method r.Method as Prometheus labels for latency and request count metric vectors before routing, allowing an unauthenticated remote attacker to issue requests with random paths such as /api/v1/timestamp/\u003cuuid\u003e or random HTTP methods and create unbounded permanent time-series entries that exhaust memory. This issue is fixed in version 2.1.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 5.9,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-17T18:16:41.764Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/sigstore/timestamp-authority/security/advisories/GHSA-9c54-x2g4-v92j",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/sigstore/timestamp-authority/security/advisories/GHSA-9c54-x2g4-v92j"
        },
        {
          "name": "https://github.com/sigstore/timestamp-authority/commit/506ec57b6ac2ea1e4739322e47453469425b69b5",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/timestamp-authority/commit/506ec57b6ac2ea1e4739322e47453469425b69b5"
        },
        {
          "name": "https://github.com/sigstore/timestamp-authority/releases/tag/v2.1.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/timestamp-authority/releases/tag/v2.1.0"
        }
      ],
      "source": {
        "advisory": "GHSA-9c54-x2g4-v92j",
        "discovery": "UNKNOWN"
      },
      "title": "Sigstore Timestamp Authority: OOM due to unbounded metric label cardinality"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-49835",
    "datePublished": "2026-07-17T18:16:41.764Z",
    "dateReserved": "2026-06-01T18:50:36.056Z",
    "dateUpdated": "2026-07-17T19:45:44.026Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-54787 (GCVE-0-2026-54787)

Vulnerability from cvelistv5 – Published: 2026-07-31 21:58 – Updated: 2026-07-31 23:36

Title

sigstore-go fails to check signature timestamps against a signing key's validity period

Summary

sigstore-go is a Go library for Sigstore signing and verification. Prior to 1.2.1, sigstore-go does not check a bundle signing timestamp against the validity window of an ExpiringKey wrapping a self-managed long-lived signing key without a certificate, which can allow an attacker holding expired key material to sign accepted bundles. This issue is fixed in version 1.2.1.

Severity

3.1 (Low)


                        
                          CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-07-31 23:35 UTC

CWE

CWE-324 - Use of a Key Past its Expiration Date

Assigner

GitHub_M

References

4 references

URL	Tags
https://github.com/sigstore/sigstore-go/security/…	x_refsource_CONFIRM
https://github.com/sigstore/sigstore-go/pull/642	x_refsource_MISC
https://github.com/sigstore/sigstore-go/commit/45…	x_refsource_MISC
https://github.com/sigstore/sigstore-go/releases/…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
sigstore	sigstore-go	Affected: < 1.2.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-54787",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-31T23:35:40.966529Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-31T23:36:13.441Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/sigstore/sigstore-go/security/advisories/GHSA-wqqc-jjcq-vfxm"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "sigstore-go",
          "vendor": "sigstore",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.2.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "sigstore-go is a Go library for Sigstore signing and verification. Prior to 1.2.1, sigstore-go does not check a bundle signing timestamp against the validity window of an ExpiringKey wrapping a self-managed long-lived signing key without a certificate, which can allow an attacker holding expired key material to sign accepted bundles. This issue is fixed in version 1.2.1."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 3.1,
            "baseSeverity": "LOW",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-324",
              "description": "CWE-324: Use of a Key Past its Expiration Date",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-31T21:58:14.156Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/sigstore/sigstore-go/security/advisories/GHSA-wqqc-jjcq-vfxm",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/sigstore/sigstore-go/security/advisories/GHSA-wqqc-jjcq-vfxm"
        },
        {
          "name": "https://github.com/sigstore/sigstore-go/pull/642",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/sigstore-go/pull/642"
        },
        {
          "name": "https://github.com/sigstore/sigstore-go/commit/4594ab4c779d08be1f4419803a8249188f35ed5f",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/sigstore-go/commit/4594ab4c779d08be1f4419803a8249188f35ed5f"
        },
        {
          "name": "https://github.com/sigstore/sigstore-go/releases/tag/v1.2.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/sigstore-go/releases/tag/v1.2.1"
        }
      ],
      "source": {
        "advisory": "GHSA-wqqc-jjcq-vfxm",
        "discovery": "UNKNOWN"
      },
      "title": "sigstore-go fails to check signature timestamps against a signing key\u0027s validity period"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-54787",
    "datePublished": "2026-07-31T21:58:14.156Z",
    "dateReserved": "2026-06-15T23:23:57.714Z",
    "dateUpdated": "2026-07-31T23:36:13.441Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

GHSA-47Q9-M4WW-924M

Vulnerability from github – Published: 2026-06-25 21:33 – Updated: 2026-06-25 21:33

Summary

Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic

Details

Description

The Package.Unmarshal() function in pkg/types/alpine/apk.go decompresses the signature and control gzip members of an APK file into in-memory buffers without bounding the total decompressed size. The existing max_apk_metadata_size check (default 1MB) is only applied to individual tar entry header sizes after decompression completes, so it does not prevent a decompression bomb from consuming unbounded heap memory.

An attacker can craft a gzip stream that compresses at a ~1000:1 ratio (e.g., 2MB compressed zeros → 2GB decompressed). When submitted as spec.package.content in an Alpine ProposedEntry, the server decompresses the full payload into memory during request processing, triggering a fatal Go runtime out-of-memory error or OS OOM-kill that cannot be caught by the server's recover() middleware.

This is reachable via two unauthenticated endpoints: - POST /api/v1/log/entries (createLogEntry) - POST /api/v1/log/entries/retrieve (searchLogQuery)

Both invoke V001Entry.Canonicalize() → fetchExternalEntities() → apk.Unmarshal(packageData), which performs the unbounded decompression.

Workarounds

There is no effective workaround. Setting max_request_body_size reduces but does not eliminate exposure due to the ~1000:1 compression ratio (a 1MB body limit still allows ~1GB heap allocation). Setting max_apk_metadata_size has no effect on this vulnerability since the check is applied after decompression.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/rekor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0"
            },
            {
              "fixed": "1.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48702"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T21:33:36Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Description\n\nThe `Package.Unmarshal()` function in `pkg/types/alpine/apk.go` decompresses the signature and control gzip members of an APK file into in-memory buffers without bounding the total decompressed size. The existing `max_apk_metadata_size` check (default 1MB) is only applied to individual tar entry header sizes after decompression completes, so it does not prevent a decompression bomb from consuming unbounded heap memory.\n\nAn attacker can craft a gzip stream that compresses at a ~1000:1 ratio (e.g., 2MB compressed zeros \u2192 2GB decompressed). When submitted as spec.package.content in an Alpine `ProposedEntry`, the server decompresses the full payload into memory during request processing, triggering a fatal Go runtime out-of-memory error or OS OOM-kill that cannot be caught by the server\u0027s recover() middleware.\n\nThis is reachable via two unauthenticated endpoints:\n- POST /api/v1/log/entries (createLogEntry)\n- POST /api/v1/log/entries/retrieve (searchLogQuery)\n\nBoth invoke `V001Entry.Canonicalize()` \u2192 `fetchExternalEntities()` \u2192 `apk.Unmarshal(packageData)`, which performs the unbounded decompression.\n\n## Workarounds\n\nThere is no effective workaround. Setting `max_request_body_size` reduces but does not eliminate exposure due to the ~1000:1 compression ratio (a 1MB body limit still allows ~1GB heap allocation). Setting `max_apk_metadata_size` has no effect on this vulnerability since the check is applied after decompression.",
  "id": "GHSA-47q9-m4ww-924m",
  "modified": "2026-06-25T21:33:36Z",
  "published": "2026-06-25T21:33:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/rekor"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic"
}

GHSA-9C54-X2G4-V92J

Vulnerability from github – Published: 2026-06-30 18:40 – Updated: 2026-06-30 18:40

Summary

Sigstore Timestamp Authority has OOM due to unbounded metric label cardinality

Details

Impact

An unauthenticated remote attacker can trigger unbounded memory growth on the timestamp authority server.

This vulnerability exists because the global wrapMetrics middleware records the raw HTTP request path (r.URL.Path) and raw HTTP request method (r.Method) as Prometheus labels for latency and request count metric vectors. Since this middleware runs before standard routing occurs, it executes for all incoming requests, including those for unmatched paths (yielding 404 responses) or arbitrary request methods. The Prometheus library registers a new, permanent time-series entry for every distinct label combination. An attacker can continuously issue requests containing random paths (e.g., /api/v1/timestamp/<uuid>) or random HTTP methods to exhaust system memory.

Patches

This issue has been patched by limiting the metric label values to a strict allowlist of expected paths (/ping, /api/v1/timestamp, /api/v1/timestamp/certchain) and expected HTTP methods (GET, POST, HEAD, OPTIONS). Unrecognized paths or methods are normalized to a static string ("unrecognized").

Users should update to version v2.0.7 or later.

Workarounds

Block or drop incoming requests with invalid HTTP methods or unknown request paths at a reverse proxy or load balancer before they reach the timestamp authority server.
Configure rate-limiting on the public interface to prevent remote attackers from issuing millions of unique requests in a short duration.

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.6"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/timestamp-authority/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/timestamp-authority"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.2.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49835"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-30T18:40:39Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn unauthenticated remote attacker can trigger unbounded memory growth on the timestamp authority server.\n\nThis vulnerability exists because the global `wrapMetrics` middleware records the raw HTTP request path (`r.URL.Path`) and raw HTTP request method (`r.Method`) as Prometheus labels for latency and request count metric vectors. Since this middleware runs before standard routing occurs, it executes for all incoming requests, including those for unmatched paths (yielding 404 responses) or arbitrary request methods. The Prometheus library registers a new, permanent time-series entry for every distinct label combination. An attacker can continuously issue requests containing random paths (e.g., `/api/v1/timestamp/\u003cuuid\u003e`) or random HTTP methods to exhaust system memory.\n\n### Patches\n\nThis issue has been patched by limiting the metric label values to a strict allowlist of expected paths (`/ping`, `/api/v1/timestamp`, `/api/v1/timestamp/certchain`) and expected HTTP methods (`GET`, `POST`, `HEAD`, `OPTIONS`). Unrecognized paths or methods are normalized to a static string (`\"unrecognized\"`).\n\nUsers should update to version `v2.0.7` or later.\n\n### Workarounds\n\n1. Block or drop incoming requests with invalid HTTP methods or unknown request paths at a reverse proxy or load balancer before they reach the timestamp authority server.\n2. Configure rate-limiting on the public interface to prevent remote attackers from issuing millions of unique requests in a short duration.",
  "id": "GHSA-9c54-x2g4-v92j",
  "modified": "2026-06-30T18:40:39Z",
  "published": "2026-06-30T18:40:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/timestamp-authority/security/advisories/GHSA-9c54-x2g4-v92j"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/timestamp-authority"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sigstore Timestamp Authority has OOM due to unbounded metric label cardinality"
}

GHSA-9VCR-P3RJ-Q5Q6

Vulnerability from github – Published: 2026-07-09 23:20 – Updated: 2026-07-31 20:17

Summary

sigstore-go has a multi-log threshold bypass via single compromised log

Details

Impact

What kind of vulnerability is it? Who is impacted?

A verifier configured with WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1) expected defense-in-depth against the compromise of a single log instance. However, threshold counting counted verified witnesses per-entry or per-validation-path rather than per-log-authority.

As a result, a single compromised transparency log could forge multiple entries with different indices, and a single compromised CT log could verify multiple times (either across multiple certificate chains or via multiple embedded SCTs), fully satisfying the multi-log threshold requirements and defeating the multi-log policy.

Note that this does not affect Cosign, as Cosign sets a threshold of 1.

Patches

Has the problem been patched? What versions should users upgrade to?

Upgrade to v1.1.5.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

There is no workaround, beyond relying on trusted logs.

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.4"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/sigstore-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49834"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T23:20:30Z",
    "nvd_published_at": "2026-07-17T20:17:21Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nA verifier configured with WithTransparencyLog(N\u003e1) or WithSignedCertificateTimestamps(N\u003e1) expected defense-in-depth against the compromise of a single log instance. However, threshold counting counted verified witnesses per-entry or per-validation-path rather than per-log-authority.\n\nAs a result, a single compromised transparency log could forge multiple entries with different indices, and a single compromised CT log could verify multiple times (either across multiple certificate chains or via multiple embedded SCTs), fully satisfying the multi-log threshold requirements and defeating the multi-log policy.\n\nNote that this does not affect Cosign, as Cosign sets a threshold of 1.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nUpgrade to v1.1.5.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nThere is no workaround, beyond relying on trusted logs.",
  "id": "GHSA-9vcr-p3rj-q5q6",
  "modified": "2026-07-31T20:17:30Z",
  "published": "2026-07-09T23:20:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49834"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/pull/633"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/commit/dbb07e62623edd5b175fb9dd5a41dcb85a159207"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/sigstore-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/releases/tag/v1.2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "sigstore-go has a multi-log threshold bypass via single compromised log"
}

GHSA-HRXH-6V49-42GF

Vulnerability from github – Published: 2026-07-21 22:03 – Updated: 2026-07-21 22:03

Summary

gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities

Details

Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:

Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing Metadata or RequestedServerName fields.
Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing NOT rules around unsupported fields.

Impact

What kind of vulnerability is it? Who is impacted?

xDS RBAC Authorization Bypass via `Metadata` & `RequestedServerName` matchers

Affected Component: xDS RBAC
Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
If these unsupported rules were nested inside logical NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.

As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.

HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts

Affected Component: HTTP/2 transport
Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as SETTINGS ACKs or server-initiated RST_STREAMs.

When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).

Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules

Affected Component: xDS RBAC
Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a NOT rule wrapped an unsupported or unhandled field (such as SourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.

An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).

Patches

Has the problem been patched? What versions should users upgrade to?

All three issues have been fixed in master and will be released in 1.82.1 shortly.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:

For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing Metadata, RequestedServerName, or NOT rules wrapping unsupported fields (such as SourcedMetadata) to grpc-go servers.
For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2 max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.

Severity

Vulnerability	Qualitative Severity	Approximate CVSS v3.1 Score	Primary Impact
xDS RBAC Authorization Bypass	High	`8.2`	Unauthorized Access / Fail-Open
HTTP/2 Rapid Reset DOS Bypass	High	`7.5`	High CPU Consumption / Denial of Service
xDS RBAC Engine Server Panic	Medium	`5.9`	Process Crash / Denial of Service

Severity

8.8 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "google.golang.org/grpc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.82.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-770",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T22:03:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:\n\n- Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing `Metadata` or `RequestedServerName` fields.\n- Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.\n- Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing `NOT` rules around unsupported fields.\n\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\n#### xDS RBAC Authorization Bypass via `Metadata` \u0026 `RequestedServerName` matchers\n\n- Affected Component: xDS RBAC \n- Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported `permission` and `principal` rules (specifically `Metadata` and `RequestedServerName`) were silently ignored and treated as no-ops.\n  - If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.\n- If these unsupported rules were nested inside logical `NOT` rules (`Permission_NotRule` / `Principal_NotId`) or multi-condition `OR/AND` rules, silently dropping them changed the boolean logic flow of the authorization engine.\n\nAs a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.\n\n#### HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts\n\n- Affected Component: HTTP/2 transport\n- Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as `SETTINGS` ACKs or server-initiated `RST_STREAM`s.\n\nWhen a client initiated a rapid flood of stream creation (`HEADERS`) immediately followed by stream termination `RST_STREAM`, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).\n\n#### Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules\n\n- Affected Component: xDS RBAC \n- Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a `NOT` rule wrapped an unsupported or unhandled field (such as `SourcedMetadata`), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.\n\nAn attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a `NOT` rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nAll three issues have been fixed in `master` and will be released in 1.82.1 shortly.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nIf upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:\n\n* For xDS RBAC Vulnerabilities \u0026 Panics: Ensure that upstream xDS management servers do not push RBAC policies containing `Metadata`, `RequestedServerName`, or `NOT` rules wrapping unsupported fields (such as `SourcedMetadata`) to grpc-go servers.\n* For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2 `max_concurrent_streams` limits and active rate limiting on `RST_STREAM` frequency per connection.\n\n### Severity\n\n  | Vulnerability | Qualitative Severity | Approximate CVSS v3.1 Score | Primary Impact |\n  | :--- | :--- | :--- | :--- |\n  | **xDS RBAC Authorization Bypass** | **High** | `8.2` | Unauthorized Access / Fail-Open |\n  | **HTTP/2 Rapid Reset DOS Bypass** | **High** | `7.5` | High CPU Consumption / Denial of Service |\n  | **xDS RBAC Engine Server Panic** | **Medium** | `5.9` | Process Crash / Denial of Service |",
  "id": "GHSA-hrxh-6v49-42gf",
  "modified": "2026-07-21T22:03:56Z",
  "published": "2026-07-21T22:03:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-hrxh-6v49-42gf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/pull/9236"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/commit/4ea465d4ab98013f72a142fe0fc89c19770b2935"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grpc/grpc-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/releases/tag/v1.82.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

Vulnerability from cleanstart

CVE-2026-48702 (GCVE-0-2026-48702)

CVE-2026-49834 (GCVE-0-2026-49834)

CVE-2026-49835 (GCVE-0-2026-49835)

CVE-2026-54787 (GCVE-0-2026-54787)

GHSA-47Q9-M4WW-924M

Description

Workarounds

GHSA-9C54-X2G4-V92J

Impact

Patches

Workarounds

GHSA-9VCR-P3RJ-Q5Q6

Impact

Patches

Workarounds

GHSA-HRXH-6V49-42GF

Impact

xDS RBAC Authorization Bypass via Metadata & RequestedServerName matchers

HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts

Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules

Patches

Workarounds

Severity

Tags

Sightings

Nomenclature

xDS RBAC Authorization Bypass via `Metadata` & `RequestedServerName` matchers