p PatchFirst

PatchFirst · Aktuelle Sicherheitslücken

Sicherheitslücken in golang-google-grpc

In den letzten 30 Tagen veröffentlichte Sicherheitslücken für golang-google-grpc: 0. Davon im KEV-Katalog: 0.

Sicherheitslücken filtern
Filter zurücksetzen

Sicherheitslücken: 3

  1. CVE-2026-33186

    Kritisch · CVSS 9.1EPSS 1,58%Keine Korrektur veröffentlicht

    gRPC-Go has an authorization bypass via missing leading slash in :path

    gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with `/`) failed to

    Veröffentlicht Aktualisiert
  2. CVE-2019-9515

    Hoch · CVSS 7.5EPSS 87,29%Keine Korrektur veröffentlicht

    Some HTTP/2 implementations are vulnerable to a settings flood, potentially leading to a denial of service

    Some HTTP/2 implementations are vulnerable to a settings flood, potentially leading to a denial of service. The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.

    Veröffentlicht Aktualisiert
  3. CVE-2019-9514

    Hoch · CVSS 7.5EPSS 82,81%Keine Korrektur veröffentlicht

    Some HTTP/2 implementations are vulnerable to a reset flood, potentially leading to a denial of service

    Some HTTP/2 implementations are vulnerable to a reset flood, potentially leading to a denial of service. The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both.

    Veröffentlicht Aktualisiert

Prüfen Sie Ihren Server

Gleichen Sie Ihren installierten Stack und seine Versionen mit den aktuellen Sicherheitsmeldungen ab.

Prüfen Sie Ihren Server →