Find a vulnerability

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-105299",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-20T19:18:45.445676Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-444",
                "description": "CWE-444 Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-20T19:19:36.616Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.9.0",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Reported by thesmartshadow (GitHub)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSummary\u003c/p\u003e\u003cp\u003eBefore version 0.9.0, the HTTP/1 upstream path in pingora-proxy passed the downstream request through upstream_request_filter and wrote it to the upstream without removing the client\u0027s Connection header, other hop-by-hop headers, or the headers Connection nominated, although RFC 9110 Section 7.6.1 requires intermediaries to remove them. The HTTP/2 upstream path already removed Connection and related HTTP/1-specific headers. A client could therefore nominate a header that the application adds in upstream_request_filter (for example, Connection: keep-alive, X-Forwarded-For). A downstream HTTP/1 intermediary that honors Connection would then strip the Pingora-added header before it reached the origin.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eImpact\u003c/p\u003e\u003cp\u003eSpecifically affects chained deployments where an HTTP/1 intermediary between Pingora and the origin processes Connection nominations (for example, Go\u0027s net/http/httputil.ReverseProxy) and the origin trusts headers added by that intermediary (for example, X-Forwarded-For for IP-based authorization). A remote, unauthenticated attacker can have those headers removed, potentially bypassing authorization. The reporter demonstrated access to an IP-restricted endpoint using X-Forwarded-For for IP validation on the origin. This is the same class of issue as CVE-2022-31813 in Apache HTTP Server.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eNote that Cloudflare CDN customers were unaffected, as no such chained deployment as described above exists with internal Pingora services, and Connection headers are sanitized before arriving at Pingora gateways.\u003c/p\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits: \u003ca href=\"https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded\"\u003ehttps://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded\u003c/a\u003e, \u003ca href=\"https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee\"\u003ehttps://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee\u003c/a\u003e\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eDo not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eIf you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e"
            }
          ],
          "value": "Summary\n\n\n\nBefore version 0.9.0, the HTTP/1 upstream path in pingora-proxy passed the downstream request through upstream_request_filter and wrote it to the upstream without removing the client\u0027s Connection header, other hop-by-hop headers, or the headers Connection nominated, although RFC 9110 Section 7.6.1 requires intermediaries to remove them. The HTTP/2 upstream path already removed Connection and related HTTP/1-specific headers. A client could therefore nominate a header that the application adds in upstream_request_filter (for example, Connection: keep-alive, X-Forwarded-For). A downstream HTTP/1 intermediary that honors Connection would then strip the Pingora-added header before it reached the origin.\n\n\n\n\nImpact\n\n\n\nSpecifically affects chained deployments where an HTTP/1 intermediary between Pingora and the origin processes Connection nominations (for example, Go\u0027s net/http/httputil.ReverseProxy) and the origin trusts headers added by that intermediary (for example, X-Forwarded-For for IP-based authorization). A remote, unauthenticated attacker can have those headers removed, potentially bypassing authorization. The reporter demonstrated access to an IP-restricted endpoint using X-Forwarded-For for IP validation on the origin. This is the same class of issue as CVE-2022-31813 in Apache HTTP Server.\n\n\n\n\nNote that Cloudflare CDN customers were unaffected, as no such chained deployment as described above exists with internal Pingora services, and Connection headers are sanitized before arriving at Pingora gateways.\n\n\n\nMitigation:\n\n  *  \n\nUpgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits:  https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded ,  https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee \n\n\n  *  \n\nDo not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.\n\n\n  *  \n\nIf you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-20T01:07:12.767Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits: \u003ca href=\"https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded\"\u003ehttps://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded\u003c/a\u003e, \u003ca href=\"https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee\"\u003ehttps://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee\u003c/a\u003e\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eDo not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eIf you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e"
            }
          ],
          "value": "Mitigation:\n\n  *  \n\nUpgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits:  https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded ,  https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee \n\n\n  *  \n\nDo not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.\n\n\n  *  \n\nIf you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Pingora forwards client-nominated Connection headers to HTTP/1 upstreams, allowing ACL bypass in specific chained deployments",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-105299",
    "datePublished": "2026-10-20T01:07:12.767Z",
    "dateReserved": "2026-10-05T04:19:00.725Z",
    "dateUpdated": "2026-10-20T19:19:36.616Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-105298",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-20T19:19:49.025330Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-444",
                "description": "CWE-444 Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-20T19:20:10.015Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.9.0",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Reported by bipol4r (GitHub)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSummary\u003c/p\u003e\u003cp\u003eBefore 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.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eRoot cause\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eHTTP/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.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eHTTP/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.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eThe HTTP/2 server did not compare Host with :authority and did not reject userinfo in the authority.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cbr\u003e\u003cp\u003eImpact\u003c/p\u003e\u003cp\u003eA 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:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eCache poisoning: a response from another virtual host is stored under the victim host\u0027s cache key and served to other users (this also requires the upstream to serve different content per Host).\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eHost-based access control bypass: a request approved for one host is served by a different virtual host on the upstream.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDeployments that do not accept HTTP/2 from clients, or that do not use the request authority for security or caching decisions, are not affected.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eNote that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.\u003c/p\u003e\u003cbr\u003e\u003cdiv\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade 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: \u003ca href=\"https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b\"\u003ehttps://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b\u003c/a\u003e, \u003ca href=\"https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76\"\u003ehttps://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76\u003c/a\u003e\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eIf you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains \u0027@\u0027.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/div\u003e"
            }
          ],
          "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\u0027s 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 \u0027@\u0027."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-20T00:46:21.902Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade 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: \u003ca href=\"https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b\"\u003ehttps://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b\u003c/a\u003e, \u003ca href=\"https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76\"\u003ehttps://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76\u003c/a\u003e\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eIf you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains \u0027@\u0027.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/b\u003e"
            }
          ],
          "value": "Mitigation:\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 \u0027@\u0027."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Pingora HTTP/2 :authority and Host header mismatch enables cache poisoning and host-based access control bypass",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-105298",
    "datePublished": "2026-10-20T00:46:21.902Z",
    "dateReserved": "2026-10-05T04:18:59.291Z",
    "dateUpdated": "2026-10-20T19:20:10.015Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-105297",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-20T19:20:25.097096Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-20T19:20:35.542Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.8.1",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Reported by jro-calif (GitHub)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSummary\u003c/p\u003e\u003cp\u003eBefore version 0.8.1, Pingora\u0027s HTTP/2 server used the h2 crate\u0027s default limits unless the application set its own 16 MiB decoded header-list size and no limit on concurrent streams. A remote, unauthenticated client can send 1-byte HPACK references to a near-empty header, making the server allocate hundreds of thousands of header fields per stream across an unlimited number of streams on one connection, and use HTTP/2 flow control to keep those streams open. This can exhaust memory and degrade or terminate the Pingora process.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eImpact\u003c/p\u003e\u003cp\u003eRemote, unauthenticated denial of service against any Pingora service that terminates HTTP/2 (h2 or h2c) without explicitly setting max_header_list_size and max_concurrent_streams. The reporter showed that a single connection could get a Pingora process with a 2 GiB memory limit OOM-killed.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eNote that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.\u003c/p\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade to pingora 0.8.1 or later (fix: \u003ca href=\"https://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd\"\u003ehttps://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd\u003c/a\u003e). When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eApplications that supply their own H2Options are not covered by these defaults and must set max_header_list_size and max_concurrent_streams explicitly (this also works on versions before 0.8.1), or, on 0.8.1 and later, start from pingora_core::protocols::http::v2::server::default_h2_options(). H2Options::default() does not include these limits.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e"
            }
          ],
          "value": "Summary\n\n\n\nBefore version 0.8.1, Pingora\u0027s HTTP/2 server used the h2 crate\u0027s default limits unless the application set its own 16 MiB decoded header-list size and no limit on concurrent streams. A remote, unauthenticated client can send 1-byte HPACK references to a near-empty header, making the server allocate hundreds of thousands of header fields per stream across an unlimited number of streams on one connection, and use HTTP/2 flow control to keep those streams open. This can exhaust memory and degrade or terminate the Pingora process.\n\n\n\n\nImpact\n\n\n\nRemote, unauthenticated denial of service against any Pingora service that terminates HTTP/2 (h2 or h2c) without explicitly setting max_header_list_size and max_concurrent_streams. The reporter showed that a single connection could get a Pingora process with a 2 GiB memory limit OOM-killed.\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\nMitigation:\n\n  *  \n\nUpgrade to pingora 0.8.1 or later (fix:  https://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd ). When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection.\n\n\n  *  \n\nApplications that supply their own H2Options are not covered by these defaults and must set max_header_list_size and max_concurrent_streams explicitly (this also works on versions before 0.8.1), or, on 0.8.1 and later, start from pingora_core::protocols::http::v2::server::default_h2_options(). H2Options::default() does not include these limits."
        }
      ],
      "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"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of resources without limits or throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-20T00:40:27.300Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade to pingora 0.8.1 or later (fix: \u003ca href=\"https://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd\"\u003ehttps://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd\u003c/a\u003e). When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eApplications that supply their own H2Options are not covered by these defaults and must set max_header_list_size and max_concurrent_streams explicitly (this also works on versions before 0.8.1), or, on 0.8.1 and later, start from pingora_core::protocols::http::v2::server::default_h2_options(). H2Options::default() does not include these limits.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/b\u003e"
            }
          ],
          "value": "Mitigation:\n\n  *  \n\nUpgrade to pingora 0.8.1 or later (fix:  https://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd ). When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection.\n\n\n  *  \n\nApplications that supply their own H2Options are not covered by these defaults and must set max_header_list_size and max_concurrent_streams explicitly (this also works on versions before 0.8.1), or, on 0.8.1 and later, start from pingora_core::protocols::http::v2::server::default_h2_options(). H2Options::default() does not include these limits."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Pingora HTTP/2 server memory exhaustion through unbounded default header-list and concurrent-stream limits",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-105297",
    "datePublished": "2026-10-20T00:40:27.300Z",
    "dateReserved": "2026-10-05T04:18:56.102Z",
    "dateUpdated": "2026-10-20T19:20:35.542Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-11325",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-12T12:05:26.217219Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-12T12:06:10.745Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "affected",
          "product": "https://github.com/cloudflare/pages-action",
          "repo": "https://github.com/cloudflare/pages-action",
          "vendor": "Cloudflare",
          "versions": [
            {
              "status": "affected",
              "version": "0"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "@agentka99"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "@beg1nn3r"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eDescription\u003c/p\u003e\u003cp\u003eCloudflare was recently notified by external researchers of vulnerabilities in this archived repository, including a remote code execution issue in `src/index.ts` reachable from certain GitHub Actions workflow configurations. Successful exploitation may expose workflow secrets such as CLOUDFLARE_API_TOKEN and GITHUB_TOKEN to an attacker. Because this repository has been deprecated since 2024, Cloudflare will not be issuing patches. To remediate this issue, we recommend migrating to `cloudflare/wrangler-action` immediately. Consumers who have already migrated are not affected.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eSunset Date\u003c/p\u003e\u003cp\u003eThe cloudflare/pages-action repository will be removed on 2026-09-18. Consumers must complete migration before 18th September to avoid CI disruption.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eAffected Versions\u003c/p\u003e\u003cp\u003eAll published versions of cloudflare/pages-action, including consumers pinned to the v1 moving tag.\u003c/p\u003e\u003cbr\u003e\u003cp\u003ePatched Versions\u003c/p\u003e\u003cp\u003eNone. This repository will not receive further updates, including security patches.\u003c/p\u003e\u003cbr\u003e\u003cp\u003e\u003cb\u003eResolution / Migration Path\u003c/b\u003e\u003cbr\u003eMigrate all workflows using cloudflare/pages-action to `cloudflare/wrangler-action` before 2026-09-18. Refer to the wrangler-action README for the equivalent step configuration and migration guidance.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eCredit\u003c/p\u003e\u003cp\u003eThanks to @agentka99 and @beg1nn3r for reporting their findings via Cloudflare\u0027s HackerOne program that informe\u003c/p\u003e\u003cbr\u003e"
            }
          ],
          "value": "Description\n\n\n\nCloudflare was recently notified by external researchers of vulnerabilities in this archived repository, including a remote code execution issue in `src/index.ts` reachable from certain GitHub Actions workflow configurations. Successful exploitation may expose workflow secrets such as CLOUDFLARE_API_TOKEN and GITHUB_TOKEN to an attacker. Because this repository has been deprecated since 2024, Cloudflare will not be issuing patches. To remediate this issue, we recommend migrating to `cloudflare/wrangler-action` immediately. Consumers who have already migrated are not affected.\n\n\n\n\nSunset Date\n\n\n\nThe cloudflare/pages-action repository will be removed on 2026-09-18. Consumers must complete migration before 18th September to avoid CI disruption.\n\n\n\n\nAffected Versions\n\n\n\nAll published versions of cloudflare/pages-action, including consumers pinned to the v1 moving tag.\n\n\n\n\nPatched Versions\n\n\n\nNone. This repository will not receive further updates, including security patches.\n\n\n\n\nResolution / Migration Path\nMigrate all workflows using cloudflare/pages-action to `cloudflare/wrangler-action` before 2026-09-18. Refer to the wrangler-action README for the equivalent step configuration and migration guidance.\n\n\n\n\nCredit\n\n\n\nThanks to @agentka99 and @beg1nn3r for reporting their findings via Cloudflare\u0027s HackerOne program that informe"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-78",
              "description": "CWE-78 Improper neutralization of special elements used in an OS command (\u0027OS command injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-1104",
              "description": "CWE-1104 Use of unmaintained third party components",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-12T11:38:41.565Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/cloudflare/wrangler-action"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "cloudflare/pages-action is deprecated \u2014 migration required by September 18th, 2026",
      "x_generator": {
        "engine": "Vulnogram 1.0.4"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-11325",
    "datePublished": "2026-08-12T11:31:15.102Z",
    "dateReserved": "2026-06-04T23:49:45.491Z",
    "dateUpdated": "2026-08-12T12:06:10.745Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-12707",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-14T15:57:40.409163Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-14T15:57:47.140Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "quiche",
          "repo": "https://github.com/cloudflare/quiche",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.29.3",
              "status": "affected",
              "version": "0.15.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSummary\u003c/p\u003e\u003cp\u003eCloudflare quiche was discovered to be vulnerable to memory resource exhaustion due to unbounded queuing of post-handshake client migration events.\u003c/p\u003e\u003cp\u003eImpact\u003c/p\u003e\u003cp\u003equiche supports the connection migration features described in Section 9 of RFC 9000, which allows a single QUIC connection to survive changes in the network path. Although quiche implements the protections described in Section 9.3 of RFC 9000 to limit server state commitment, it was discovered that the collection of PathEvents, intended to be consumed by applications via the path_event_next() function, was not bounded.\u003c/p\u003e\u003cp\u003eOnce the QUIC handshake completed, a peer could exploit rapid source address migration in order to cause unbounded queuing of the PathEvent::ReusedSourceConnectionId type. Servers are vulnerable even if active connection migration is disabled.\u003c/p\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eApplications can call path_event_next() to drain the PathEvent collection, mitigating the attack.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eUsers are requested to upgrade to quiche 0.29.3 which is the earliest version that prevents excessive queueing of PathEvent::ReusedSourceConnectionId.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e"
            }
          ],
          "value": "Summary\n\n\n\nCloudflare quiche was discovered to be vulnerable to memory resource exhaustion due to unbounded queuing of post-handshake client migration events.\n\n\n\nImpact\n\n\n\nquiche supports the connection migration features described in Section 9 of RFC 9000, which allows a single QUIC connection to survive changes in the network path. Although quiche implements the protections described in Section 9.3 of RFC 9000 to limit server state commitment, it was discovered that the collection of PathEvents, intended to be consumed by applications via the path_event_next() function, was not bounded.\n\n\n\nOnce the QUIC handshake completed, a peer could exploit rapid source address migration in order to cause unbounded queuing of the PathEvent::ReusedSourceConnectionId type. Servers are vulnerable even if active connection migration is disabled.\n\n\n\nMitigation:\n\n  *  \n\nApplications can call path_event_next() to drain the PathEvent collection, mitigating the attack.\n\n\n  *  \n\nUsers are requested to upgrade to quiche 0.29.3 which is the earliest version that prevents excessive queueing of PathEvent::ReusedSourceConnectionId."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-130",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-130 Excessive Allocation"
            }
          ]
        }
      ],
      "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"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of resources without limits or throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-14T15:18:24.104Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/quiche/security/advisories/GHSA-4q5x-gp38-rfp4"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Unbounded path event queue growth in quiche via peer-driven source connection ID rotation",
      "x_generator": {
        "engine": "Vulnogram 1.0.2"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-12707",
    "datePublished": "2026-07-14T15:18:24.104Z",
    "dateReserved": "2026-06-19T10:27:48.087Z",
    "dateUpdated": "2026-07-14T15:57:47.140Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-12523",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-15T14:08:33.441723Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-400",
                "description": "CWE-400 Uncontrolled Resource Consumption",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-15T17:47:52.441Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "quiche",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.29.3",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "S\u00e9bastien F\u00e9ry"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSummary\u003c/p\u003e\u003cp\u003eCloudflare quiche\u0027s HTTP/3 layer was discovered to be vulnerable to resource exhaustion (i.e., memory) by means of specially crafted HTTP/3 frames.\u003c/p\u003e\u003cbr\u003e\u003cdiv\u003e\u003cp\u003eImpact\u003c/p\u003e\u003cp\u003eHTTP/3 defines multiple frame types to support HTTP message exchanges and connection management. Each frame has a length and a payload whose length depends on the frame type. quiche was found to be vulnerable when parsing some frame types to pre-allocating memory based on the declared length. An attacker would not need to send the number of declared bytes to trigger this issue.\u003c/p\u003e\u003cp\u003eIn addition, quiche was found to not apply QPACK decompression limits correctly. This could allow an attacker to send specially crafted HEADERS frames that would cause more memory commitment than otherwise advertised by MAX_FIELD_SECTION_SIZE (configured by set_max_field_section_size()).\u003c/p\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUsers are requested to upgrade to quiche 0.29.3 which is the earliest version containing the fix for this issue.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003c/div\u003e\u003cdiv\u003e\u003cb\u003eCredits: \u003c/b\u003eDisclosed responsibly by S\u00e9bastien F\u00e9ry\u0026nbsp;\u003c/div\u003e"
            }
          ],
          "value": "Summary\n\n\n\nCloudflare quiche\u0027s HTTP/3 layer was discovered to be vulnerable to resource exhaustion (i.e., memory) by means of specially crafted HTTP/3 frames.\n\n\n\n\nImpact\n\n\n\nHTTP/3 defines multiple frame types to support HTTP message exchanges and connection management. Each frame has a length and a payload whose length depends on the frame type. quiche was found to be vulnerable when parsing some frame types to pre-allocating memory based on the declared length. An attacker would not need to send the number of declared bytes to trigger this issue.\n\n\n\nIn addition, quiche was found to not apply QPACK decompression limits correctly. This could allow an attacker to send specially crafted HEADERS frames that would cause more memory commitment than otherwise advertised by MAX_FIELD_SECTION_SIZE (configured by set_max_field_section_size()).\n\n\n\n\n\n\nMitigation:\n\n  *  \n\nUsers are requested to upgrade to quiche 0.29.3 which is the earliest version containing the fix for this issue.\n\n\n\n\n\n\n\n\n\nCredits: Disclosed responsibly by S\u00e9bastien F\u00e9ry"
        }
      ],
      "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"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-14T15:51:28.886Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/quiche/security/advisories/GHSA-4fgf-9xrr-88gf"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Resource exhaustion in quiche HTTP/3 and QPACK layers",
      "x_generator": {
        "engine": "Vulnogram 1.0.2"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-12523",
    "datePublished": "2026-07-14T15:51:28.886Z",
    "dateReserved": "2026-06-17T13:35:37.498Z",
    "dateUpdated": "2026-07-15T17:47:52.441Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "HIGH",
              "attackVector": "ADJACENT_NETWORK",
              "availabilityImpact": "NONE",
              "baseScore": 6.8,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "HIGH",
              "integrityImpact": "HIGH",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-14440",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-02T19:22:08.681269Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-693",
                "description": "CWE-693 Protection Mechanism Failure",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-02T19:22:18.404Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "technical-description",
              "exploit"
            ],
            "url": "https://david-osipov.vision/en/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/"
          },
          {
            "tags": [
              "related"
            ],
            "url": "https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999/10"
          },
          {
            "tags": [
              "related"
            ],
            "url": "https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930"
          },
          {
            "tags": [
              "technical-description",
              "exploit"
            ],
            "url": "https://zenodo.org/records/18330221"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "platforms": [
            "Cloud Service"
          ],
          "product": "Universal SSL",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThanOrEqual": "current",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003e\u003cb\u003eDescription:\u003c/b\u003e\u003c/p\u003e\u003cbr\u003e\u003cp\u003eTo issue and renew TLS certificates on behalf of customers, Cloudflare\u0027s Universal SSL feature automatically manages the CAA RRset for the customer\u0027s zone. This auto-managed RRset is permissive by design (e.g. \u0027issue \"letsencrypt.org\"\u0027 without parameters). On Universal SSL zones, Cloudflare\u0027s authoritative DNS serves this auto-managed RRset at query time, superseding any customer-configured CAA records on the zone. When a customer publishes a stricter CAA record using the RFC 8657 accounturi or validationmethods parameters, the Certificate Authority does not observe those parameters when evaluating the served RRset under RFC 8659. As a result, the RFC 8657 account-binding and validation-method-binding protections are not enforced end-to-end on Universal SSL zones. Successful exploitation could result in issuance of a browser-trusted TLS certificate to an attacker, enabling MITM against the affected domain.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eExploitation is non-trivial in practice: an attacker would need to hold an ACME account at one of the Certificate Authorities in the served CAA RRset and to simultaneously satisfy domain control validation across the multiple geographically distinct Network Perspectives the CA relies on for Multi-Perspective Issuance Corroboration. Cloudflare prefixes are anycast-announced from hundreds of locations globally, raising the bar against single-vantage-point BGP hijacks. Any resulting misissuance of a browser-trusted certificate is subject to Certificate Transparency logging required by major browsers, and would be visible to CT monitoring.\u003c/p\u003e\u003cp\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eMitigation:\u0026nbsp;\u003c/b\u003e\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eUniversal SSL\u0027s automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.\u0026nbsp;\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eCertificate Transparency monitoring is recommended for all customers as a general detection control.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cb\u003e\u003c/b\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eCredits:\u003c/b\u003e\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cb\u003e\u003c/b\u003e\u003cbr\u003e\u003c/p\u003e\u003cbr\u003e"
            }
          ],
          "value": "Description:\n\n\n\n\nTo issue and renew TLS certificates on behalf of customers, Cloudflare\u0027s Universal SSL feature automatically manages the CAA RRset for the customer\u0027s zone. This auto-managed RRset is permissive by design (e.g. \u0027issue \"letsencrypt.org\"\u0027 without parameters). On Universal SSL zones, Cloudflare\u0027s authoritative DNS serves this auto-managed RRset at query time, superseding any customer-configured CAA records on the zone. When a customer publishes a stricter CAA record using the RFC 8657 accounturi or validationmethods parameters, the Certificate Authority does not observe those parameters when evaluating the served RRset under RFC 8659. As a result, the RFC 8657 account-binding and validation-method-binding protections are not enforced end-to-end on Universal SSL zones. Successful exploitation could result in issuance of a browser-trusted TLS certificate to an attacker, enabling MITM against the affected domain.\n\n\n\n\nExploitation is non-trivial in practice: an attacker would need to hold an ACME account at one of the Certificate Authorities in the served CAA RRset and to simultaneously satisfy domain control validation across the multiple geographically distinct Network Perspectives the CA relies on for Multi-Perspective Issuance Corroboration. Cloudflare prefixes are anycast-announced from hundreds of locations globally, raising the bar against single-vantage-point BGP hijacks. Any resulting misissuance of a browser-trusted certificate is subject to Certificate Transparency logging required by major browsers, and would be visible to CT monitoring.\n\n\n\n\n\n\n\n\nMitigation:\u00a0\n\n\n\nCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal SSL\u0027s automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.\u00a0\n\n\n\nCertificate Transparency monitoring is recommended for all customers as a general detection control.\n\n\n\n\n\n\n\n\nCredits:\n\n\n\nDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher"
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "HIGH",
            "attackRequirements": "PRESENT",
            "attackVector": "ADJACENT",
            "baseScore": 7.6,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-01T22:35:10.353Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://developers.cloudflare.com/ssl/edge-certificates/caa-records/"
        },
        {
          "url": "https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/limitations/"
        },
        {
          "url": "https://www.rfc-editor.org/rfc/rfc8657"
        },
        {
          "url": "https://www.rfc-editor.org/rfc/rfc8659"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003e\u003cp\u003eCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\u003c/p\u003e\u003cp\u003eUniversal SSL\u0027s automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCertificate Transparency monitoring is recommended for all customers as a general detection control.\u003c/p\u003e\u003c/b\u003e\u003cbr\u003e"
            }
          ],
          "value": "Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal SSL\u0027s automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.\u00a0\n\n\n\nCertificate Transparency monitoring is recommended for all customers as a general detection control."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Cloudflare Universal SSL automatically managed CAA RRset supersedes customer-configured CAA records",
      "x_generator": {
        "engine": "Vulnogram 1.0.2"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-14440",
    "datePublished": "2026-07-01T22:35:10.353Z",
    "dateReserved": "2026-07-01T22:20:45.895Z",
    "dateUpdated": "2026-07-02T19:22:18.404Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-11941",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-06-22T15:09:49.880714Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-06-22T15:10:00.033Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Quiche",
          "repo": "https://github.com/cloudflare/quiche",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThanOrEqual": "0.29.1",
              "status": "affected",
              "version": "0.20.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "datePublic": "2026-06-19T09:49:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eCloudflare Quiche was affected by 2 use-after-free vulnerabilities in the connection ID iterator FFI functions.\u003c/p\u003e\u003cp\u003eThe \u201cquiche_connection_id_iter_next\u201d and \u201cquiche_conn_retired_scid_next\u201d functions would return a pointer to a \u201cConnectionId\u201d to the applications via function arguments, but the owned \u201cConnectionId\u201d would be dropped at the end of those functions\u0027 scope.\u003c/p\u003e\u003cp\u003eOnly applications using those FFI functions are affected. The FFI API is disabled by default by a build-time feature flag.\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eImpact\u003cbr\u003e\u003c/b\u003e\u003c/span\u003e\u003cspan\u003eIf unpatched, an application calling the affected FFI functions will dereference freed memory. The most likely outcome is undefined behavior leading to a process crash (denial of service). Depending on allocator state, the read may also return adjacent heap contents, resulting in limited information disclosure or incorrect connection identifier handling.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eMitigation\u003cbr\u003e\u003c/b\u003e\u003c/span\u003e\u003cspan\u003eUsers are requested to upgrade to quiche 0.29.2 which is the earliest version containing the fix for this issue.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cb\u003e\u003c/b\u003e\u003cbr\u003e\u003c/p\u003e\u003cbr\u003e"
            }
          ],
          "value": "Cloudflare Quiche was affected by 2 use-after-free vulnerabilities in the connection ID iterator FFI functions.\n\n\n\nThe \u201cquiche_connection_id_iter_next\u201d and \u201cquiche_conn_retired_scid_next\u201d functions would return a pointer to a \u201cConnectionId\u201d to the applications via function arguments, but the owned \u201cConnectionId\u201d would be dropped at the end of those functions\u0027 scope.\n\n\n\nOnly applications using those FFI functions are affected. The FFI API is disabled by default by a build-time feature flag.\n\n\n\nImpact\nIf unpatched, an application calling the affected FFI functions will dereference freed memory. The most likely outcome is undefined behavior leading to a process crash (denial of service). Depending on allocator state, the read may also return adjacent heap contents, resulting in limited information disclosure or incorrect connection identifier handling.\n\n\n\nMitigation\nUsers are requested to upgrade to quiche 0.29.2 which is the earliest version containing the fix for this issue."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 5.6,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-416",
              "description": "CWE-416 Use after free",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-06-19T09:55:54.501Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/quiche/security/advisories/GHSA-mh64-ph39-mrc9"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Use-after-free in connection ID iterator and FFI functions",
      "x_generator": {
        "engine": "Vulnogram 1.0.2"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-11941",
    "datePublished": "2026-06-19T09:55:54.501Z",
    "dateReserved": "2026-06-10T20:16:34.590Z",
    "dateUpdated": "2026-06-22T15:10:00.033Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-2836",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-06T18:23:54.507163Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-345",
                "description": "CWE-345 Insufficient Verification of Data Authenticity",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-06T18:24:11.367Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.8.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Rajat Raghav (xclow3n)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eA cache poisoning vulnerability has been found in the Pingora HTTP proxy framework\u2019s default cache key construction. The issue occurs because the default HTTP cache key implementation generates cache keys using only the URI path, excluding critical factors such as the host header (authority). Operators relying on the default are vulnerable to cache poisoning, and cross-origin responses may be improperly served to users.\u003c/span\u003e\u003c/p\u003e\u003c/b\u003e\u003cbr\u003e\u003cb\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eImpact\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eThis vulnerability affects users of Pingora\u0027s alpha proxy caching feature who relied on the default \u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003eCacheKey\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e implementation. An attacker could exploit this for:\u003c/span\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eCross-tenant data leakage: In multi-tenant deployments, poison the cache so that users from one tenant receive cached responses from another tenant\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eCache poisoning attacks: Serve malicious content to legitimate users by poisoning shared cache entries\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as Cloudflare\u0027s default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.\u003c/span\u003e\u003c/p\u003e\u003c/b\u003e\u003cbr\u003e\u003cb\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eMitigation:\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003eWe strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher, which removes the insecure default cache key implementation. Users must now explicitly implement their own callback that includes appropriate factors such as Host header, origin server HTTP scheme, and other attributes their cache should vary on.\u003c/span\u003e\u003c/p\u003e\u003cbr\u003e\u003cp\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003ePingora users on previous versions may also remove any of their default \u003c/span\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003eCacheKey\u003c/span\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003e usage and implement their own that should at minimum include the host header / authority and upstream peer\u2019s HTTP scheme.\u003c/span\u003e\u003c/p\u003e\u003c/b\u003e\u003cbr\u003e\u003cbr\u003e"
            }
          ],
          "value": "A cache poisoning vulnerability has been found in the Pingora HTTP proxy framework\u2019s default cache key construction. The issue occurs because the default HTTP cache key implementation generates cache keys using only the URI path, excluding critical factors such as the host header (authority). Operators relying on the default are vulnerable to cache poisoning, and cross-origin responses may be improperly served to users.\n\n\nImpact\n\nThis vulnerability affects users of Pingora\u0027s alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for:\n\n  *  Cross-tenant data leakage: In multi-tenant deployments, poison the cache so that users from one tenant receive cached responses from another tenant\n\n\n  *  Cache poisoning attacks: Serve malicious content to legitimate users by poisoning shared cache entries\n\n\n\n\nCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as Cloudflare\u0027s default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.\n\n\nMitigation:\n\nWe strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher, which removes the insecure default cache key implementation. Users must now explicitly implement their own callback that includes appropriate factors such as Host header, origin server HTTP scheme, and other attributes their cache should vary on.\n\n\nPingora users on previous versions may also remove any of their default CacheKey usage and implement their own that should at minimum include the host header / authority and upstream peer\u2019s HTTP scheme."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.4,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "PASSIVE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-04T23:44:56.472Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "We strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher\u003cbr\u003e"
            }
          ],
          "value": "We strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Cache poisoning via insecure-by-default cache key",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003e\u003cp\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003ePingora users on previous versions may also remove any of their default \u003c/span\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003eCacheKey\u003c/span\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003e usage and implement their own that should at minimum include the host header / authority and upstream peer\u2019s HTTP scheme.\u003c/span\u003e\u003c/p\u003e\u003c/b\u003e"
            }
          ],
          "value": "Pingora users on previous versions may also remove any of their default CacheKey usage and implement their own that should at minimum include the host header / authority and upstream peer\u2019s HTTP scheme."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-2836",
    "datePublished": "2026-03-04T23:44:56.472Z",
    "dateReserved": "2026-02-19T21:33:42.425Z",
    "dateUpdated": "2026-03-06T18:24:11.367Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-2835",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-06T18:24:39.168924Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-06T18:24:48.150Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.8.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Rajat Raghav (xclow3n)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cspan style=\"background-color: transparent;\"\u003eAn HTTP Request Smuggling vulnerability (CWE-444) has been found in Pingora\u0027s parsing of HTTP/1.0 and Transfer-Encoding requests. The issue occurs due to improperly allowing HTTP/1.0 request bodies to be close-delimited and incorrect handling of multiple Transfer-Encoding values, allowing attackers to send HTTP/1.0 requests in a way that would desync Pingora\u2019s request framing from backend servers\u2019.\u003c/span\u003e\u003cb\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cbr\u003e\u003c/span\u003e\u003c/b\u003e\u003cbr\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eImpact\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eThis vulnerability primarily affects standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. An attacker could craft a malicious payload following this request that Pingora forwards to the backend in order to:\u003c/span\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eBypass proxy-level ACL controls and WAF logic\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePoison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePerform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as its ingress proxy layers forwarded HTTP/1.1 requests only, rejected ambiguous framing such as invalid Content-Length values, and forwarded a single Transfer-Encoding: chunked header for chunked requests.\u003c/span\u003e\u003c/p\u003e\u003cbr\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eMitigation:\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePingora users should upgrade to Pingora v0.8.0 or higher that fixes this issue by correctly parsing message length headers per RFC 9112 and strictly adhering to more RFC guidelines, including that HTTP request bodies are never close-delimited.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eAs a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact \u201cchunked\u201d string match.\u003c/span\u003e\u003c/p\u003e\u003cbr\u003e\u003cbr\u003e"
            }
          ],
          "value": "An HTTP Request Smuggling vulnerability (CWE-444) has been found in Pingora\u0027s parsing of HTTP/1.0 and Transfer-Encoding requests. The issue occurs due to improperly allowing HTTP/1.0 request bodies to be close-delimited and incorrect handling of multiple Transfer-Encoding values, allowing attackers to send HTTP/1.0 requests in a way that would desync Pingora\u2019s request framing from backend servers\u2019.\n\nImpact\n\nThis vulnerability primarily affects standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. An attacker could craft a malicious payload following this request that Pingora forwards to the backend in order to:\n\n  *  Bypass proxy-level ACL controls and WAF logic\n\n\n\n\n  *  Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests\n\n\n\n\n  *  Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP\n\n\n\n\nCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as its ingress proxy layers forwarded HTTP/1.1 requests only, rejected ambiguous framing such as invalid Content-Length values, and forwarded a single Transfer-Encoding: chunked header for chunked requests.\n\n\nMitigation:\n\nPingora users should upgrade to Pingora v0.8.0 or higher that fixes this issue by correctly parsing message length headers per RFC 9112 and strictly adhering to more RFC guidelines, including that HTTP request bodies are never close-delimited.\n\nAs a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact \u201cchunked\u201d string match."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 9.3,
            "baseSeverity": "CRITICAL",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-444",
              "description": "CWE-444 Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-04T23:32:41.186Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Pingora users should upgrade to Pingora v0.8.0 or higher\u003cbr\u003e"
            }
          ],
          "value": "Pingora users should upgrade to Pingora v0.8.0 or higher"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "HTTP Request Smuggling via HTTP/1.0 and Transfer-Encoding Misparsing",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eAs a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact \u201cchunked\u201d string match.\u003c/span\u003e\u003c/p\u003e\u003cbr\u003e"
            }
          ],
          "value": "As a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact \u201cchunked\u201d string match."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-2835",
    "datePublished": "2026-03-04T23:32:41.186Z",
    "dateReserved": "2026-02-19T21:24:24.726Z",
    "dateUpdated": "2026-03-06T18:24:48.150Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-2833",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-06T18:25:53.691901Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-06T18:26:03.825Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.8.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Rajat Raghav (xclow3n)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cspan style=\"background-color: transparent;\"\u003eAn HTTP request smuggling vulnerability (CWE-444) was found in Pingora\u0027s handling of HTTP/1.1 connection upgrades. The issue occurs when a Pingora proxy reads a request containing an Upgrade header, causing the proxy to pass through the rest of the bytes on the connection to a backend before the backend has accepted the upgrade. An attacker can thus directly forward a malicious payload after a request with an Upgrade header to that backend in a way that may be interpreted as a subsequent request header, bypassing proxy-level security controls and enabling cross-user session hijacking.\u003cbr\u003e\u003cbr\u003e\u003c/span\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eImpact\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eThis vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to:\u003c/span\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eBypass proxy-level ACL controls and WAF logic\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePoison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePerform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.\u003c/span\u003e\u003c/p\u003e\u003cbr\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eMitigation:\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePingora users should upgrade to Pingora v0.8.0 or higher\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cbr\u003e\u003c/span\u003e\u003c/p\u003e\u003cb\u003e\u003c/b\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eAs a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.\u003c/span\u003e\u003c/p\u003e"
            }
          ],
          "value": "An HTTP request smuggling vulnerability (CWE-444) was found in Pingora\u0027s handling of HTTP/1.1 connection upgrades. The issue occurs when a Pingora proxy reads a request containing an Upgrade header, causing the proxy to pass through the rest of the bytes on the connection to a backend before the backend has accepted the upgrade. An attacker can thus directly forward a malicious payload after a request with an Upgrade header to that backend in a way that may be interpreted as a subsequent request header, bypassing proxy-level security controls and enabling cross-user session hijacking.\n\nImpact\n\nThis vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to:\n\n  *  Bypass proxy-level ACL controls and WAF logic\n\n\n\n\n  *  Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests\n\n\n\n\n  *  Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP\n\n\n\n\nCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.\n\n\nMitigation:\n\nPingora users should upgrade to Pingora v0.8.0 or higher\n\n\nAs a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 9.3,
            "baseSeverity": "CRITICAL",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-444",
              "description": "CWE-444 Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-04T23:20:51.985Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Pingora users should upgrade to Pingora v0.8.0 or higher\u003cbr\u003e"
            }
          ],
          "value": "Pingora users should upgrade to Pingora v0.8.0 or higher"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "HTTP Request Smuggling via Premature Upgrade",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.\u003cbr\u003e"
            }
          ],
          "value": "As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-2833",
    "datePublished": "2026-03-04T23:20:51.985Z",
    "dateReserved": "2026-02-19T21:02:12.382Z",
    "dateUpdated": "2026-03-06T18:26:03.825Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-1229",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-02-24T15:04:09.395394Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-02-24T15:10:21.738Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "platforms": [
            "Go"
          ],
          "product": "CIRCL",
          "repo": "https://github.com/cloudflare/circl",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "1.6.3",
              "status": "affected",
              "version": "CIRCL up to version 1.6.2",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Guido Vranken"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cp\u003eThe CombinedMult function in the CIRCL ecc/p384 package (secp384r1 curve) produces an incorrect value for specific inputs. The issue is fixed by using complete addition formulas.\u003cbr\u003eECDH and ECDSA signing relying on this curve are not affected.\u003c/p\u003e\u003cp\u003eThe bug was fixed in \u003cstrong\u003e\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/cloudflare/circl/releases/tag/v1.6.3\"\u003ev1.6.3\u003c/a\u003e\u003c/strong\u003e.\u003c/p\u003e\u003c/div\u003e\u003c/div\u003e\u003c/div\u003e\u003c/div\u003e\u003c/div\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003c/div\u003e\u003c/div\u003e\u003c/div\u003e\u003cbr\u003e"
            }
          ],
          "value": "The CombinedMult function in the CIRCL ecc/p384 package (secp384r1 curve) produces an incorrect value for specific inputs. The issue is fixed by using complete addition formulas.\nECDH and ECDSA signing relying on this curve are not affected.\n\nThe bug was fixed in  v1.6.3 https://github.com/cloudflare/circl/releases/tag/v1.6.3 ."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "YES",
            "Recovery": "NOT_DEFINED",
            "Safety": "NEGLIGIBLE",
            "attackComplexity": "HIGH",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 2.9,
            "baseSeverity": "LOW",
            "exploitMaturity": "PROOF_OF_CONCEPT",
            "privilegesRequired": "NONE",
            "providerUrgency": "AMBER",
            "subAvailabilityImpact": "LOW",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/E:P/S:N/AU:Y/U:Amber",
            "version": "4.0",
            "vulnAvailabilityImpact": "LOW",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "LOW",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-682",
              "description": "CWE-682 Incorrect Calculation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-02-24T07:58:54.406Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/circl"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Incorrect calculation in CIRCL secp384r1 CombinedMult",
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-1229",
    "datePublished": "2026-02-24T07:58:54.406Z",
    "dateReserved": "2026-01-20T13:09:57.206Z",
    "dateUpdated": "2026-02-24T15:10:21.738Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-0933",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-01-23T18:58:09.879547Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-01-23T21:54:58.842Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "Wrangler",
          "product": "Wrangler",
          "repo": "https://github.com/cloudflare/workers-sdk",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThanOrEqual": "v3.114.16",
              "status": "affected",
              "version": "v3.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "v4.59.0",
              "status": "affected",
              "version": "v4.0.0",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "v2.0.15+"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003ch2\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cb\u003eSummary\u003c/b\u003e\u003c/span\u003e\u003c/h2\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eA command injection vulnerability (CWE-78) has been found to exist in the `wrangler pages deploy` command. The issue occurs because the `--commit-hash` parameter is passed directly to a shell command without proper validation or sanitization, allowing an attacker with control of `--commit-hash` to execute arbitrary commands on the system running Wrangler.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cbr\u003e\u003c/span\u003e\u003c/p\u003e\u003ch3\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cb\u003eRoot cause\u003c/b\u003e\u003c/span\u003e\u003c/h3\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eThe \u003c/span\u003e\u003cspan style=\"background-color: rgb(233, 238, 246);\"\u003ecommitHash\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e variable, derived from user input via the --commit-hash \u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003eCLI argument, is interpolated directly into a shell command using template literals (e.g., \u0026nbsp;\u003cspan style=\"background-color: rgb(233, 238, 246);\"\u003eexecSync(`git show -s --format=%B ${commitHash}`)\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e)\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e. Shell metacharacters are interpreted by the shell, enabling command execution.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cbr\u003e\u003c/span\u003e\u003c/p\u003e\u003ch3\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cb\u003eImpact\u003c/b\u003e\u003c/span\u003e\u003c/h3\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eThis vulnerability is generally hard to exploit, as it requires --commit-hash to be attacker controlled. The vulnerability primarily affects CI/CD environments where `wrangler pages deploy` is used in automated pipelines and the \u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003e--commit-hash\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u0026nbsp;parameter is populated from external, potentially untrusted sources. An attacker could exploit this to:\u003c/span\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cspan style=\"background-color: transparent;\"\u003eRun any shell command.\u003c/span\u003e\u003c/li\u003e\u003cli\u003eExfiltrate environment variables.\u003c/li\u003e\u003cli\u003eCompromise the CI runner to install backdoors or modify build artifacts.\u003c/li\u003e\u003c/ul\u003e\u003cbr\u003e\u003ch3\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cb\u003eCredits\u003c/b\u003e\u003c/span\u003e\u003c/h3\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003e Disclosed responsibly by \u003c/span\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003ekny4hacker.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u003cbr\u003e\u003c/span\u003e\u003c/p\u003e\u003ch3\u003eMitigation\u003cbr\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003e\u003cspan style=\"background-color: transparent;\"\u003eWrangler v4 users are requested to upgrade to Wrangler v4.59.1 or higher.\u003c/span\u003e\u003c/li\u003e\u003cli\u003eWrangler v3 users are requested to upgrade to \u003cspan style=\"background-color: transparent;\"\u003eWrangler v3.114.17 or higher.\u003c/span\u003e\u003c/li\u003e\u003cli\u003eUsers on Wrangler v2 (EOL) should upgrade to a supported major version.\u003c/li\u003e\u003c/ul\u003e\u003cbr\u003e\u003cbr\u003e"
            }
          ],
          "value": "SummaryA command injection vulnerability (CWE-78) has been found to exist in the `wrangler pages deploy` command. The issue occurs because the `--commit-hash` parameter is passed directly to a shell command without proper validation or sanitization, allowing an attacker with control of `--commit-hash` to execute arbitrary commands on the system running Wrangler.\n\n\n\n\nRoot causeThe commitHash variable, derived from user input via the --commit-hash CLI argument, is interpolated directly into a shell command using template literals (e.g., \u00a0execSync(`git show -s --format=%B ${commitHash}`)). Shell metacharacters are interpreted by the shell, enabling command execution.\n\n\n\n\nImpactThis vulnerability is generally hard to exploit, as it requires --commit-hash to be attacker controlled. The vulnerability primarily affects CI/CD environments where `wrangler pages deploy` is used in automated pipelines and the \n\n--commit-hash\u00a0parameter is populated from external, potentially untrusted sources. An attacker could exploit this to:\n\n  *  Run any shell command.\n  *  Exfiltrate environment variables.\n  *  Compromise the CI runner to install backdoors or modify build artifacts.\n\n\n\nCredits Disclosed responsibly by kny4hacker.\n\n\n\n\nMitigation\n  *  Wrangler v4 users are requested to upgrade to Wrangler v4.59.1 or higher.\n  *  Wrangler v3 users are requested to upgrade to Wrangler v3.114.17 or higher.\n  *  Users on Wrangler v2 (EOL) should upgrade to a supported major version."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7.7,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20 Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-01-20T22:58:05.212Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/workers-sdk"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "OS Command Injection in `wrangler pages deploy`",
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-0933",
    "datePublished": "2026-01-20T22:58:05.212Z",
    "dateReserved": "2026-01-14T08:27:27.244Z",
    "dateUpdated": "2026-01-23T21:54:58.842Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-13353",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-12-02T16:50:27.674442Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-12-02T16:54:23.544Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "github.com/cloudflare/gokey",
          "product": "gokey",
          "repo": "https://github.com/cloudflare/gokey",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.2.0",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\n  \u003cdiv\u003e\n    \u003cp\u003eIn gokey versions \u003ccode\u003e\u0026lt;0.2.0\u003c/code\u003e,\n a flaw in the seed decryption logic resulted in passwords incorrectly \nbeing derived solely from the initial vector and the AES-GCM \nauthentication tag of the key seed.\u003c/p\u003e\n\u003cp\u003eThis issue has been fixed in gokey version \u003ccode\u003e0.2.0\u003c/code\u003e. This is a breaking change. The fix has invalidated any passwords/secrets that were derived from the seed file (using the \u003ccode\u003e-s\u003c/code\u003e option). Even if the input seed file stays the same, version \u003ccode\u003e0.2.0\u003c/code\u003e gokey will generate different secrets.\u003c/p\u003e\n\u003ch3\u003eImpact\u003c/h3\u003e\n\u003cp\u003eThis vulnerability impacts generated keys/secrets using a seed file as an entropy input (using the \u003ccode\u003e-s\u003c/code\u003e option). Keys/secrets generated just from the master password (without the \u003ccode\u003e-s\u003c/code\u003e\n option) are not impacted. The confidentiality of the seed itself is \nalso not impacted (it is not required to regenerate the seed itself). \nSpecific impact includes:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ekeys/secrets generated from a seed file may have lower entropy: it \nwas expected that the whole seed would be used to generate keys (240 \nbytes of entropy input), where in vulnerable versions only 28 bytes was \nused\u003c/li\u003e\n\u003cli\u003ea malicious entity could have recovered all passwords, generated \nfrom a particular seed, having only the seed file in possession without \nthe knowledge of the seed master password\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003ePatches\u003c/h3\u003e\n\u003cp\u003eThe code logic bug has been fixed in gokey version \u003ccode\u003e0.2.0\u003c/code\u003e\n and above. Due to the deterministic nature of gokey, fixed versions \nwill produce different passwords/secrets using seed files, as all seed \nentropy will be used now.\u003c/p\u003e\n\u003ch3\u003eSystem secret rotation guidance\u003c/h3\u003e\n\u003cp\u003eIt is advised for users to regenerate passwords/secrets using the patched version of gokey (\u003ccode\u003e0.2.0\u003c/code\u003e\n and above), and provision/rotate these secrets into respective systems \nin place of the old secret. A specific rotation procedure is \nsystem-dependent, but most common patterns are described below.\u003c/p\u003e\n\u003ch4\u003eSystems that do not require the old password/secret for rotation\u003c/h4\u003e\n\u003cp\u003eSuch systems usually have a \"Forgot password\" facility or a\n similar facility allowing users to rotate their password/secrets by \nsending a unique \"magic\" link to the user\u0027s email or phone. In such \ncases users are advised to use this facility and input the newly \ngenerated password secret, when prompted by the system.\u003c/p\u003e\n\u003ch4\u003eSystems that require the old password/secret for rotation\u003c/h4\u003e\n\u003cp\u003eSuch systems usually have a modal password rotation window\n usually in the user settings section requiring the user to input the \nold and the new password sometimes with a confirmation. To \ngenerate/recover the old password in such cases users are advised to:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003etemporarily download \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/cloudflare/gokey/releases/tag/v0.1.3\"\u003egokey version \u003ccode\u003e0.1.3\u003c/code\u003e\u003c/a\u003e for their respective operating system to recover the old password\u003c/li\u003e\n\u003cli\u003euse gokey version \u003ccode\u003e0.2.0\u003c/code\u003e or above to generate the new password\u003c/li\u003e\n\u003cli\u003epopulate the system provided password rotation form\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch4\u003eSystems that allow multiple credentials for the same account to be provisioned\u003c/h4\u003e\n\u003cp\u003eSuch systems usually require a secret or a cryptographic \nkey as a credential for access, but allow several credentials at the \nsame time. One example is SSH: a particular user may have several \nauthorized public keys configured on the SSH server for access. For such\n systems users are advised to:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003egenerate a new secret/key/credential using gokey version \u003ccode\u003e0.2.0\u003c/code\u003e or above\u003c/li\u003e\n\u003cli\u003eprovision the new secret/key/credential in addition to the existing credential on the system\u003c/li\u003e\n\u003cli\u003everify that the access or required system operation is still possible with the new secret/key/credential\u003c/li\u003e\n\u003cli\u003erevoke authorization for the existing/old credential from the system\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003eCredit\u003c/h3\u003e\n\u003cp\u003eThis vulnerability was found by Th\u00e9o Cusnir (\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://hackerone.com/mister_mime?type=user\"\u003e@mister_mime\u003c/a\u003e) and responsibly disclosed through Cloudflare\u0027s bug bounty program.\u003c/p\u003e\n  \u003c/div\u003e\n\u003c/div\u003e\u003cbr\u003e"
            }
          ],
          "value": "In gokey versions \u003c0.2.0,\n a flaw in the seed decryption logic resulted in passwords incorrectly \nbeing derived solely from the initial vector and the AES-GCM \nauthentication tag of the key seed.\n\n\nThis issue has been fixed in gokey version 0.2.0. This is a breaking change. The fix has invalidated any passwords/secrets that were derived from the seed file (using the -s option). Even if the input seed file stays the same, version 0.2.0 gokey will generate different secrets.\n\n\nImpact\nThis vulnerability impacts generated keys/secrets using a seed file as an entropy input (using the -s option). Keys/secrets generated just from the master password (without the -s\n option) are not impacted. The confidentiality of the seed itself is \nalso not impacted (it is not required to regenerate the seed itself). \nSpecific impact includes:\n\n\n\n  *  keys/secrets generated from a seed file may have lower entropy: it \nwas expected that the whole seed would be used to generate keys (240 \nbytes of entropy input), where in vulnerable versions only 28 bytes was \nused\n\n  *  a malicious entity could have recovered all passwords, generated \nfrom a particular seed, having only the seed file in possession without \nthe knowledge of the seed master password\n\n\n\n\nPatches\nThe code logic bug has been fixed in gokey version 0.2.0\n and above. Due to the deterministic nature of gokey, fixed versions \nwill produce different passwords/secrets using seed files, as all seed \nentropy will be used now.\n\n\nSystem secret rotation guidance\nIt is advised for users to regenerate passwords/secrets using the patched version of gokey (0.2.0\n and above), and provision/rotate these secrets into respective systems \nin place of the old secret. A specific rotation procedure is \nsystem-dependent, but most common patterns are described below.\n\n\nSystems that do not require the old password/secret for rotation\nSuch systems usually have a \"Forgot password\" facility or a\n similar facility allowing users to rotate their password/secrets by \nsending a unique \"magic\" link to the user\u0027s email or phone. In such \ncases users are advised to use this facility and input the newly \ngenerated password secret, when prompted by the system.\n\n\nSystems that require the old password/secret for rotation\nSuch systems usually have a modal password rotation window\n usually in the user settings section requiring the user to input the \nold and the new password sometimes with a confirmation. To \ngenerate/recover the old password in such cases users are advised to:\n\n\n\n  *  temporarily download  gokey version 0.1.3 https://github.com/cloudflare/gokey/releases/tag/v0.1.3  for their respective operating system to recover the old password\n\n  *  use gokey version 0.2.0 or above to generate the new password\n\n  *  populate the system provided password rotation form\n\n\n\n\nSystems that allow multiple credentials for the same account to be provisioned\nSuch systems usually require a secret or a cryptographic \nkey as a credential for access, but allow several credentials at the \nsame time. One example is SSH: a particular user may have several \nauthorized public keys configured on the SSH server for access. For such\n systems users are advised to:\n\n\n\n  *  generate a new secret/key/credential using gokey version 0.2.0 or above\n\n  *  provision the new secret/key/credential in addition to the existing credential on the system\n\n  *  verify that the access or required system operation is still possible with the new secret/key/credential\n\n  *  revoke authorization for the existing/old credential from the system\n\n\n\n\nCredit\nThis vulnerability was found by Th\u00e9o Cusnir ( @mister_mime https://hackerone.com/mister_mime ) and responsibly disclosed through Cloudflare\u0027s bug bounty program."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "LOCAL",
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "HIGH",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-330",
              "description": "CWE-330 Use of Insufficiently Random Values",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-12-02T11:03:21.832Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/gokey/security/advisories/GHSA-69jw-4jj8-fcxm"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "gokey allows secret recovery from a seed file without the master password",
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2025-13353",
    "datePublished": "2025-12-02T11:03:21.832Z",
    "dateReserved": "2025-11-18T11:21:27.669Z",
    "dateUpdated": "2025-12-02T16:54:23.544Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-105299",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-20T19:18:45.445676Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-444",
                "description": "CWE-444 Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-20T19:19:36.616Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.9.0",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Reported by thesmartshadow (GitHub)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSummary\u003c/p\u003e\u003cp\u003eBefore version 0.9.0, the HTTP/1 upstream path in pingora-proxy passed the downstream request through upstream_request_filter and wrote it to the upstream without removing the client\u0027s Connection header, other hop-by-hop headers, or the headers Connection nominated, although RFC 9110 Section 7.6.1 requires intermediaries to remove them. The HTTP/2 upstream path already removed Connection and related HTTP/1-specific headers. A client could therefore nominate a header that the application adds in upstream_request_filter (for example, Connection: keep-alive, X-Forwarded-For). A downstream HTTP/1 intermediary that honors Connection would then strip the Pingora-added header before it reached the origin.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eImpact\u003c/p\u003e\u003cp\u003eSpecifically affects chained deployments where an HTTP/1 intermediary between Pingora and the origin processes Connection nominations (for example, Go\u0027s net/http/httputil.ReverseProxy) and the origin trusts headers added by that intermediary (for example, X-Forwarded-For for IP-based authorization). A remote, unauthenticated attacker can have those headers removed, potentially bypassing authorization. The reporter demonstrated access to an IP-restricted endpoint using X-Forwarded-For for IP validation on the origin. This is the same class of issue as CVE-2022-31813 in Apache HTTP Server.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eNote that Cloudflare CDN customers were unaffected, as no such chained deployment as described above exists with internal Pingora services, and Connection headers are sanitized before arriving at Pingora gateways.\u003c/p\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits: \u003ca href=\"https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded\"\u003ehttps://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded\u003c/a\u003e, \u003ca href=\"https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee\"\u003ehttps://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee\u003c/a\u003e\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eDo not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eIf you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e"
            }
          ],
          "value": "Summary\n\n\n\nBefore version 0.9.0, the HTTP/1 upstream path in pingora-proxy passed the downstream request through upstream_request_filter and wrote it to the upstream without removing the client\u0027s Connection header, other hop-by-hop headers, or the headers Connection nominated, although RFC 9110 Section 7.6.1 requires intermediaries to remove them. The HTTP/2 upstream path already removed Connection and related HTTP/1-specific headers. A client could therefore nominate a header that the application adds in upstream_request_filter (for example, Connection: keep-alive, X-Forwarded-For). A downstream HTTP/1 intermediary that honors Connection would then strip the Pingora-added header before it reached the origin.\n\n\n\n\nImpact\n\n\n\nSpecifically affects chained deployments where an HTTP/1 intermediary between Pingora and the origin processes Connection nominations (for example, Go\u0027s net/http/httputil.ReverseProxy) and the origin trusts headers added by that intermediary (for example, X-Forwarded-For for IP-based authorization). A remote, unauthenticated attacker can have those headers removed, potentially bypassing authorization. The reporter demonstrated access to an IP-restricted endpoint using X-Forwarded-For for IP validation on the origin. This is the same class of issue as CVE-2022-31813 in Apache HTTP Server.\n\n\n\n\nNote that Cloudflare CDN customers were unaffected, as no such chained deployment as described above exists with internal Pingora services, and Connection headers are sanitized before arriving at Pingora gateways.\n\n\n\nMitigation:\n\n  *  \n\nUpgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits:  https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded ,  https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee \n\n\n  *  \n\nDo not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.\n\n\n  *  \n\nIf you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-20T01:07:12.767Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits: \u003ca href=\"https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded\"\u003ehttps://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded\u003c/a\u003e, \u003ca href=\"https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee\"\u003ehttps://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee\u003c/a\u003e\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eDo not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eIf you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e"
            }
          ],
          "value": "Mitigation:\n\n  *  \n\nUpgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits:  https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded ,  https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee \n\n\n  *  \n\nDo not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.\n\n\n  *  \n\nIf you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Pingora forwards client-nominated Connection headers to HTTP/1 upstreams, allowing ACL bypass in specific chained deployments",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-105299",
    "datePublished": "2026-10-20T01:07:12.767Z",
    "dateReserved": "2026-10-05T04:19:00.725Z",
    "dateUpdated": "2026-10-20T19:19:36.616Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-105298",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-20T19:19:49.025330Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-444",
                "description": "CWE-444 Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-20T19:20:10.015Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.9.0",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Reported by bipol4r (GitHub)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSummary\u003c/p\u003e\u003cp\u003eBefore 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.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eRoot cause\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eHTTP/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.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eHTTP/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.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eThe HTTP/2 server did not compare Host with :authority and did not reject userinfo in the authority.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cbr\u003e\u003cp\u003eImpact\u003c/p\u003e\u003cp\u003eA 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:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eCache poisoning: a response from another virtual host is stored under the victim host\u0027s cache key and served to other users (this also requires the upstream to serve different content per Host).\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eHost-based access control bypass: a request approved for one host is served by a different virtual host on the upstream.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDeployments that do not accept HTTP/2 from clients, or that do not use the request authority for security or caching decisions, are not affected.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eNote that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.\u003c/p\u003e\u003cbr\u003e\u003cdiv\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade 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: \u003ca href=\"https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b\"\u003ehttps://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b\u003c/a\u003e, \u003ca href=\"https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76\"\u003ehttps://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76\u003c/a\u003e\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eIf you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains \u0027@\u0027.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/div\u003e"
            }
          ],
          "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\u0027s 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 \u0027@\u0027."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-20T00:46:21.902Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade 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: \u003ca href=\"https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b\"\u003ehttps://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b\u003c/a\u003e, \u003ca href=\"https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76\"\u003ehttps://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76\u003c/a\u003e\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eIf you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains \u0027@\u0027.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/b\u003e"
            }
          ],
          "value": "Mitigation:\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 \u0027@\u0027."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Pingora HTTP/2 :authority and Host header mismatch enables cache poisoning and host-based access control bypass",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-105298",
    "datePublished": "2026-10-20T00:46:21.902Z",
    "dateReserved": "2026-10-05T04:18:59.291Z",
    "dateUpdated": "2026-10-20T19:20:10.015Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-105297",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-20T19:20:25.097096Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-20T19:20:35.542Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.8.1",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Reported by jro-calif (GitHub)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSummary\u003c/p\u003e\u003cp\u003eBefore version 0.8.1, Pingora\u0027s HTTP/2 server used the h2 crate\u0027s default limits unless the application set its own 16 MiB decoded header-list size and no limit on concurrent streams. A remote, unauthenticated client can send 1-byte HPACK references to a near-empty header, making the server allocate hundreds of thousands of header fields per stream across an unlimited number of streams on one connection, and use HTTP/2 flow control to keep those streams open. This can exhaust memory and degrade or terminate the Pingora process.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eImpact\u003c/p\u003e\u003cp\u003eRemote, unauthenticated denial of service against any Pingora service that terminates HTTP/2 (h2 or h2c) without explicitly setting max_header_list_size and max_concurrent_streams. The reporter showed that a single connection could get a Pingora process with a 2 GiB memory limit OOM-killed.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eNote that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.\u003c/p\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade to pingora 0.8.1 or later (fix: \u003ca href=\"https://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd\"\u003ehttps://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd\u003c/a\u003e). When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eApplications that supply their own H2Options are not covered by these defaults and must set max_header_list_size and max_concurrent_streams explicitly (this also works on versions before 0.8.1), or, on 0.8.1 and later, start from pingora_core::protocols::http::v2::server::default_h2_options(). H2Options::default() does not include these limits.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e"
            }
          ],
          "value": "Summary\n\n\n\nBefore version 0.8.1, Pingora\u0027s HTTP/2 server used the h2 crate\u0027s default limits unless the application set its own 16 MiB decoded header-list size and no limit on concurrent streams. A remote, unauthenticated client can send 1-byte HPACK references to a near-empty header, making the server allocate hundreds of thousands of header fields per stream across an unlimited number of streams on one connection, and use HTTP/2 flow control to keep those streams open. This can exhaust memory and degrade or terminate the Pingora process.\n\n\n\n\nImpact\n\n\n\nRemote, unauthenticated denial of service against any Pingora service that terminates HTTP/2 (h2 or h2c) without explicitly setting max_header_list_size and max_concurrent_streams. The reporter showed that a single connection could get a Pingora process with a 2 GiB memory limit OOM-killed.\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\nMitigation:\n\n  *  \n\nUpgrade to pingora 0.8.1 or later (fix:  https://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd ). When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection.\n\n\n  *  \n\nApplications that supply their own H2Options are not covered by these defaults and must set max_header_list_size and max_concurrent_streams explicitly (this also works on versions before 0.8.1), or, on 0.8.1 and later, start from pingora_core::protocols::http::v2::server::default_h2_options(). H2Options::default() does not include these limits."
        }
      ],
      "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"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of resources without limits or throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-20T00:40:27.300Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUpgrade to pingora 0.8.1 or later (fix: \u003ca href=\"https://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd\"\u003ehttps://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd\u003c/a\u003e). When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eApplications that supply their own H2Options are not covered by these defaults and must set max_header_list_size and max_concurrent_streams explicitly (this also works on versions before 0.8.1), or, on 0.8.1 and later, start from pingora_core::protocols::http::v2::server::default_h2_options(). H2Options::default() does not include these limits.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/b\u003e"
            }
          ],
          "value": "Mitigation:\n\n  *  \n\nUpgrade to pingora 0.8.1 or later (fix:  https://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd ). When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection.\n\n\n  *  \n\nApplications that supply their own H2Options are not covered by these defaults and must set max_header_list_size and max_concurrent_streams explicitly (this also works on versions before 0.8.1), or, on 0.8.1 and later, start from pingora_core::protocols::http::v2::server::default_h2_options(). H2Options::default() does not include these limits."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Pingora HTTP/2 server memory exhaustion through unbounded default header-list and concurrent-stream limits",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-105297",
    "datePublished": "2026-10-20T00:40:27.300Z",
    "dateReserved": "2026-10-05T04:18:56.102Z",
    "dateUpdated": "2026-10-20T19:20:35.542Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-11325",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-12T12:05:26.217219Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-12T12:06:10.745Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "affected",
          "product": "https://github.com/cloudflare/pages-action",
          "repo": "https://github.com/cloudflare/pages-action",
          "vendor": "Cloudflare",
          "versions": [
            {
              "status": "affected",
              "version": "0"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "@agentka99"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "@beg1nn3r"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eDescription\u003c/p\u003e\u003cp\u003eCloudflare was recently notified by external researchers of vulnerabilities in this archived repository, including a remote code execution issue in `src/index.ts` reachable from certain GitHub Actions workflow configurations. Successful exploitation may expose workflow secrets such as CLOUDFLARE_API_TOKEN and GITHUB_TOKEN to an attacker. Because this repository has been deprecated since 2024, Cloudflare will not be issuing patches. To remediate this issue, we recommend migrating to `cloudflare/wrangler-action` immediately. Consumers who have already migrated are not affected.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eSunset Date\u003c/p\u003e\u003cp\u003eThe cloudflare/pages-action repository will be removed on 2026-09-18. Consumers must complete migration before 18th September to avoid CI disruption.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eAffected Versions\u003c/p\u003e\u003cp\u003eAll published versions of cloudflare/pages-action, including consumers pinned to the v1 moving tag.\u003c/p\u003e\u003cbr\u003e\u003cp\u003ePatched Versions\u003c/p\u003e\u003cp\u003eNone. This repository will not receive further updates, including security patches.\u003c/p\u003e\u003cbr\u003e\u003cp\u003e\u003cb\u003eResolution / Migration Path\u003c/b\u003e\u003cbr\u003eMigrate all workflows using cloudflare/pages-action to `cloudflare/wrangler-action` before 2026-09-18. Refer to the wrangler-action README for the equivalent step configuration and migration guidance.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eCredit\u003c/p\u003e\u003cp\u003eThanks to @agentka99 and @beg1nn3r for reporting their findings via Cloudflare\u0027s HackerOne program that informe\u003c/p\u003e\u003cbr\u003e"
            }
          ],
          "value": "Description\n\n\n\nCloudflare was recently notified by external researchers of vulnerabilities in this archived repository, including a remote code execution issue in `src/index.ts` reachable from certain GitHub Actions workflow configurations. Successful exploitation may expose workflow secrets such as CLOUDFLARE_API_TOKEN and GITHUB_TOKEN to an attacker. Because this repository has been deprecated since 2024, Cloudflare will not be issuing patches. To remediate this issue, we recommend migrating to `cloudflare/wrangler-action` immediately. Consumers who have already migrated are not affected.\n\n\n\n\nSunset Date\n\n\n\nThe cloudflare/pages-action repository will be removed on 2026-09-18. Consumers must complete migration before 18th September to avoid CI disruption.\n\n\n\n\nAffected Versions\n\n\n\nAll published versions of cloudflare/pages-action, including consumers pinned to the v1 moving tag.\n\n\n\n\nPatched Versions\n\n\n\nNone. This repository will not receive further updates, including security patches.\n\n\n\n\nResolution / Migration Path\nMigrate all workflows using cloudflare/pages-action to `cloudflare/wrangler-action` before 2026-09-18. Refer to the wrangler-action README for the equivalent step configuration and migration guidance.\n\n\n\n\nCredit\n\n\n\nThanks to @agentka99 and @beg1nn3r for reporting their findings via Cloudflare\u0027s HackerOne program that informe"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-78",
              "description": "CWE-78 Improper neutralization of special elements used in an OS command (\u0027OS command injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-1104",
              "description": "CWE-1104 Use of unmaintained third party components",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-12T11:38:41.565Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/cloudflare/wrangler-action"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "cloudflare/pages-action is deprecated \u2014 migration required by September 18th, 2026",
      "x_generator": {
        "engine": "Vulnogram 1.0.4"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-11325",
    "datePublished": "2026-08-12T11:31:15.102Z",
    "dateReserved": "2026-06-04T23:49:45.491Z",
    "dateUpdated": "2026-08-12T12:06:10.745Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-12523",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-15T14:08:33.441723Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-400",
                "description": "CWE-400 Uncontrolled Resource Consumption",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-15T17:47:52.441Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "quiche",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.29.3",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "S\u00e9bastien F\u00e9ry"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSummary\u003c/p\u003e\u003cp\u003eCloudflare quiche\u0027s HTTP/3 layer was discovered to be vulnerable to resource exhaustion (i.e., memory) by means of specially crafted HTTP/3 frames.\u003c/p\u003e\u003cbr\u003e\u003cdiv\u003e\u003cp\u003eImpact\u003c/p\u003e\u003cp\u003eHTTP/3 defines multiple frame types to support HTTP message exchanges and connection management. Each frame has a length and a payload whose length depends on the frame type. quiche was found to be vulnerable when parsing some frame types to pre-allocating memory based on the declared length. An attacker would not need to send the number of declared bytes to trigger this issue.\u003c/p\u003e\u003cp\u003eIn addition, quiche was found to not apply QPACK decompression limits correctly. This could allow an attacker to send specially crafted HEADERS frames that would cause more memory commitment than otherwise advertised by MAX_FIELD_SECTION_SIZE (configured by set_max_field_section_size()).\u003c/p\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eUsers are requested to upgrade to quiche 0.29.3 which is the earliest version containing the fix for this issue.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003c/div\u003e\u003cdiv\u003e\u003cb\u003eCredits: \u003c/b\u003eDisclosed responsibly by S\u00e9bastien F\u00e9ry\u0026nbsp;\u003c/div\u003e"
            }
          ],
          "value": "Summary\n\n\n\nCloudflare quiche\u0027s HTTP/3 layer was discovered to be vulnerable to resource exhaustion (i.e., memory) by means of specially crafted HTTP/3 frames.\n\n\n\n\nImpact\n\n\n\nHTTP/3 defines multiple frame types to support HTTP message exchanges and connection management. Each frame has a length and a payload whose length depends on the frame type. quiche was found to be vulnerable when parsing some frame types to pre-allocating memory based on the declared length. An attacker would not need to send the number of declared bytes to trigger this issue.\n\n\n\nIn addition, quiche was found to not apply QPACK decompression limits correctly. This could allow an attacker to send specially crafted HEADERS frames that would cause more memory commitment than otherwise advertised by MAX_FIELD_SECTION_SIZE (configured by set_max_field_section_size()).\n\n\n\n\n\n\nMitigation:\n\n  *  \n\nUsers are requested to upgrade to quiche 0.29.3 which is the earliest version containing the fix for this issue.\n\n\n\n\n\n\n\n\n\nCredits: Disclosed responsibly by S\u00e9bastien F\u00e9ry"
        }
      ],
      "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"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-14T15:51:28.886Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/quiche/security/advisories/GHSA-4fgf-9xrr-88gf"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Resource exhaustion in quiche HTTP/3 and QPACK layers",
      "x_generator": {
        "engine": "Vulnogram 1.0.2"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-12523",
    "datePublished": "2026-07-14T15:51:28.886Z",
    "dateReserved": "2026-06-17T13:35:37.498Z",
    "dateUpdated": "2026-07-15T17:47:52.441Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-12707",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-14T15:57:40.409163Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-14T15:57:47.140Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "quiche",
          "repo": "https://github.com/cloudflare/quiche",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.29.3",
              "status": "affected",
              "version": "0.15.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSummary\u003c/p\u003e\u003cp\u003eCloudflare quiche was discovered to be vulnerable to memory resource exhaustion due to unbounded queuing of post-handshake client migration events.\u003c/p\u003e\u003cp\u003eImpact\u003c/p\u003e\u003cp\u003equiche supports the connection migration features described in Section 9 of RFC 9000, which allows a single QUIC connection to survive changes in the network path. Although quiche implements the protections described in Section 9.3 of RFC 9000 to limit server state commitment, it was discovered that the collection of PathEvents, intended to be consumed by applications via the path_event_next() function, was not bounded.\u003c/p\u003e\u003cp\u003eOnce the QUIC handshake completed, a peer could exploit rapid source address migration in order to cause unbounded queuing of the PathEvent::ReusedSourceConnectionId type. Servers are vulnerable even if active connection migration is disabled.\u003c/p\u003e\u003cp\u003eMitigation:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003eApplications can call path_event_next() to drain the PathEvent collection, mitigating the attack.\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003eUsers are requested to upgrade to quiche 0.29.3 which is the earliest version that prevents excessive queueing of PathEvent::ReusedSourceConnectionId.\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e"
            }
          ],
          "value": "Summary\n\n\n\nCloudflare quiche was discovered to be vulnerable to memory resource exhaustion due to unbounded queuing of post-handshake client migration events.\n\n\n\nImpact\n\n\n\nquiche supports the connection migration features described in Section 9 of RFC 9000, which allows a single QUIC connection to survive changes in the network path. Although quiche implements the protections described in Section 9.3 of RFC 9000 to limit server state commitment, it was discovered that the collection of PathEvents, intended to be consumed by applications via the path_event_next() function, was not bounded.\n\n\n\nOnce the QUIC handshake completed, a peer could exploit rapid source address migration in order to cause unbounded queuing of the PathEvent::ReusedSourceConnectionId type. Servers are vulnerable even if active connection migration is disabled.\n\n\n\nMitigation:\n\n  *  \n\nApplications can call path_event_next() to drain the PathEvent collection, mitigating the attack.\n\n\n  *  \n\nUsers are requested to upgrade to quiche 0.29.3 which is the earliest version that prevents excessive queueing of PathEvent::ReusedSourceConnectionId."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-130",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-130 Excessive Allocation"
            }
          ]
        }
      ],
      "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"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of resources without limits or throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-14T15:18:24.104Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/quiche/security/advisories/GHSA-4q5x-gp38-rfp4"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Unbounded path event queue growth in quiche via peer-driven source connection ID rotation",
      "x_generator": {
        "engine": "Vulnogram 1.0.2"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-12707",
    "datePublished": "2026-07-14T15:18:24.104Z",
    "dateReserved": "2026-06-19T10:27:48.087Z",
    "dateUpdated": "2026-07-14T15:57:47.140Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "HIGH",
              "attackVector": "ADJACENT_NETWORK",
              "availabilityImpact": "NONE",
              "baseScore": 6.8,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "HIGH",
              "integrityImpact": "HIGH",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-14440",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-02T19:22:08.681269Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-693",
                "description": "CWE-693 Protection Mechanism Failure",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-02T19:22:18.404Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "technical-description",
              "exploit"
            ],
            "url": "https://david-osipov.vision/en/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/"
          },
          {
            "tags": [
              "related"
            ],
            "url": "https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999/10"
          },
          {
            "tags": [
              "related"
            ],
            "url": "https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930"
          },
          {
            "tags": [
              "technical-description",
              "exploit"
            ],
            "url": "https://zenodo.org/records/18330221"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "platforms": [
            "Cloud Service"
          ],
          "product": "Universal SSL",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThanOrEqual": "current",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003e\u003cb\u003eDescription:\u003c/b\u003e\u003c/p\u003e\u003cbr\u003e\u003cp\u003eTo issue and renew TLS certificates on behalf of customers, Cloudflare\u0027s Universal SSL feature automatically manages the CAA RRset for the customer\u0027s zone. This auto-managed RRset is permissive by design (e.g. \u0027issue \"letsencrypt.org\"\u0027 without parameters). On Universal SSL zones, Cloudflare\u0027s authoritative DNS serves this auto-managed RRset at query time, superseding any customer-configured CAA records on the zone. When a customer publishes a stricter CAA record using the RFC 8657 accounturi or validationmethods parameters, the Certificate Authority does not observe those parameters when evaluating the served RRset under RFC 8659. As a result, the RFC 8657 account-binding and validation-method-binding protections are not enforced end-to-end on Universal SSL zones. Successful exploitation could result in issuance of a browser-trusted TLS certificate to an attacker, enabling MITM against the affected domain.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eExploitation is non-trivial in practice: an attacker would need to hold an ACME account at one of the Certificate Authorities in the served CAA RRset and to simultaneously satisfy domain control validation across the multiple geographically distinct Network Perspectives the CA relies on for Multi-Perspective Issuance Corroboration. Cloudflare prefixes are anycast-announced from hundreds of locations globally, raising the bar against single-vantage-point BGP hijacks. Any resulting misissuance of a browser-trusted certificate is subject to Certificate Transparency logging required by major browsers, and would be visible to CT monitoring.\u003c/p\u003e\u003cp\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eMitigation:\u0026nbsp;\u003c/b\u003e\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eUniversal SSL\u0027s automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.\u0026nbsp;\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eCertificate Transparency monitoring is recommended for all customers as a general detection control.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cb\u003e\u003c/b\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eCredits:\u003c/b\u003e\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cb\u003e\u003c/b\u003e\u003cbr\u003e\u003c/p\u003e\u003cbr\u003e"
            }
          ],
          "value": "Description:\n\n\n\n\nTo issue and renew TLS certificates on behalf of customers, Cloudflare\u0027s Universal SSL feature automatically manages the CAA RRset for the customer\u0027s zone. This auto-managed RRset is permissive by design (e.g. \u0027issue \"letsencrypt.org\"\u0027 without parameters). On Universal SSL zones, Cloudflare\u0027s authoritative DNS serves this auto-managed RRset at query time, superseding any customer-configured CAA records on the zone. When a customer publishes a stricter CAA record using the RFC 8657 accounturi or validationmethods parameters, the Certificate Authority does not observe those parameters when evaluating the served RRset under RFC 8659. As a result, the RFC 8657 account-binding and validation-method-binding protections are not enforced end-to-end on Universal SSL zones. Successful exploitation could result in issuance of a browser-trusted TLS certificate to an attacker, enabling MITM against the affected domain.\n\n\n\n\nExploitation is non-trivial in practice: an attacker would need to hold an ACME account at one of the Certificate Authorities in the served CAA RRset and to simultaneously satisfy domain control validation across the multiple geographically distinct Network Perspectives the CA relies on for Multi-Perspective Issuance Corroboration. Cloudflare prefixes are anycast-announced from hundreds of locations globally, raising the bar against single-vantage-point BGP hijacks. Any resulting misissuance of a browser-trusted certificate is subject to Certificate Transparency logging required by major browsers, and would be visible to CT monitoring.\n\n\n\n\n\n\n\n\nMitigation:\u00a0\n\n\n\nCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal SSL\u0027s automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.\u00a0\n\n\n\nCertificate Transparency monitoring is recommended for all customers as a general detection control.\n\n\n\n\n\n\n\n\nCredits:\n\n\n\nDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher"
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "HIGH",
            "attackRequirements": "PRESENT",
            "attackVector": "ADJACENT",
            "baseScore": 7.6,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-01T22:35:10.353Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://developers.cloudflare.com/ssl/edge-certificates/caa-records/"
        },
        {
          "url": "https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/limitations/"
        },
        {
          "url": "https://www.rfc-editor.org/rfc/rfc8657"
        },
        {
          "url": "https://www.rfc-editor.org/rfc/rfc8659"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003e\u003cp\u003eCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\u003c/p\u003e\u003cp\u003eUniversal SSL\u0027s automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCertificate Transparency monitoring is recommended for all customers as a general detection control.\u003c/p\u003e\u003c/b\u003e\u003cbr\u003e"
            }
          ],
          "value": "Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal SSL\u0027s automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.\u00a0\n\n\n\nCertificate Transparency monitoring is recommended for all customers as a general detection control."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Cloudflare Universal SSL automatically managed CAA RRset supersedes customer-configured CAA records",
      "x_generator": {
        "engine": "Vulnogram 1.0.2"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-14440",
    "datePublished": "2026-07-01T22:35:10.353Z",
    "dateReserved": "2026-07-01T22:20:45.895Z",
    "dateUpdated": "2026-07-02T19:22:18.404Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-11941",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-06-22T15:09:49.880714Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-06-22T15:10:00.033Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Quiche",
          "repo": "https://github.com/cloudflare/quiche",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThanOrEqual": "0.29.1",
              "status": "affected",
              "version": "0.20.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "datePublic": "2026-06-19T09:49:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eCloudflare Quiche was affected by 2 use-after-free vulnerabilities in the connection ID iterator FFI functions.\u003c/p\u003e\u003cp\u003eThe \u201cquiche_connection_id_iter_next\u201d and \u201cquiche_conn_retired_scid_next\u201d functions would return a pointer to a \u201cConnectionId\u201d to the applications via function arguments, but the owned \u201cConnectionId\u201d would be dropped at the end of those functions\u0027 scope.\u003c/p\u003e\u003cp\u003eOnly applications using those FFI functions are affected. The FFI API is disabled by default by a build-time feature flag.\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eImpact\u003cbr\u003e\u003c/b\u003e\u003c/span\u003e\u003cspan\u003eIf unpatched, an application calling the affected FFI functions will dereference freed memory. The most likely outcome is undefined behavior leading to a process crash (denial of service). Depending on allocator state, the read may also return adjacent heap contents, resulting in limited information disclosure or incorrect connection identifier handling.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eMitigation\u003cbr\u003e\u003c/b\u003e\u003c/span\u003e\u003cspan\u003eUsers are requested to upgrade to quiche 0.29.2 which is the earliest version containing the fix for this issue.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cb\u003e\u003c/b\u003e\u003cbr\u003e\u003c/p\u003e\u003cbr\u003e"
            }
          ],
          "value": "Cloudflare Quiche was affected by 2 use-after-free vulnerabilities in the connection ID iterator FFI functions.\n\n\n\nThe \u201cquiche_connection_id_iter_next\u201d and \u201cquiche_conn_retired_scid_next\u201d functions would return a pointer to a \u201cConnectionId\u201d to the applications via function arguments, but the owned \u201cConnectionId\u201d would be dropped at the end of those functions\u0027 scope.\n\n\n\nOnly applications using those FFI functions are affected. The FFI API is disabled by default by a build-time feature flag.\n\n\n\nImpact\nIf unpatched, an application calling the affected FFI functions will dereference freed memory. The most likely outcome is undefined behavior leading to a process crash (denial of service). Depending on allocator state, the read may also return adjacent heap contents, resulting in limited information disclosure or incorrect connection identifier handling.\n\n\n\nMitigation\nUsers are requested to upgrade to quiche 0.29.2 which is the earliest version containing the fix for this issue."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 5.6,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-416",
              "description": "CWE-416 Use after free",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-06-19T09:55:54.501Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/quiche/security/advisories/GHSA-mh64-ph39-mrc9"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Use-after-free in connection ID iterator and FFI functions",
      "x_generator": {
        "engine": "Vulnogram 1.0.2"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-11941",
    "datePublished": "2026-06-19T09:55:54.501Z",
    "dateReserved": "2026-06-10T20:16:34.590Z",
    "dateUpdated": "2026-06-22T15:10:00.033Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-2836",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-06T18:23:54.507163Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-345",
                "description": "CWE-345 Insufficient Verification of Data Authenticity",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-06T18:24:11.367Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.8.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Rajat Raghav (xclow3n)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eA cache poisoning vulnerability has been found in the Pingora HTTP proxy framework\u2019s default cache key construction. The issue occurs because the default HTTP cache key implementation generates cache keys using only the URI path, excluding critical factors such as the host header (authority). Operators relying on the default are vulnerable to cache poisoning, and cross-origin responses may be improperly served to users.\u003c/span\u003e\u003c/p\u003e\u003c/b\u003e\u003cbr\u003e\u003cb\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eImpact\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eThis vulnerability affects users of Pingora\u0027s alpha proxy caching feature who relied on the default \u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003eCacheKey\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e implementation. An attacker could exploit this for:\u003c/span\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eCross-tenant data leakage: In multi-tenant deployments, poison the cache so that users from one tenant receive cached responses from another tenant\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eCache poisoning attacks: Serve malicious content to legitimate users by poisoning shared cache entries\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as Cloudflare\u0027s default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.\u003c/span\u003e\u003c/p\u003e\u003c/b\u003e\u003cbr\u003e\u003cb\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eMitigation:\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003eWe strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher, which removes the insecure default cache key implementation. Users must now explicitly implement their own callback that includes appropriate factors such as Host header, origin server HTTP scheme, and other attributes their cache should vary on.\u003c/span\u003e\u003c/p\u003e\u003cbr\u003e\u003cp\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003ePingora users on previous versions may also remove any of their default \u003c/span\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003eCacheKey\u003c/span\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003e usage and implement their own that should at minimum include the host header / authority and upstream peer\u2019s HTTP scheme.\u003c/span\u003e\u003c/p\u003e\u003c/b\u003e\u003cbr\u003e\u003cbr\u003e"
            }
          ],
          "value": "A cache poisoning vulnerability has been found in the Pingora HTTP proxy framework\u2019s default cache key construction. The issue occurs because the default HTTP cache key implementation generates cache keys using only the URI path, excluding critical factors such as the host header (authority). Operators relying on the default are vulnerable to cache poisoning, and cross-origin responses may be improperly served to users.\n\n\nImpact\n\nThis vulnerability affects users of Pingora\u0027s alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for:\n\n  *  Cross-tenant data leakage: In multi-tenant deployments, poison the cache so that users from one tenant receive cached responses from another tenant\n\n\n  *  Cache poisoning attacks: Serve malicious content to legitimate users by poisoning shared cache entries\n\n\n\n\nCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as Cloudflare\u0027s default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.\n\n\nMitigation:\n\nWe strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher, which removes the insecure default cache key implementation. Users must now explicitly implement their own callback that includes appropriate factors such as Host header, origin server HTTP scheme, and other attributes their cache should vary on.\n\n\nPingora users on previous versions may also remove any of their default CacheKey usage and implement their own that should at minimum include the host header / authority and upstream peer\u2019s HTTP scheme."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.4,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "PASSIVE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-04T23:44:56.472Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "We strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher\u003cbr\u003e"
            }
          ],
          "value": "We strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Cache poisoning via insecure-by-default cache key",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003e\u003cp\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003ePingora users on previous versions may also remove any of their default \u003c/span\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003eCacheKey\u003c/span\u003e\u003cspan style=\"background-color: rgb(244, 249, 250);\"\u003e usage and implement their own that should at minimum include the host header / authority and upstream peer\u2019s HTTP scheme.\u003c/span\u003e\u003c/p\u003e\u003c/b\u003e"
            }
          ],
          "value": "Pingora users on previous versions may also remove any of their default CacheKey usage and implement their own that should at minimum include the host header / authority and upstream peer\u2019s HTTP scheme."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-2836",
    "datePublished": "2026-03-04T23:44:56.472Z",
    "dateReserved": "2026-02-19T21:33:42.425Z",
    "dateUpdated": "2026-03-06T18:24:11.367Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-2835",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-06T18:24:39.168924Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-06T18:24:48.150Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.8.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Rajat Raghav (xclow3n)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cspan style=\"background-color: transparent;\"\u003eAn HTTP Request Smuggling vulnerability (CWE-444) has been found in Pingora\u0027s parsing of HTTP/1.0 and Transfer-Encoding requests. The issue occurs due to improperly allowing HTTP/1.0 request bodies to be close-delimited and incorrect handling of multiple Transfer-Encoding values, allowing attackers to send HTTP/1.0 requests in a way that would desync Pingora\u2019s request framing from backend servers\u2019.\u003c/span\u003e\u003cb\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cbr\u003e\u003c/span\u003e\u003c/b\u003e\u003cbr\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eImpact\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eThis vulnerability primarily affects standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. An attacker could craft a malicious payload following this request that Pingora forwards to the backend in order to:\u003c/span\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eBypass proxy-level ACL controls and WAF logic\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePoison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePerform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as its ingress proxy layers forwarded HTTP/1.1 requests only, rejected ambiguous framing such as invalid Content-Length values, and forwarded a single Transfer-Encoding: chunked header for chunked requests.\u003c/span\u003e\u003c/p\u003e\u003cbr\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eMitigation:\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePingora users should upgrade to Pingora v0.8.0 or higher that fixes this issue by correctly parsing message length headers per RFC 9112 and strictly adhering to more RFC guidelines, including that HTTP request bodies are never close-delimited.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eAs a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact \u201cchunked\u201d string match.\u003c/span\u003e\u003c/p\u003e\u003cbr\u003e\u003cbr\u003e"
            }
          ],
          "value": "An HTTP Request Smuggling vulnerability (CWE-444) has been found in Pingora\u0027s parsing of HTTP/1.0 and Transfer-Encoding requests. The issue occurs due to improperly allowing HTTP/1.0 request bodies to be close-delimited and incorrect handling of multiple Transfer-Encoding values, allowing attackers to send HTTP/1.0 requests in a way that would desync Pingora\u2019s request framing from backend servers\u2019.\n\nImpact\n\nThis vulnerability primarily affects standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. An attacker could craft a malicious payload following this request that Pingora forwards to the backend in order to:\n\n  *  Bypass proxy-level ACL controls and WAF logic\n\n\n\n\n  *  Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests\n\n\n\n\n  *  Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP\n\n\n\n\nCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as its ingress proxy layers forwarded HTTP/1.1 requests only, rejected ambiguous framing such as invalid Content-Length values, and forwarded a single Transfer-Encoding: chunked header for chunked requests.\n\n\nMitigation:\n\nPingora users should upgrade to Pingora v0.8.0 or higher that fixes this issue by correctly parsing message length headers per RFC 9112 and strictly adhering to more RFC guidelines, including that HTTP request bodies are never close-delimited.\n\nAs a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact \u201cchunked\u201d string match."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 9.3,
            "baseSeverity": "CRITICAL",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-444",
              "description": "CWE-444 Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-04T23:32:41.186Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Pingora users should upgrade to Pingora v0.8.0 or higher\u003cbr\u003e"
            }
          ],
          "value": "Pingora users should upgrade to Pingora v0.8.0 or higher"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "HTTP Request Smuggling via HTTP/1.0 and Transfer-Encoding Misparsing",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eAs a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact \u201cchunked\u201d string match.\u003c/span\u003e\u003c/p\u003e\u003cbr\u003e"
            }
          ],
          "value": "As a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact \u201cchunked\u201d string match."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-2835",
    "datePublished": "2026-03-04T23:32:41.186Z",
    "dateReserved": "2026-02-19T21:24:24.726Z",
    "dateUpdated": "2026-03-06T18:24:48.150Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-2833",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-06T18:25:53.691901Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-06T18:26:03.825Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "https://github.com/cloudflare/pingora",
          "repo": "https://github.com/cloudflare/pingora",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.8.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Rajat Raghav (xclow3n)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cspan style=\"background-color: transparent;\"\u003eAn HTTP request smuggling vulnerability (CWE-444) was found in Pingora\u0027s handling of HTTP/1.1 connection upgrades. The issue occurs when a Pingora proxy reads a request containing an Upgrade header, causing the proxy to pass through the rest of the bytes on the connection to a backend before the backend has accepted the upgrade. An attacker can thus directly forward a malicious payload after a request with an Upgrade header to that backend in a way that may be interpreted as a subsequent request header, bypassing proxy-level security controls and enabling cross-user session hijacking.\u003cbr\u003e\u003cbr\u003e\u003c/span\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eImpact\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eThis vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to:\u003c/span\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eBypass proxy-level ACL controls and WAF logic\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePoison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cul\u003e\u003cli\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePerform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP\u003c/span\u003e\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.\u003c/span\u003e\u003c/p\u003e\u003cbr\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eMitigation:\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003ePingora users should upgrade to Pingora v0.8.0 or higher\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cbr\u003e\u003c/span\u003e\u003c/p\u003e\u003cb\u003e\u003c/b\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eAs a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.\u003c/span\u003e\u003c/p\u003e"
            }
          ],
          "value": "An HTTP request smuggling vulnerability (CWE-444) was found in Pingora\u0027s handling of HTTP/1.1 connection upgrades. The issue occurs when a Pingora proxy reads a request containing an Upgrade header, causing the proxy to pass through the rest of the bytes on the connection to a backend before the backend has accepted the upgrade. An attacker can thus directly forward a malicious payload after a request with an Upgrade header to that backend in a way that may be interpreted as a subsequent request header, bypassing proxy-level security controls and enabling cross-user session hijacking.\n\nImpact\n\nThis vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to:\n\n  *  Bypass proxy-level ACL controls and WAF logic\n\n\n\n\n  *  Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests\n\n\n\n\n  *  Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP\n\n\n\n\nCloudflare\u0027s CDN infrastructure was not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.\n\n\nMitigation:\n\nPingora users should upgrade to Pingora v0.8.0 or higher\n\n\nAs a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 9.3,
            "baseSeverity": "CRITICAL",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-444",
              "description": "CWE-444 Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-04T23:20:51.985Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/pingora"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Pingora users should upgrade to Pingora v0.8.0 or higher\u003cbr\u003e"
            }
          ],
          "value": "Pingora users should upgrade to Pingora v0.8.0 or higher"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "HTTP Request Smuggling via Premature Upgrade",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.\u003cbr\u003e"
            }
          ],
          "value": "As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-2833",
    "datePublished": "2026-03-04T23:20:51.985Z",
    "dateReserved": "2026-02-19T21:02:12.382Z",
    "dateUpdated": "2026-03-06T18:26:03.825Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-1229",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-02-24T15:04:09.395394Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-02-24T15:10:21.738Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "platforms": [
            "Go"
          ],
          "product": "CIRCL",
          "repo": "https://github.com/cloudflare/circl",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "1.6.3",
              "status": "affected",
              "version": "CIRCL up to version 1.6.2",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Guido Vranken"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cp\u003eThe CombinedMult function in the CIRCL ecc/p384 package (secp384r1 curve) produces an incorrect value for specific inputs. The issue is fixed by using complete addition formulas.\u003cbr\u003eECDH and ECDSA signing relying on this curve are not affected.\u003c/p\u003e\u003cp\u003eThe bug was fixed in \u003cstrong\u003e\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/cloudflare/circl/releases/tag/v1.6.3\"\u003ev1.6.3\u003c/a\u003e\u003c/strong\u003e.\u003c/p\u003e\u003c/div\u003e\u003c/div\u003e\u003c/div\u003e\u003c/div\u003e\u003c/div\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003c/div\u003e\u003c/div\u003e\u003c/div\u003e\u003cbr\u003e"
            }
          ],
          "value": "The CombinedMult function in the CIRCL ecc/p384 package (secp384r1 curve) produces an incorrect value for specific inputs. The issue is fixed by using complete addition formulas.\nECDH and ECDSA signing relying on this curve are not affected.\n\nThe bug was fixed in  v1.6.3 https://github.com/cloudflare/circl/releases/tag/v1.6.3 ."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "YES",
            "Recovery": "NOT_DEFINED",
            "Safety": "NEGLIGIBLE",
            "attackComplexity": "HIGH",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 2.9,
            "baseSeverity": "LOW",
            "exploitMaturity": "PROOF_OF_CONCEPT",
            "privilegesRequired": "NONE",
            "providerUrgency": "AMBER",
            "subAvailabilityImpact": "LOW",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/E:P/S:N/AU:Y/U:Amber",
            "version": "4.0",
            "vulnAvailabilityImpact": "LOW",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "LOW",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-682",
              "description": "CWE-682 Incorrect Calculation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-02-24T07:58:54.406Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/circl"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Incorrect calculation in CIRCL secp384r1 CombinedMult",
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-1229",
    "datePublished": "2026-02-24T07:58:54.406Z",
    "dateReserved": "2026-01-20T13:09:57.206Z",
    "dateUpdated": "2026-02-24T15:10:21.738Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-0933",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-01-23T18:58:09.879547Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-01-23T21:54:58.842Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "Wrangler",
          "product": "Wrangler",
          "repo": "https://github.com/cloudflare/workers-sdk",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThanOrEqual": "v3.114.16",
              "status": "affected",
              "version": "v3.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "v4.59.0",
              "status": "affected",
              "version": "v4.0.0",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "v2.0.15+"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003ch2\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cb\u003eSummary\u003c/b\u003e\u003c/span\u003e\u003c/h2\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eA command injection vulnerability (CWE-78) has been found to exist in the `wrangler pages deploy` command. The issue occurs because the `--commit-hash` parameter is passed directly to a shell command without proper validation or sanitization, allowing an attacker with control of `--commit-hash` to execute arbitrary commands on the system running Wrangler.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cbr\u003e\u003c/span\u003e\u003c/p\u003e\u003ch3\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cb\u003eRoot cause\u003c/b\u003e\u003c/span\u003e\u003c/h3\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eThe \u003c/span\u003e\u003cspan style=\"background-color: rgb(233, 238, 246);\"\u003ecommitHash\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e variable, derived from user input via the --commit-hash \u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003eCLI argument, is interpolated directly into a shell command using template literals (e.g., \u0026nbsp;\u003cspan style=\"background-color: rgb(233, 238, 246);\"\u003eexecSync(`git show -s --format=%B ${commitHash}`)\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e)\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e. Shell metacharacters are interpreted by the shell, enabling command execution.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cbr\u003e\u003c/span\u003e\u003c/p\u003e\u003ch3\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cb\u003eImpact\u003c/b\u003e\u003c/span\u003e\u003c/h3\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003eThis vulnerability is generally hard to exploit, as it requires --commit-hash to be attacker controlled. The vulnerability primarily affects CI/CD environments where `wrangler pages deploy` is used in automated pipelines and the \u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003e--commit-hash\u003c/span\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u0026nbsp;parameter is populated from external, potentially untrusted sources. An attacker could exploit this to:\u003c/span\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cspan style=\"background-color: transparent;\"\u003eRun any shell command.\u003c/span\u003e\u003c/li\u003e\u003cli\u003eExfiltrate environment variables.\u003c/li\u003e\u003cli\u003eCompromise the CI runner to install backdoors or modify build artifacts.\u003c/li\u003e\u003c/ul\u003e\u003cbr\u003e\u003ch3\u003e\u003cspan style=\"background-color: transparent;\"\u003e\u003cb\u003eCredits\u003c/b\u003e\u003c/span\u003e\u003c/h3\u003e\u003cp\u003e\u003cspan style=\"background-color: transparent;\"\u003e Disclosed responsibly by \u003c/span\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003ekny4hacker.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u003cbr\u003e\u003c/span\u003e\u003c/p\u003e\u003ch3\u003eMitigation\u003cbr\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003e\u003cspan style=\"background-color: transparent;\"\u003eWrangler v4 users are requested to upgrade to Wrangler v4.59.1 or higher.\u003c/span\u003e\u003c/li\u003e\u003cli\u003eWrangler v3 users are requested to upgrade to \u003cspan style=\"background-color: transparent;\"\u003eWrangler v3.114.17 or higher.\u003c/span\u003e\u003c/li\u003e\u003cli\u003eUsers on Wrangler v2 (EOL) should upgrade to a supported major version.\u003c/li\u003e\u003c/ul\u003e\u003cbr\u003e\u003cbr\u003e"
            }
          ],
          "value": "SummaryA command injection vulnerability (CWE-78) has been found to exist in the `wrangler pages deploy` command. The issue occurs because the `--commit-hash` parameter is passed directly to a shell command without proper validation or sanitization, allowing an attacker with control of `--commit-hash` to execute arbitrary commands on the system running Wrangler.\n\n\n\n\nRoot causeThe commitHash variable, derived from user input via the --commit-hash CLI argument, is interpolated directly into a shell command using template literals (e.g., \u00a0execSync(`git show -s --format=%B ${commitHash}`)). Shell metacharacters are interpreted by the shell, enabling command execution.\n\n\n\n\nImpactThis vulnerability is generally hard to exploit, as it requires --commit-hash to be attacker controlled. The vulnerability primarily affects CI/CD environments where `wrangler pages deploy` is used in automated pipelines and the \n\n--commit-hash\u00a0parameter is populated from external, potentially untrusted sources. An attacker could exploit this to:\n\n  *  Run any shell command.\n  *  Exfiltrate environment variables.\n  *  Compromise the CI runner to install backdoors or modify build artifacts.\n\n\n\nCredits Disclosed responsibly by kny4hacker.\n\n\n\n\nMitigation\n  *  Wrangler v4 users are requested to upgrade to Wrangler v4.59.1 or higher.\n  *  Wrangler v3 users are requested to upgrade to Wrangler v3.114.17 or higher.\n  *  Users on Wrangler v2 (EOL) should upgrade to a supported major version."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7.7,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20 Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-01-20T22:58:05.212Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/workers-sdk"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "OS Command Injection in `wrangler pages deploy`",
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2026-0933",
    "datePublished": "2026-01-20T22:58:05.212Z",
    "dateReserved": "2026-01-14T08:27:27.244Z",
    "dateUpdated": "2026-01-23T21:54:58.842Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-13353",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-12-02T16:50:27.674442Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-12-02T16:54:23.544Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "github.com/cloudflare/gokey",
          "product": "gokey",
          "repo": "https://github.com/cloudflare/gokey",
          "vendor": "Cloudflare",
          "versions": [
            {
              "lessThan": "0.2.0",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\n  \u003cdiv\u003e\n    \u003cp\u003eIn gokey versions \u003ccode\u003e\u0026lt;0.2.0\u003c/code\u003e,\n a flaw in the seed decryption logic resulted in passwords incorrectly \nbeing derived solely from the initial vector and the AES-GCM \nauthentication tag of the key seed.\u003c/p\u003e\n\u003cp\u003eThis issue has been fixed in gokey version \u003ccode\u003e0.2.0\u003c/code\u003e. This is a breaking change. The fix has invalidated any passwords/secrets that were derived from the seed file (using the \u003ccode\u003e-s\u003c/code\u003e option). Even if the input seed file stays the same, version \u003ccode\u003e0.2.0\u003c/code\u003e gokey will generate different secrets.\u003c/p\u003e\n\u003ch3\u003eImpact\u003c/h3\u003e\n\u003cp\u003eThis vulnerability impacts generated keys/secrets using a seed file as an entropy input (using the \u003ccode\u003e-s\u003c/code\u003e option). Keys/secrets generated just from the master password (without the \u003ccode\u003e-s\u003c/code\u003e\n option) are not impacted. The confidentiality of the seed itself is \nalso not impacted (it is not required to regenerate the seed itself). \nSpecific impact includes:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ekeys/secrets generated from a seed file may have lower entropy: it \nwas expected that the whole seed would be used to generate keys (240 \nbytes of entropy input), where in vulnerable versions only 28 bytes was \nused\u003c/li\u003e\n\u003cli\u003ea malicious entity could have recovered all passwords, generated \nfrom a particular seed, having only the seed file in possession without \nthe knowledge of the seed master password\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003ePatches\u003c/h3\u003e\n\u003cp\u003eThe code logic bug has been fixed in gokey version \u003ccode\u003e0.2.0\u003c/code\u003e\n and above. Due to the deterministic nature of gokey, fixed versions \nwill produce different passwords/secrets using seed files, as all seed \nentropy will be used now.\u003c/p\u003e\n\u003ch3\u003eSystem secret rotation guidance\u003c/h3\u003e\n\u003cp\u003eIt is advised for users to regenerate passwords/secrets using the patched version of gokey (\u003ccode\u003e0.2.0\u003c/code\u003e\n and above), and provision/rotate these secrets into respective systems \nin place of the old secret. A specific rotation procedure is \nsystem-dependent, but most common patterns are described below.\u003c/p\u003e\n\u003ch4\u003eSystems that do not require the old password/secret for rotation\u003c/h4\u003e\n\u003cp\u003eSuch systems usually have a \"Forgot password\" facility or a\n similar facility allowing users to rotate their password/secrets by \nsending a unique \"magic\" link to the user\u0027s email or phone. In such \ncases users are advised to use this facility and input the newly \ngenerated password secret, when prompted by the system.\u003c/p\u003e\n\u003ch4\u003eSystems that require the old password/secret for rotation\u003c/h4\u003e\n\u003cp\u003eSuch systems usually have a modal password rotation window\n usually in the user settings section requiring the user to input the \nold and the new password sometimes with a confirmation. To \ngenerate/recover the old password in such cases users are advised to:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003etemporarily download \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/cloudflare/gokey/releases/tag/v0.1.3\"\u003egokey version \u003ccode\u003e0.1.3\u003c/code\u003e\u003c/a\u003e for their respective operating system to recover the old password\u003c/li\u003e\n\u003cli\u003euse gokey version \u003ccode\u003e0.2.0\u003c/code\u003e or above to generate the new password\u003c/li\u003e\n\u003cli\u003epopulate the system provided password rotation form\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch4\u003eSystems that allow multiple credentials for the same account to be provisioned\u003c/h4\u003e\n\u003cp\u003eSuch systems usually require a secret or a cryptographic \nkey as a credential for access, but allow several credentials at the \nsame time. One example is SSH: a particular user may have several \nauthorized public keys configured on the SSH server for access. For such\n systems users are advised to:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003egenerate a new secret/key/credential using gokey version \u003ccode\u003e0.2.0\u003c/code\u003e or above\u003c/li\u003e\n\u003cli\u003eprovision the new secret/key/credential in addition to the existing credential on the system\u003c/li\u003e\n\u003cli\u003everify that the access or required system operation is still possible with the new secret/key/credential\u003c/li\u003e\n\u003cli\u003erevoke authorization for the existing/old credential from the system\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003eCredit\u003c/h3\u003e\n\u003cp\u003eThis vulnerability was found by Th\u00e9o Cusnir (\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://hackerone.com/mister_mime?type=user\"\u003e@mister_mime\u003c/a\u003e) and responsibly disclosed through Cloudflare\u0027s bug bounty program.\u003c/p\u003e\n  \u003c/div\u003e\n\u003c/div\u003e\u003cbr\u003e"
            }
          ],
          "value": "In gokey versions \u003c0.2.0,\n a flaw in the seed decryption logic resulted in passwords incorrectly \nbeing derived solely from the initial vector and the AES-GCM \nauthentication tag of the key seed.\n\n\nThis issue has been fixed in gokey version 0.2.0. This is a breaking change. The fix has invalidated any passwords/secrets that were derived from the seed file (using the -s option). Even if the input seed file stays the same, version 0.2.0 gokey will generate different secrets.\n\n\nImpact\nThis vulnerability impacts generated keys/secrets using a seed file as an entropy input (using the -s option). Keys/secrets generated just from the master password (without the -s\n option) are not impacted. The confidentiality of the seed itself is \nalso not impacted (it is not required to regenerate the seed itself). \nSpecific impact includes:\n\n\n\n  *  keys/secrets generated from a seed file may have lower entropy: it \nwas expected that the whole seed would be used to generate keys (240 \nbytes of entropy input), where in vulnerable versions only 28 bytes was \nused\n\n  *  a malicious entity could have recovered all passwords, generated \nfrom a particular seed, having only the seed file in possession without \nthe knowledge of the seed master password\n\n\n\n\nPatches\nThe code logic bug has been fixed in gokey version 0.2.0\n and above. Due to the deterministic nature of gokey, fixed versions \nwill produce different passwords/secrets using seed files, as all seed \nentropy will be used now.\n\n\nSystem secret rotation guidance\nIt is advised for users to regenerate passwords/secrets using the patched version of gokey (0.2.0\n and above), and provision/rotate these secrets into respective systems \nin place of the old secret. A specific rotation procedure is \nsystem-dependent, but most common patterns are described below.\n\n\nSystems that do not require the old password/secret for rotation\nSuch systems usually have a \"Forgot password\" facility or a\n similar facility allowing users to rotate their password/secrets by \nsending a unique \"magic\" link to the user\u0027s email or phone. In such \ncases users are advised to use this facility and input the newly \ngenerated password secret, when prompted by the system.\n\n\nSystems that require the old password/secret for rotation\nSuch systems usually have a modal password rotation window\n usually in the user settings section requiring the user to input the \nold and the new password sometimes with a confirmation. To \ngenerate/recover the old password in such cases users are advised to:\n\n\n\n  *  temporarily download  gokey version 0.1.3 https://github.com/cloudflare/gokey/releases/tag/v0.1.3  for their respective operating system to recover the old password\n\n  *  use gokey version 0.2.0 or above to generate the new password\n\n  *  populate the system provided password rotation form\n\n\n\n\nSystems that allow multiple credentials for the same account to be provisioned\nSuch systems usually require a secret or a cryptographic \nkey as a credential for access, but allow several credentials at the \nsame time. One example is SSH: a particular user may have several \nauthorized public keys configured on the SSH server for access. For such\n systems users are advised to:\n\n\n\n  *  generate a new secret/key/credential using gokey version 0.2.0 or above\n\n  *  provision the new secret/key/credential in addition to the existing credential on the system\n\n  *  verify that the access or required system operation is still possible with the new secret/key/credential\n\n  *  revoke authorization for the existing/old credential from the system\n\n\n\n\nCredit\nThis vulnerability was found by Th\u00e9o Cusnir ( @mister_mime https://hackerone.com/mister_mime ) and responsibly disclosed through Cloudflare\u0027s bug bounty program."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "LOCAL",
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "HIGH",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-330",
              "description": "CWE-330 Use of Insufficiently Random Values",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-12-02T11:03:21.832Z",
        "orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
        "shortName": "cloudflare"
      },
      "references": [
        {
          "url": "https://github.com/cloudflare/gokey/security/advisories/GHSA-69jw-4jj8-fcxm"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "gokey allows secret recovery from a seed file without the master password",
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
    "assignerShortName": "cloudflare",
    "cveId": "CVE-2025-13353",
    "datePublished": "2025-12-02T11:03:21.832Z",
    "dateReserved": "2025-11-18T11:21:27.669Z",
    "dateUpdated": "2025-12-02T16:54:23.544Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Universal Ssl",
          "vendor": "Cloudflare",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "NotCVE Advisories"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "----------------------------------------------------------------------------\nNotCVE Disclosure Update \u2014 NotCVE-2026-0001 / CVE-2026-14440\n----------------------------------------------------------------------------\n\n[-] Summary:\n\nOn 2026-01-19 the issue described below was published as NotCVE-2026-0001\nafter no CVE identifier was assigned for it. On 2026-07-01 \u2014 163 days\nlater \u2014 Cloudflare assigned CVE-2026-14440 to the same issue, now rated\nCVSS 9.1. This message documents the disclosure timeline for the public\nrecord.\n\n[-] Affected:\n\nCloudflare Universal SSL (managed CAA record augmentation) \u2014 service-side\nbehaviour; no customer-side patch applicable.\n\n[-] Technical Description:\n\nCloudflare Universal SSL automatically adds CAA issue/issuewild records\nwhen a customer has Universal SSL enabled and publishes any CAA records\nfor the zone. These auto-added records are not shown in the Cloudflare\ndashboard but are returned in DNS responses, and can include permissive\nauthorizations such as:\n\n    CAA 0 issue \"letsencrypt.org\"\n    CAA 0 issuewild \"letsencrypt.org\"\n\nWhen a domain owner uses RFC 8657 CAA extensions (accounturi and/or\nvalidationmethods) to restrict certificate issuance to a specific\nauthorized ACME account or validation method, the presence of an\nauto-added CAA issue property WITHOUT those RFC 8657 constraints broadens\nauthorization: per RFC 8657, a CAA property without an accounturi\nparameter matches any account. This weakens the domain owner\u0027s intended\naccount binding and may enable unauthorized DV certificate issuance.\n\n[-] Disclosure Timeline:\n\n[19/01/2026] - Public record published as NotCVE-2026-0001; no CVE\n               identifier assigned at that time\n[01/07/2026] - Cloudflare assigns CVE-2026-14440 (CVSS 9.1) for the same\n               issue, 163 days after the public record\n\n[-] CVE Reference:\n\nCVE-2026-14440\n\n[-] References:\n\nhttps://notcve.org/notcve/NotCVE-2026-0001   (full technical record,\n                                              preserved since day one)\nhttps://notcve.org/cve/CVE-2026-14440\n\n[-] About NotCVE:\n\nNotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to\nvulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?\nRequest a NotCVE: https://notcve.org/form/ \u00b7 Contributors:\nhttps://notcve.org/hall/\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T07:55:56Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/22"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Jul/22"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://notcve.org"
        },
        {
          "url": "https://notcve.org/cve/CVE-2026-14440"
        },
        {
          "url": "https://notcve.org/form/"
        },
        {
          "url": "https://notcve.org/hall/"
        },
        {
          "url": "https://notcve.org/notcve/NotCVE-2026-0001"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Jul/22"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[NotCVE-2026-0001] Cloudflare Universal SSL CAA augmentation weakens RFC 8657 account binding \u2014 CVE-2026-14440 assigned 163 days after public no-CVE disclosure",
      "x_gcve": [
        {
          "recordType": "reference",
          "relationships": [
            {
              "destId": "CVE-2026-14440",
              "type": "related"
            }
          ],
          "vulnId": "GCVE-1988-2026-0339",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/22",
            "automated": true,
            "contentSha256": "74c32742b1845f9d69c269583c1496d4b7bcc719376171964a308397dc9fea62",
            "evidenceScore": 7,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/22",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-07-13T13:10:43Z"
          }
        },
        {
          "recordType": "advisory",
          "vulnId": "gcve-1988-2026-0339"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-11T07:55:56Z",
    "dateUpdated": "2026-09-11T07:55:56Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0339"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Cloudflare Universal SSL",
          "vendor": "Cloudflare",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "NotCVE Advisories"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "----------------------------------------------------------------------------\nNotCVE Disclosure Update \u2014 NotCVE-2026-0001 / CVE-2026-14440\n----------------------------------------------------------------------------\n\n[-] Summary:\n\nOn 2026-01-19 the issue described below was published as NotCVE-2026-0001\nafter no CVE identifier was assigned for it. On 2026-07-01 \u2014 163 days\nlater \u2014 Cloudflare assigned CVE-2026-14440 to the same issue, now rated\nCVSS 9.1. This message documents the disclosure timeline for the public\nrecord.\n\n[-] Affected:\n\nCloudflare Universal SSL (managed CAA record augmentation) \u2014 service-side\nbehaviour; no customer-side patch applicable.\n\n[-] Technical Description:\n\nCloudflare Universal SSL automatically adds CAA issue/issuewild records\nwhen a customer has Universal SSL enabled and publishes any CAA records\nfor the zone. These auto-added records are not shown in the Cloudflare\ndashboard but are returned in DNS responses, and can include permissive\nauthorizations such as:\n\n    CAA 0 issue \"letsencrypt.org\"\n    CAA 0 issuewild \"letsencrypt.org\"\n\nWhen a domain owner uses RFC 8657 CAA extensions (accounturi and/or\nvalidationmethods) to restrict certificate issuance to a specific\nauthorized ACME account or validation method, the presence of an\nauto-added CAA issue property WITHOUT those RFC 8657 constraints broadens\nauthorization: per RFC 8657, a CAA property without an accounturi\nparameter matches any account. This weakens the domain owner\u0027s intended\naccount binding and may enable unauthorized DV certificate issuance.\n\n[-] Disclosure Timeline:\n\n[19/01/2026] - Public record published as NotCVE-2026-0001; no CVE\n               identifier assigned at that time\n[01/07/2026] - Cloudflare assigns CVE-2026-14440 (CVSS 9.1) for the same\n               issue, 163 days after the public record\n\n[-] CVE Reference:\n\nCVE-2026-14440\n\n[-] References:\n\nhttps://notcve.org/notcve/NotCVE-2026-0001   (full technical record,\n                                              preserved since day one)\nhttps://notcve.org/cve/CVE-2026-14440\n\n[-] About NotCVE:\n\nNotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to\nvulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?\nRequest a NotCVE: https://notcve.org/form/ \u00b7 Contributors:\nhttps://notcve.org/hall/\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-09T10:11:51Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/22"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Jul/22"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://notcve.org"
        },
        {
          "url": "https://notcve.org/cve/CVE-2026-14440"
        },
        {
          "url": "https://notcve.org/form/"
        },
        {
          "url": "https://notcve.org/hall/"
        },
        {
          "url": "https://notcve.org/notcve/NotCVE-2026-0001"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Jul/22"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[NotCVE-2026-0001] Cloudflare Universal SSL CAA augmentation weakens RFC 8657 account binding \u2014 CVE-2026-14440 assigned 163 days after public no-CVE disclosure",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0029",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/22",
            "automated": true,
            "contentSha256": "74c32742b1845f9d69c269583c1496d4b7bcc719376171964a308397dc9fea62",
            "evidenceScore": 7,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/22",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-07-13T13:10:43Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-07T13:20:21Z",
    "dateUpdated": "2026-09-09T10:11:51Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0029"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}