CVE-2021-32693

Executive Summary

CVE-2021-32693 is an authentication isolation flaw in the Symfony PHP framework, affecting versions 5.3.0 through 5.3.1. In applications defining multiple firewalls, an authentication token generated by one firewall is incorrectly honored by all other firewalls, allowing a user authenticated against one part of an application (e.g., an admin panel) to be implicitly considered authenticated in unrelated sections protected by different providers. Successful exploitation can lead to horizontal or vertical privilege escalation, broken access control, and unauthorized data access, with a CVSS base score of 6.8 (medium severity). The flaw was addressed in Symfony 5.3.2, and no in-the-wild exploitation or public proof-of-concept has been reported.

Technical Analysis

Symfony's security component uses a firewall-based architecture to manage authentication and authorization. Each firewall defines its own authentication mechanism (e.g., form login, API token, HTTP basic) and can reference a distinct user provider. When an application defines multiple firewalls — a common pattern for splitting admin, API, and frontend sections — Symfony maintains the authenticated token in the security token storage during the lifecycle of the request.

The vulnerability stems from Symfony's token storage being realm-agnostic. In affected versions, the token storage layer does not track which firewall generated the authenticated token. Consequently, when a request traverses the firewall chain, each firewall checks the token storage and finds an authenticated token — regardless of which firewall originally authenticated it. The AuthenticationListener for each firewall validates whether a token exists, but in versions 5.3.0 and 5.3.1, it does not verify that the token was produced by that same firewall.

The practical consequence is that if an application defines different user providers per firewall — e.g., an admin firewall backed by an "admin_users" table and an API firewall backed by a "customers" table — a user authenticating through the admin firewall (gaining an admin-scoped token) is subsequently treated as an authenticated principal in the API firewall's context. The application code in the API section would then see an authenticated user where none should exist, bypassing provider-specific isolation.

The patch introduced in Symfony 5.3.2 resolves this by binding the authenticated token to the firewall that generated it. Each firewall instance now verifies token provenance before considering the request authenticated, ensuring a token minted by firewall A is not consumable by firewall B. This aligns with Symfony's security best-practice of treating each firewall as an isolated security context.

Attack surface: Any Symfony 5.3.0–5.3.1 application that defines more than one firewall and relies on different user providers for those firewalls. The exploitation vector is server-side and does not require a crafted payload — merely authenticating against one firewall creates the prerequisite state.

Exploitation Scenarios

No public PoC or exploit code is available for CVE-2021-32693. The following attack chain is inferred from the vulnerability class (broken authentication/authorization isolation) and the NVD description, not from observed exploits.

Step 1: Reconnaissance / Target Identification — The attacker identifies a Symfony-based application and fingerprints its version. Indicators include Symfony-specific HTTP headers, debug toolbar artifacts (in dev environments), generator meta tags in HTML, or predictable path patterns (e.g., /_profiler, /console, /login). Version detection to confirm 5.3.0–5.3.1 narrows the viable target set.

Step 2: Triggering the Authentication Isolation Flaw — The attacker requires valid credentials for at least one firewall's provider. With those credentials, they authenticate normally against an exposed authentication endpoint (e.g., a login form, HTTP basic auth, or token-based endpoint). The exploit is not a single injection or crafted payload; it is a logic flaw that manifests immediately upon successful authentication. No additional request manipulation is necessary — the flaw is inherent to the framework's token handling.

Step 3: Payload / Execution at the Vulnerability-Class Level — After authentication, the flawed token remains in the security token storage for the remainder of the request. The attacker then navigates to a resource protected by a different firewall, where no valid authentication should exist. Because the token storage persists across the firewall chain and the second firewall does not validate token provenance, the resource is served as if the attacker were an authenticated user of that second firewall's realm.

The attacker must discover which application sections are protected by a distinct firewall and what operations those sections expose. In common multi-firewall layouts, this includes admin backends, management APIs, or privileged reporting interfaces. The level of access granted depends on the roles/authorities encoded in the stolen token and the permission model of the second firewall.

Step 4: Post-Exploitation Impact — With cross-firewall authentication, the attacker can perform any operation that the second firewall's policy grants to an authenticated user. This may include unauthorized data reads, writes, configuration changes, or — if the second firewall guards administrative functionality — full administrative control over the application. The impact is bounded by the privilege set of the credentials the attacker initially used, meaning a low-privileged user in one realm could become a high-privileged user in another realm if the token's roles are honored globally.

Impact Assessment

CVSS Score: 6.8 (Medium Severity). The vector AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N indicates: network-exploitable, high attack complexity (requires multi-firewall application design and valid low-privilege credentials), low privilege required, no user interaction, and a security boundary crossing that yields high confidentiality and integrity impact, with no direct availability impact. EPSS probability of exploitation is 0.01388 (69.8th percentile), suggesting the vulnerability is a plausible but not actively targeted exploitation candidate.

Business Impact — The core business risk is the breakdown of the application's trust boundaries. Enterprises commonly segment Symfony deployments by firewall to enforce least-privilege and separation of duties: e.g., customers access the storefront, employees access the CRM, administrators access the console. This vulnerability silently erases those boundaries. A customer-account takeover of one realm can cascade into administrative access over another realm, directly threatening data integrity, regulatory compliance (e.g., GDPR, PCI-DSS), and audit trail validity.

Affected Systems — Any Symfony PHP application deployed on version 5.3.0 or 5.3.1 that defines multiple firewalls. Applications with a single firewall are unaffected. The severity scales with the sensitivity of the resources guarded by the secondary firewalls.

Blast Radius — Full application database exposure, administrative control, potential server-side file modification (if admin interfaces expose file management), and lateral movement into adjacent middleware or underlying infrastructure. The availability impact is limited, but confidentiality and integrity losses can be total when the strongest firewall in the application is compromised via a sibling's token.

Detection Guidance

The log-centric detection rules below focus on indicators of unusual multi-realm authentication activity, since the vulnerability manifests as legitimate authentication that exceeds its intended scope. Network-layer detection is limited because exploitation uses standard HTTP requests.

Sigma Rule

title: Symfony Multi-Firewall Cross-Authentication - Suspicious Session Token Usage
id: 9fcb3468-1f4e-4f75-9e2c-bf45c7d77e04
status: experimental
description: Detects authentication events occurring across multiple Symfony firewalls in a short window, indicating potential CVE-2021-32693 exploitation
author: Valtersit Threat Intelligence
logsource:
  category: application
  product: symfony
  service: security
detection:
  selection_login:
    event.action: 'authenticated'
    event.outcome: 'success'
  selection_admin:
    event.context:
      path|contains: '/admin/'
  selection_api:
    event.context:
      path|contains: '/api/'
  condition: selection_admin and selection_api in (1 minute window) and same source.ip
timeframe: 1m
level: high
falsepositives:
  - Legitimate admin users also consuming API endpoints on the same host
  - Authentication proxies that replay user sessions across firewalls
tags:
  - attack.initial_access
  - attack.t1190
  - cve.2021.32693

YARA Rule

rule CVE_2021_32693_Symfony_Firewall_Auth_Bypass
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects Symfony 5.3.0-5.3.1 source artifacts containing cross-firewall token storage logic vulnerable to CVE-2021-32693"
        date = "2025-05-01"
        reference = "CVE-2021-32693"
        severity = "medium"

    strings:
        $token_class = /class\s+TokenStorage/
        $set_token = /function\s+setToken\s*\(/ nocase
        $get_token = /function\s+getToken\s*\(/ nocase
        $firewall_check = /firewall.*authenticated|authenticated.*firewall/ nocase
        $token_check = /TokenInterface|getUser\(\s*\)/ nocase

    condition:
        uint16(0) == 0x5A4D  // "MZ" for PE-packed PHP or file header check
        and 2 of ($token_class, $set_token, $get_token)
        and $firewall_check
        and $token_check
}

Note: This rule targets source-code artifacts obtained during penetration testing or incident response. Runtime detection is limited to log analysis rather than binary scanning.

Suricata IDS Rule

alert http any any -> $HOME_NET any (
    msg:"CVE-2021-32693 - Symfony Multi-Firewall Authentication Boundary Bypass (Recon or Trail)";
    flow:established,to_server;
    content:"/admin/"; http_uri; nocase;
    threshold: type both, track by_src, count 5, seconds 60;
    sid:4929307; rev:1;
    reference:cve,2021-32693;
    metadata: attack_target Web_Server; tag cve_2021_32693; created_at 2025-05-01;
)

Note: Network-based detection is inherently weak for this vulnerability since it exploits application-level authentication state. The rule above flags rapid-fire admin and API endpoint access from a single source, which may indicate attempted cross-firewall probing.

Elastic Detection

// Detect session token reuse across firewall realms (Elastic EQL)
sequence by source.ip with maxspan=1m
  [ authentication where event.outcome == "success" and url.path like "*admin*" ]
  [ authentication where event.outcome == "success" and url.path like "*api*" ]

Splunk SPL Query

index=web sourcetype=access_combined
| where like(uri, "%/admin/%") OR like(uri, "%/api/%")
| where status=200
| transaction clientip maxspan=1m
| where mvcount(uri) > 1
| where like(mvindex(uri, 0), "%admin%") AND like(mvindex(uri, 1), "%api%")
| table _time, clientip, uri, status, user_agent
| sort - _time

Wazuh OSSEC Rule

<group name="symfony,">
  <rule id="100207" level="10">
    <decoded_as>json</decoded_as>
    <field name="event.action">authenticated</field>
    <field name="event.outcome">success</field>
    <field name="url.path" type="pcre2">/admin/</field>
    <description>Symfony admin authentication success - correlate with subsequent cross-firewall access</description>
    <group>authentication_success,</group>
  </rule>
  <rule id="100208" level="12">
    <if_sid>100207</if_sid>
    <field name="url.path" type="pcre2">/api/</field>
    <description>Potential CVE-2021-32693 cross-firewall authentication: authenticated user previously in admin realm is now accessing API realm. Investigate token isolation.</description>
    <group>cve_2021_32693,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 3/4 (LIKELY) — the fix is confirmed by two independent sources (CNA and Debian), and the vendor patch (Symfony 5.3.2) explicitly scopes authenticated tokens to the originating firewall.

Immediate Mitigations (before patching):

1. Audit multi-firewall configurations. Identify all Symfony 5.3.0–5.3.1 applications defining more than one firewall with different providers. If possible, temporarily consolidate firewalls to a single authentication realm until patching is complete.
2. Restrict authentication endpoints. Block external access to high-privilege firewalls (e.g., admin panels) by IP allow-listing or VPN gating, reducing the pool of attackers who could authenticate.
3. Enable comprehensive authentication logging. Ensure all firewall authentication events are logged with user, source IP, path, and session identifiers to enable forensic reconstruction if exploitation is suspected.
4. Review user provisioning. Temporarily reduce privileges on secondary-firewall accounts to limit blast radius if cross-authentication occurs.

Patch / Upgrade Steps:

1. Upgrade Symfony to version 5.3.2 or later (or any later stable 5.4/6.x release). The security fix is included in 5.3.2:

   composer update symfony/symfony --with-dependencies
   

2. Alternatively, apply the specific security fix via the symfony/security-http package update if a partial upgrade is preferred.
3. Verify the upgrade: confirm that symfony/symfony resolves to 5.3.2 or higher in composer.lock, and run Symfony's built-in security checks (bin/console security:check).
4. Regression-test all firewalls in the application to confirm that authentication still works independently and that tokens no longer cross realms.

Long-Term Hardening:

1. Treat each firewall as a fully isolated security context. Verify that authentication tokens are scoped per-firewall for all future Symfony upgrades.
2. Implement application-layer authorization (e.g., role-based access control via is_granted()) in addition to firewall authentication, so that even a valid token cannot access resources without the correct role.
3. Adopt a security monitoring pipeline that correlates authentication events across all application realms.
4. Subscribe to Symfony security advisories and incorporate Composer audit into CI/CD (composer audit).

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2021-32693 — Official NVD record with CVSS scoring and CNA description.
2. Symfony Security Advisory: https://symfony.com/cve-2021-32693 — Vendor advisory detailing the multi-firewall authentication flaw and the 5.3.2 patch. (Note: verify URL availability; advisory mirrors GitHub advisory.)
3. Symfony GitHub Advisory: https://github.com/advisories/GHSA-4q6r-2r3f-6h43 (returned 404 — verify manually) — GitHub Security Advisory for CVE-2021-32693 with affiliated commit references.
4. Debian Security Tracker: https://security-tracker.debian.org/tracker/CVE-2021-32693 — Independent confirmation of the fix via Debian's packaging of the patched Symfony versions.
5. CISA KEV: Not listed — This CVE is not on the CISA Known Exploited Vulnerabilities catalog, consistent with no confirmed in-the-wild exploitation as of the report date. No threat actor campaigns have been publicly attributed to this CVE.