CVE-2026-105298

Estado: Pendiente de análisisMedia (6.3)—
Gravedad6.3Media · CVSS 4.0
Probabilidad de explotación0.44 %mayor que el 37 % de las CVE
Explotación activaNono figura en el catálogo de CISA
Exploit públicoNo conocidosin código público localizado

Resumen

Antes de la versión 0.9.0, Pingora aceptaba peticiones HTTP/2 cuyo encabezado Host difería del pseudo-encabezado :authority. Los filtros de petición, las claves de caché y los registros que leían el URI de la petición (session.req_header().uri) veían el valor de :authority, pero el upstream recibía el valor de Host proporcionado por el cliente. Pingora también aceptaba valores de :authority que contenían userinfo (por ejemplo, user@example.com). Esto incumple la sección 8.3.1 de la RFC 9113, que exige que un intermediario use el valor de :authority para Host y reemplace cualquier campo Host existente.

Leer descripción completaMostrar menos

Causa raíz

HTTP/2 a HTTP/1.1: Host solo se generaba a partir de :authority cuando la petición no tenía encabezado Host, por lo que un Host del cliente en conflicto se reenviaba sin cambios.

HTTP/2 a HTTP/2: el encabezado Host del cliente se eliminaba y se usaba para sobrescribir el :authority del upstream, después de que los filtros de petición ya se hubieran ejecutado sobre el :authority original.

El servidor HTTP/2 no comparaba Host con :authority y no rechazaba userinfo en la autoridad.

Impacto

Un atacante remoto y sin autenticar puede enviar una única petición HTTP/2 que la aplicación interpreta como un host y el upstream recibe como otro. Cuando los filtros de petición, los controles de acceso o las claves de caché usan la autoridad del URI y el upstream enruta según Host, esto puede dar lugar a:

Envenenamiento de caché: una respuesta de otro host virtual se almacena bajo la clave de caché del host víctima y se sirve a otros usuarios (esto también requiere que el upstream sirva contenido distinto según Host).

Evasión de controles de acceso basados en el host: una petición aprobada para un host es atendida por un host virtual distinto en el upstream.

Las implementaciones que no aceptan HTTP/2 de los clientes, o que no usan la autoridad de la petición para decisiones de seguridad o de caché, no se ven afectadas.

Tenga en cuenta que los clientes del CDN de Cloudflare no se vieron afectados, ya que los servicios internos de Pingora en Cloudflare no tienen clientes HTTP/2.

Mitigación:

Actualice a pingora 0.9.0 o posterior. Pingora ahora devuelve 400 Bad Request para las peticiones HTTP/2 cuyo Host difiere de :authority, que contienen más de un Host, o cuya autoridad contiene userinfo, y mantiene coherentes el Host o el :authority del upstream con la autoridad de la petición. Commits de corrección: https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b , https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76

Si no puede actualizar: en request_filter, rechace las peticiones HTTP/2 que lleven un encabezado Host distinto de la autoridad del URI, o cuya autoridad contenga '@'.

Detalles técnicos trazas, registros y código del informe original
  *

  *

  *

  *

  *

  *

  *

Traducción automática del texto original de NVD (en inglés).

CVSS

Puntuación base
6.3
Versión
4.0
Vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Probabilidad de explotación (EPSS)

Probabilidad de explotación en los próximos 30 días
0.44 %
Percentil entre todas las CVEs puntuadas
37
Fecha de la puntuación
20/10/2026

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

Técnicas ATT&CK

Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.

Vector AV:N/PR:N/UI:N y texto: una sola peticion HTTP/2 remota no autenticada desvia Host y :authority, lo que permite envenenar la cache de otro host.

Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.

Mitigaciones ATT&CK que cubren estas técnicas

Tecnologías afectadas (1)

⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.

Referencias

Mostrar las 1 referencias

JSON original (NVD)

Mostrar
{
  "id": "CVE-2026-105298",
  "cveTags": [],
  "metrics": {
    "cvssMetricV40": [
      {
        "type": "Secondary",
        "source": "cna@cloudflare.com",
        "cvssData": {
          "Safety": "NOT_DEFINED",
          "version": "4.0",
          "Recovery": "NOT_DEFINED",
          "baseScore": 6.3,
          "Automatable": "NOT_DEFINED",
          "attackVector": "NETWORK",
          "baseSeverity": "MEDIUM",
          "valueDensity": "NOT_DEFINED",
          "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
          "exploitMaturity": "NOT_DEFINED",
          "providerUrgency": "NOT_DEFINED",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "attackRequirements": "PRESENT",
          "privilegesRequired": "NONE",
          "subIntegrityImpact": "LOW",
          "vulnIntegrityImpact": "NONE",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "subAvailabilityImpact": "NONE",
          "vulnAvailabilityImpact": "NONE",
          "availabilityRequirement": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "subConfidentialityImpact": "LOW",
          "vulnConfidentialityImpact": "NONE",
          "confidentialityRequirement": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "vulnerabilityResponseEffort": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED"
        }
      }
    ]
  },
  "affected": [
    {
      "source": "cna@cloudflare.com",
      "affectedData": [
        {
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "product": "https://github.com/cloudflare/pingora",
          "versions": [
            {
              "status": "affected",
              "version": "0.1.0",
              "lessThan": "0.9.0",
              "versionType": "semver"
            }
          ],
          "defaultStatus": "unaffected"
        }
      ]
    }
  ],
  "published": "2026-10-20T01:17:09.787",
  "references": [
    {
      "url": "https://github.com/cloudflare/pingora",
      "source": "cna@cloudflare.com"
    }
  ],
  "vulnStatus": "Awaiting Analysis",
  "descriptions": [
    {
      "lang": "en",
      "value": "Summary\n\n\n\nBefore version 0.9.0, Pingora accepted HTTP/2 requests whose Host header differed from the :authority pseudo-header. Request filters, cache keys, and logs that read the request URI (session.req_header().uri) saw the :authority value, but the upstream received the client-supplied Host value. Pingora also accepted :authority values containing userinfo (for example, user@example.com). This violates RFC 9113 Section 8.3.1, which requires an intermediary to use the :authority value for Host and replace any existing Host field.\n\n\n\n\nRoot cause\n\n  *  \n\nHTTP/2 to HTTP/1.1: Host was generated from :authority only when the request had no Host header, so a conflicting client Host was forwarded unchanged.\n\n\n  *  \n\nHTTP/2 to HTTP/2: the client Host header was removed and used to overwrite the upstream :authority, after request filters had already run against the original :authority.\n\n\n  *  \n\nThe HTTP/2 server did not compare Host with :authority and did not reject userinfo in the authority.\n\n\n\n\n\n\n\nImpact\n\n\n\nA remote, unauthenticated attacker can send a single HTTP/2 request that the application sees as one host and the upstream receives as another. Where request filters, access controls, or cache keys use the URI authority and the upstream routes by Host, this can lead to:\n\n  *  \n\nCache poisoning: a response from another virtual host is stored under the victim host's cache key and served to other users (this also requires the upstream to serve different content per Host).\n\n\n  *  \n\nHost-based access control bypass: a request approved for one host is served by a different virtual host on the upstream.\n\n\n\n\n\n\nDeployments that do not accept HTTP/2 from clients, or that do not use the request authority for security or caching decisions, are not affected.\n\n\n\n\nNote that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.\n\n\n\n\nMitigation:\n\n  *  \n\nUpgrade to pingora 0.9.0 or later. Pingora now returns 400 Bad Request for HTTP/2 requests whose Host differs from :authority, that contain more than one Host, or whose authority contains userinfo, and keeps the upstream Host or :authority consistent with the request authority. Fix commits:  https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b ,  https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76 \n\n\n  *  \n\nIf you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains '@'."
    }
  ],
  "lastModified": "2026-10-20T15:03:59.857",
  "sourceIdentifier": "cna@cloudflare.com"
}