CVE-2026-45063 - Symfony X509Authenticator DN identity spoofing

Symfony’s X509Authenticator can be used for client-certificate authentication behind a web server or reverse proxy that validates mTLS and passes the certificate Subject DN to PHP in SSL_CLIENT_S_DN. Vulnerable versions extracted the configured user identifier with an unanchored match, so an identity marker such as emailAddress= could be found inside another relative distinguished name value instead of only at an RDN boundary.

The practical risk is account impersonation in Symfony apps that authenticate users or service clients from certificate Subject DN fields. A certificate from a trusted CA with a permissive free-text subject value can be interpreted as a different user if the application trusts the vulnerable extraction result.

When to use it

Use this recipe when a Symfony application uses X509Authenticator, mTLS, reverse-proxy certificate forwarding, or Subject DN fields for user or service identity. It is built for source-code remediation, certificate identity mapping review, reverse-proxy trust auditing, and evidence that attacker-controlled DN fragments cannot impersonate another account.

Inputs

  • Symfony security-http version, authenticator configuration, reverse proxy certificate headers, mTLS validation policy, and identity mapping rules.
  • Source/config paths that read SSL_CLIENT_S_DN, extract user identifiers, map certificate fields to users, or trust proxy-provided headers.
  • Regression fixtures for anchored RDN matches, embedded marker strings, multiple DN attributes, invalid client certs, and valid expected identities.
  • Boundary evidence: trusted proxy chain, certificate authority policy, affected user/service accounts, logs, and deployment artifact versions.

Affected versions

Package Vulnerable versions Fixed versions
symfony/security-http <5.4.52; >=6.0.0-BETA1, <6.4.40; >=7.0.0-BETA1, <7.4.12; >=8.0.0-BETA1, <8.0.12 5.4.52, 6.4.40, 7.4.12, 8.0.12 or later on the same train
symfony/symfony <5.4.52; >=6.0.0-BETA1, <6.4.40; >=7.0.0-BETA1, <7.4.12; >=8.0.0-BETA1, <8.0.12 5.4.52, 6.4.40, 7.4.12, 8.0.12 or later on the same train

Indicator-of-exposure

  • The repository resolves a vulnerable symfony/security-http or symfony/symfony version through Composer, a lockfile, a vendor snapshot, a container image, or generated SBOM/dependency report.
  • Symfony Security firewalls use the x509 authenticator or equivalent custom code that reads certificate identity from SSL_CLIENT_S_DN, SSL_CLIENT_S_DN_Email, SSL_CLIENT_CERT, X-SSL-Client-*, or upstream mTLS headers.
  • User lookup, service-account lookup, tenant routing, admin access, API token issuance, audit attribution, or approval workflows trust an email, CN, or other identifier parsed from the Subject DN.
  • The issuing CA, enterprise PKI, partner CA, or device enrollment flow permits free-text subject values instead of tightly controlled identity fields.
  • mTLS-authenticated routes are reachable by partners, devices, employees, agents, CI systems, support tools, or service meshes outside one trusted deployment boundary.

Quick checks:

rg -n "x509:|X509Authenticator|SSL_CLIENT_S_DN|SSL_CLIENT_S_DN_Email|SSL_CLIENT_CERT|X-SSL-Client|client.?cert|mTLS|mutual TLS|emailAddress|subject.?DN" .
composer show symfony/security-http symfony/symfony
composer why symfony/security-http
composer audit

Windows:

rg -n "x509:|X509Authenticator|SSL_CLIENT_S_DN|SSL_CLIENT_S_DN_Email|SSL_CLIENT_CERT|X-SSL-Client|client.?cert|mTLS|mutual TLS|emailAddress|subject.?DN" .
composer show symfony/security-http symfony/symfony
composer why symfony/security-http
composer audit

Do not test by issuing crafted client certificates against production, changing trusted CA policy in place, printing full certificate subjects for real users, or replaying mTLS sessions outside an approved test environment.

Remediation strategy

  • Upgrade every repository-controlled Symfony runtime, lockfile, vendor tree, image, generated dependency report, and SBOM to a fixed train: 5.4.52+, 6.4.40+, 7.4.12+, or 8.0.12+.
  • Inventory all mTLS and X.509 authentication paths. The default fix is the Symfony patch, but reviewers should still prove the application does not duplicate vulnerable DN parsing in custom authenticators, event listeners, middleware, proxy adapters, or service-mesh glue code.
  • Prefer stable identity attributes controlled by the CA or identity provider. If email is used, make sure the value is extracted by patched framework code or by a parser that anchors to RDN boundaries and rejects ambiguous subjects.
  • Tighten edge and PKI controls where this repository owns them: web server mTLS validation, trusted CA bundles, accepted client-certificate issuers, forwarded certificate headers, and proxy header stripping.
  • Add safe regression tests with local fixture strings or test certificates that prove ambiguous Subject DN values are rejected or mapped to the correct canonical identity without contacting live services.
  • If upgrade cannot deploy immediately, disable X.509 login for high-risk routes, restrict trusted client certificates to a tightly controlled CA, or require a second authentication factor until fixed Symfony packages are live.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-45063 / GHSA-ph86-p8f6-f9r2, a high-severity
Symfony X509Authenticator identity-spoofing issue where unanchored Subject DN
parsing can authenticate one client certificate as another user. Produce
exactly one output:

- A reviewer-ready PR/change request that upgrades Symfony security-http or
  symfony/symfony to the fixed release train, removes or fixes duplicate unsafe
  DN parsing, adds safe mTLS identity regression tests, refreshes generated
  artifacts, and documents operator actions, or
- TRIAGE.md if this repository does not control an affected Symfony X.509
  authentication runtime, Composer package, image, or deployment boundary.

## Rules

- Scope only CVE-2026-45063 / GHSA-ph86-p8f6-f9r2 and directly related Symfony
  X.509, mTLS, certificate Subject DN parsing, proxy header, and generated
  dependency artifacts.
- Treat client certificates, private keys, CA material, session cookies,
  bearer tokens, tenant identifiers, user emails, service-account identities,
  audit logs, and approval records as sensitive.
- Do not mint or replay crafted certificates against production, weaken mTLS,
  print real certificate subjects, expose private keys, or change CA trust
  policy without owner approval.
- Do not remove authentication, authorization, tenant isolation, audit logging,
  proxy header stripping, or certificate validation to silence the finding.
- Do not auto-merge.

## Steps

1. Inventory every Symfony runtime controlled by this repository: Composer
   manifests, lockfiles, vendor snapshots, Dockerfiles, base images, Helm or
   Kubernetes manifests, generated dependency reports, SBOMs, and deployment
   documentation.
2. Determine every resolved `symfony/security-http` and `symfony/symfony`
   version. A target is vulnerable if it resolves to `<5.4.52`,
   `>=6.0.0-BETA1, <6.4.40`, `>=7.0.0-BETA1, <7.4.12`, or
   `>=8.0.0-BETA1, <8.0.12`.
3. Search for X.509 and mTLS authentication paths: Symfony `x509` firewall
   config, `X509Authenticator`, `SSL_CLIENT_S_DN`, `SSL_CLIENT_S_DN_Email`,
   `SSL_CLIENT_CERT`, upstream `X-SSL-Client-*` headers, custom authenticators,
   event listeners, service-mesh adapters, and reverse-proxy config.
4. Map each trust decision that depends on certificate identity: user lookup,
   service-account lookup, tenant binding, admin access, API token issuance,
   approval authority, audit attribution, and partner or device access.
5. If this repository only calls an externally owned Symfony service, stop with
   `TRIAGE.md` naming checked files, the owner, the affected package ranges,
   and the required fixed train.
6. Upgrade all controlled Symfony runtimes to the appropriate fixed train:
   `5.4.52+`, `6.4.40+`, `7.4.12+`, or `8.0.12+`. Refresh `composer.lock`,
   vendor snapshots, generated dependency reports, SBOMs, image references,
   deployment manifests, and release notes.
7. Fix adjacent identity parsing:
   - remove custom regex extraction that searches for `emailAddress=`, `CN=`,
     or another RDN marker anywhere in the DN string;
   - anchor custom parsing to RDN boundaries or replace it with a maintained
     certificate/DN parser;
   - reject ambiguous subjects and duplicate identity attributes;
   - make proxy-provided certificate headers trusted only after the edge strips
     client-supplied equivalents;
   - avoid logging full Subject DN values for real users.
8. Review PKI and edge controls controlled by this repository:
   - trusted client CA bundles;
   - issuer restrictions;
   - web server mTLS validation;
   - forwarded certificate header stripping and allowlisting;
   - fallback authentication when X.509 identity is missing or ambiguous.
9. Add safe regression coverage:
   - dependency policy rejects vulnerable Symfony release trains;
   - X.509 login fixtures map only boundary-delimited identity fields;
   - ambiguous or duplicate Subject DN identity markers fail closed;
   - custom authenticators and proxy adapters do not trust raw client headers;
   - logs and snapshots redact certificate material and user identifiers.
10. Add a PR body section named `CVE-2026-45063 operator actions` that states:
    - Symfony packages and versions before and after;
    - which firewalls, authenticators, proxy configs, and mTLS routes were
      checked;
    - which identity field is authoritative after the fix;
    - whether the trusted CA or certificate enrollment policy permits free-text
      subject values;
    - whether suspicious certificate-authenticated logins need review;
    - whether any keys, certificates, sessions, or service-account credentials
      need rotation;
    - which validation commands passed.
11. If immediate upgrade is blocked, add temporary containment where this repo
    controls it: disable X.509 login on sensitive routes, require an additional
    auth factor, restrict client certificates to a tightly controlled CA, block
    proxy-supplied certificate headers from untrusted clients, and document the
    owner, follow-up date, and residual risk.
12. Run available validation: Composer install, lockfile integrity,
    `composer audit`, Symfony security tests, authentication integration tests,
    config rendering, container build, SBOM refresh, dependency/security scans,
    and deployment dry-run if available.
13. Use PR title:
    `fix(sec): remediate CVE-2026-45063 in Symfony X509 auth`.

## Stop conditions

- No affected Symfony package, X.509 authenticator, mTLS route, image,
  deployment artifact, or generated dependency report is controlled by this
  repository.
- The affected Symfony runtime is owned by another team or platform; document
  the owner and required fixed train in `TRIAGE.md`.
- The CA or mTLS edge policy is controlled outside this PR and blocks safe
  verification; document the owner, containment, and residual risk.
- Verification would require crafted certificates against production, live
  private keys, real user certificate subjects, tenant data, or privileged
  sessions.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades Symfony security-http, anchors certificate identity parsing, verifies reverse-proxy trust, adds spoofing regression tests, and documents credential/cert cleanup.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, mTLS identity boundary, affected accounts, required fix, and residual risk.
  • The output must include exact validation commands and must not expose client certificates, private keys, user PII, or production auth logs.

Verification - what the reviewer looks for

  • No controlled Composer manifest, lockfile, vendor tree, SBOM, generated dependency report, container image, or deployment artifact resolves a vulnerable symfony/security-http or symfony/symfony release train.
  • X.509 and mTLS authentication paths were inventoried, including custom authenticators and reverse-proxy certificate headers.
  • Identity extraction is performed by patched Symfony code or an explicitly boundary-aware parser that rejects ambiguous Subject DN values.
  • Regression tests cover ambiguous Subject DN identity markers without using live certificates, real users, private keys, or production services.
  • Operator notes cover CA/enrollment assumptions, suspicious-login review, and credential/session rotation when exposure existed.

Watch for

  • Upgrading composer.json while composer.lock, vendor snapshots, images, or SBOMs still resolve a vulnerable Symfony release train.
  • Custom authenticators, listeners, or proxy adapters that continue to parse SSL_CLIENT_S_DN with unanchored regexes after the framework upgrade.
  • Trusting X-SSL-Client-* or similar headers from clients because a reverse proxy is assumed but not enforced.
  • Treating all mTLS as low risk because certificates are issued by an internal CA, even when enrollment allows user-controlled subject text.
  • Logging full certificate subjects, user emails, service-account identities, or certificate serials in tests and CI output.

References