Vulnerability-Lookup

CVE-2026-49457 (GCVE-0-2026-49457)

Vulnerability from cvelistv5 – Published: 2026-08-14 18:27 – Updated: 2026-08-14 19:30

Title

QUIC has Broken TLS verification

Summary

erlang_quic is a pure Erlang QUIC implementation. Prior to version 1.4.4, the QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. This is fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify => false` to accept any certificate (for example a self-signed test server). No known workarounds are available before 1.4.4. `verify => true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents.

Severity

9.1 (Critical)


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

SSVC

Exploitation: none Automatable: yes Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-08-14 19:29 UTC

CWE

CWE-295 - Improper Certificate Validation
CWE-297 - Improper Validation of Certificate with Host Mismatch

Assigner

GitHub_M

References

1 reference

URL	Tags
https://github.com/benoitc/erlang_quic/security/a…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version	CPE status
benoitc	erlang_quic	Affected: < 1.4.4	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-49457",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-14T19:29:49.865264Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-14T19:30:02.687Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "erlang_quic",
          "vendor": "benoitc",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.4.4"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "erlang_quic is a pure Erlang QUIC implementation. Prior to version 1.4.4, the QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. This is fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify =\u003e false` to accept any certificate (for example a self-signed test server). No known workarounds are available before 1.4.4. `verify =\u003e true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-295",
              "description": "CWE-295: Improper Certificate Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-297",
              "description": "CWE-297: Improper Validation of Certificate with Host Mismatch",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-14T18:27:20.523Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663"
        }
      ],
      "source": {
        "advisory": "GHSA-2r8v-p65x-3663",
        "discovery": "UNKNOWN"
      },
      "title": "QUIC has Broken TLS verification"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-49457",
    "datePublished": "2026-08-14T18:27:20.523Z",
    "dateReserved": "2026-05-30T02:43:33.107Z",
    "dateUpdated": "2026-08-14T19:30:02.687Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-49457",
      "date": "2026-08-16",
      "epss": "0.00149",
      "percentile": "0.04601"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-49457\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-08-14T19:17:18.707\",\"lastModified\":\"2026-08-14T20:16:53.283\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"erlang_quic is a pure Erlang QUIC implementation. Prior to version 1.4.4, the QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. This is fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify =\u003e false` to accept any certificate (for example a self-signed test server). No known workarounds are available before 1.4.4. `verify =\u003e true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents.\"}],\"affected\":[{\"source\":\"security-advisories@github.com\",\"affectedData\":[{\"vendor\":\"benoitc\",\"product\":\"erlang_quic\",\"versions\":[{\"version\":\"\u003c 1.4.4\",\"status\":\"affected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N\",\"baseScore\":9.1,\"baseSeverity\":\"CRITICAL\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":3.9,\"impactScore\":5.2}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2026-08-14T19:29:49.865264Z\",\"id\":\"CVE-2026-49457\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"yes\"},{\"technicalImpact\":\"total\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-295\"},{\"lang\":\"en\",\"value\":\"CWE-297\"}]}],\"references\":[{\"url\":\"https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663\",\"source\":\"security-advisories@github.com\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-49457\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-08-14T19:29:49.865264Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-08-14T19:29:57.501Z\"}}], \"cna\": {\"title\": \"QUIC has Broken TLS verification\", \"source\": {\"advisory\": \"GHSA-2r8v-p65x-3663\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 9.1, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"CRITICAL\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N\", \"integrityImpact\": \"HIGH\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"HIGH\"}}], \"affected\": [{\"vendor\": \"benoitc\", \"product\": \"erlang_quic\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 1.4.4\"}]}], \"references\": [{\"url\": \"https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663\", \"name\": \"https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663\", \"tags\": [\"x_refsource_CONFIRM\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"erlang_quic is a pure Erlang QUIC implementation. Prior to version 1.4.4, the QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. This is fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify =\u003e false` to accept any certificate (for example a self-signed test server). No known workarounds are available before 1.4.4. `verify =\u003e true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-295\", \"description\": \"CWE-295: Improper Certificate Validation\"}]}, {\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-297\", \"description\": \"CWE-297: Improper Validation of Certificate with Host Mismatch\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-08-14T18:27:20.523Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-49457\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-14T19:30:02.687Z\", \"dateReserved\": \"2026-05-30T02:43:33.107Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-08-14T18:27:20.523Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

FKIE_CVE-2026-49457

Vulnerability from fkie_nvd - Published: 2026-08-14 19:17 - Updated: 2026-08-14 20:16

Severity

9.1 (Critical) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "erlang_quic",
          "vendor": "benoitc",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.4.4"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "erlang_quic is a pure Erlang QUIC implementation. Prior to version 1.4.4, the QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. This is fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify =\u003e false` to accept any certificate (for example a self-signed test server). No known workarounds are available before 1.4.4. `verify =\u003e true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents."
    }
  ],
  "id": "CVE-2026-49457",
  "lastModified": "2026-08-14T20:16:53.283",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 9.1,
          "baseSeverity": "CRITICAL",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 5.2,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-49457",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-14T19:29:49.865264Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-14T19:17:18.707",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Received",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-295"
        },
        {
          "lang": "en",
          "value": "CWE-297"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

GHSA-2R8V-P65X-3663

Vulnerability from github – Published: 2026-07-01 20:32 – Updated: 2026-07-01 20:32

Summary

QUIC has Broken TLS verification

Details

Impact

The QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so verify was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent.

Patches

Fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (cacerts option, the operating system store by default), and checks the hostname. Client verify now defaults to on; set verify => false to accept any certificate (for example a self-signed test server).

Workarounds

None before 1.4.4. verify => true had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents.

Credit

Reported by benmmurphy.

Severity

9.1 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.3"
      },
      "package": {
        "ecosystem": "Hex",
        "name": "quic"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49457"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T20:32:34Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nThe QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent.\n\n### Patches\n\nFixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify =\u003e false` to accept any certificate (for example a self-signed test server).\n\n### Workarounds\n\nNone before 1.4.4. `verify =\u003e true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents.\n\n### Credit\n\nReported by benmmurphy.",
  "id": "GHSA-2r8v-p65x-3663",
  "modified": "2026-07-01T20:32:34Z",
  "published": "2026-07-01T20:32:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/benoitc/erlang_quic"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "QUIC has Broken TLS verification"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

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

Detection rules are retrieved from Rulezet.

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

Action not permitted

CVE-2026-49457 (GCVE-0-2026-49457)

FKIE_CVE-2026-49457

GHSA-2R8V-P65X-3663

Impact

Patches

Workarounds

Credit

Tags

Sightings

Nomenclature