CVE-2022-23632 - How a TLS Configuration Slip Exposed Traefik Users to Wrong TLS Settings

Traefik is a popular open-source HTTP reverse proxy and load balancer that's used by many to route traffic to microservices securely. Security is critical in this role, and Traefik offers robust support for TLS (Transport Layer Security) to encrypt HTTP connections. However, a vulnerability — CVE-2022-23632 — was discovered in how Traefik handled TLS configurations for different domains. In this post, we'll break down what happened, how it can be exploited, show you example configurations, and discuss ways to protect your setup.

What Was the Problem?

Before version 2.6.1, Traefik had a flaw where the TLS configuration attached to a router could be skipped if a request came in with a fully qualified domain name (FQDN) in the Host header.

- Normally, you'd configure a router to use custom TLS settings for a specific domain — say, a different certificate or protocol requirements.
- Traefik would sometimes assign the default TLS configuration *instead* of your dedicated one when the incoming request used an FQDN in the Host header.
- If you were using CNAME flattening (where Traefik resolves CNAME DNS records to their target domain), the problem got worse: Traefik could pick the SNI (Server Name Indication) based TLS config and route using the CNAME value, bypassing the set router's expected TLS config.

A failed expectation of security policies.

- Potential compromise of privacy between clients and your backend if the default TLS config was weaker or expired.

Let's look at how you might set up Traefik routers and certificates in a *good* configuration

# Sample static configuration for Traefik router
http:
  routers:
    mysecureapp:
      rule: Host(myapp.example.com)
      entryPoints:
        - websecure
      tls:
        certResolver: letsencrypt
        domains:
          - main: "myapp.example.com"
            sans:
              - "www.myapp.example.com"
      service: myapp-service

You set a specific TLS configuration for myapp.example.com as above.

2. A user requests your site using another FQDN that points to the same service, such as myapp.example.com.cdnproxy.com via a CNAME.
3. The router rule (Host('myapp.example.com')) does not match, but because the certificate resolver and configurations are not properly enforced in the router logic, Traefik might fall back to the default, global TLS settings.

If CNAME flattening is ON, the SNI (from the TLS handshake) still comes in as myapp.example.com, but routing is based on the CNAME value. The dedicated TLS config is skipped!

This could result in your service delivering a certificate for the wrong domain — which might be invalid or generic — and not the one you configured.

Exploitation: How Could Malicious Actors Leverage This?

- Impersonation & Phishing: Attackers might serve a more generic or otherwise misissued certificate on a domain, tricking users.
- Security Downgrade: If your default TLS config is less strict (older TLS version, weak cipher suites), sessions could be easier to intercept or decrypt.
- Failure of Mutual TLS: If you use client certificates as part of mutual TLS, the router’s specific client CA setting could get bypassed, letting unauthorized clients connect.

Register a CNAME like malicious.site.com pointing to myapp.example.com.

2. Craft an HTTPS request using SNI for myapp.example.com but route to malicious.site.com with CNAME flattening enabled on Traefik.
3. Observe Traefik serves the default TLS configuration/cert — not the one set up for myapp.example.com.

Suppose you have DNS set up as

malicious.site.com CNAME myapp.example.com

And a user requests

https://malicious.site.com

With the Host header set to malicious.site.com but SNI set to myapp.example.com, the router selection fails, and Traefik picks the global/default TLS, completely bypassing anything you customized for myapp.example.com.

The Simple Fix

Upgrade Traefik to v2.6.1 or later, where the logic now ensures requests for FQDNs properly match router TLS configurations before falling back.

GitHub Traefik Advisory & Patch

If you can't upgrade immediately and CNAME flattening is off, add all FQDNs used (including the CNAME targets) explicitly to your Host rules in your router config.

rule: "Host(myapp.example.com) || Host(malicious.site.com)"

Note: No workaround exists *if CNAME flattening is enabled*. You *must* upgrade.

References

- Official CVE entry (nvd.nist.gov)
- Traefik GitHub Security Advisory
- Fix PR on GitHub
- Understanding CNAME flattening (Cloudflare)

CNAME flattening made the issue unavoidable without patching.

- This could open the door to mis-issued certificates or unexpected weak TLS for your critical services.
- Upgrade to *at least* Traefik v2.6.1, and review your router rules and DNS records to avoid these problems now and in the future.

Timeline

Published on: 02/17/2022 15:15:00 UTC
Last modified on: 07/25/2022 18:21:00 UTC