Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-48489

CVE-2026-48489: Symfony Auth Bypass Vulnerability

CVE-2026-48489 is an authentication bypass flaw in Sensiolabs Symfony that allows unauthenticated users to access protected routes via failing login requests. This article covers technical details, affected versions, and patches.

Published:

CVE-2026-48489 Overview

CVE-2026-48489 is an authorization bypass vulnerability in the Symfony PHP framework. The flaw resides in the DefaultAuthenticationFailureHandler component of the Security HTTP subsystem. When failure_forward: true is enabled, the handler honored the user-controlled _failure_path request parameter. An unauthenticated attacker could submit a failing login request that dispatched a subrequest to any access_control-protected GET route while skipping firewall listeners. This allowed access to routes that should have required authentication [CWE-863: Incorrect Authorization]. The vulnerability affects Symfony versions prior to 5.4.53, 6.4.41, 7.4.13, and 8.0.13.

Critical Impact

Unauthenticated attackers can reach protected GET endpoints by abusing the login failure forward flow, bypassing firewall authentication checks entirely.

Affected Products

  • Symfony 5.x prior to 5.4.53
  • Symfony 6.x prior to 6.4.41
  • Symfony 7.x prior to 7.4.13
  • Symfony 8.x prior to 8.0.13

Discovery Timeline

  • 2026-07-14 - CVE-2026-48489 published to NVD
  • 2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-48489

Vulnerability Analysis

Symfony's DefaultAuthenticationFailureHandler processes failed authentication attempts and can either redirect the user or forward the request internally to a configured failure path. When failure_forward is enabled, the handler dispatched a subrequest through the HTTP kernel using the failure path. The handler previously read the _failure_path parameter directly from the request before this branch. An attacker could supply an arbitrary internal path in _failure_path alongside invalid login credentials. The framework then forwarded the request to that path as an internal subrequest, which bypassed the firewall listeners that normally enforce authentication on access_control-protected routes.

Root Cause

The root cause is trusting user-supplied input to select the forward destination without validating it against the intended failure workflow. The _failure_path request parameter was extracted and used to overwrite $options['failure_path'] regardless of whether the flow would result in a redirect or an internal forward. Internal forwards executed by the HTTP kernel do not re-invoke the firewall, so authorization checks tied to firewall listeners were skipped for the forwarded route.

Attack Vector

An unauthenticated remote attacker submits a POST request to the login form endpoint with invalid credentials and a crafted _failure_path parameter pointing to a protected GET route. The failure handler forwards the request internally to that route, returning content the attacker should not be able to view.

php
    public function onAuthenticationFailure(Request $request, AuthenticationException $exception)
    {
        $options = $this->options;
-       $failureUrl = ParameterBagUtils::getRequestParameterValue($request, $options['failure_path_parameter']);
-
-       if (\is_string($failureUrl) && (str_starts_with($failureUrl, '/') || str_starts_with($failureUrl, 'http'))) {
-           $options['failure_path'] = $failureUrl;
-       } elseif ($this->logger && $failureUrl) {
-           $this->logger->debug(sprintf('Ignoring query parameter "%s": not a valid URL.', $options['failure_path_parameter']));
-       }
-
-       $options['failure_path'] ?? $options['failure_path'] = $options['login_path'];

        if ($options['failure_forward']) {
+           $options['failure_path'] ?? $options['failure_path'] = $options['login_path'];
+
            if (null !== $this->logger) {
                $this->logger->debug('Authentication failure, forward triggered.', ['failure_path' => $options['failure_path']]);
            }

Source: Symfony security commit c48a427. The patch moves the _failure_path handling so it no longer applies in the failure_forward branch, preventing attacker-controlled internal forwards.

Detection Methods for CVE-2026-48489

Indicators of Compromise

  • POST requests to login endpoints containing a _failure_path parameter with values pointing to internal application routes rather than login-related paths.
  • Application logs showing Authentication failure, forward triggered. entries with failure_path values that reference sensitive or access_control-protected routes.
  • Successful HTTP 200 responses to failed login attempts where the response body content matches protected resources rather than a login form.

Detection Strategies

  • Inspect web server and application logs for login form submissions that include the _failure_path parameter with unexpected values.
  • Correlate authentication failure events with rendering of content that should require an authenticated session.
  • Review Symfony security bundle configuration to identify firewalls where failure_forward: true is set, and audit historical requests targeting those login endpoints.

Monitoring Recommendations

  • Enable verbose logging on the Symfony security component to capture failure handler dispatch details.
  • Alert on anomalous _failure_path parameter values, particularly those referencing API routes, admin controllers, or user profile paths.
  • Track the Composer package version of symfony/security-http across deployed applications to identify unpatched instances.

How to Mitigate CVE-2026-48489

Immediate Actions Required

  • Upgrade Symfony to 5.4.53, 6.4.41, 7.4.13, or 8.0.13 depending on the release branch in use.
  • Audit all firewall configurations for failure_forward: true and review whether the forward behavior is still required.
  • Review access logs for prior exploitation attempts using the _failure_path parameter against login endpoints.

Patch Information

The fix is delivered in Symfony releases v5.4.53, v6.4.41, and v7.4.13. Full details are in the GHSA-6h46-9jf5-q59x advisory. The patch relocates the _failure_path handling out of the failure_forward code path, ensuring attacker-supplied paths cannot influence internal subrequest dispatch.

Workarounds

  • Disable failure_forward in the firewall configuration and rely on redirect-based failure handling until the patched version can be deployed.
  • Filter incoming requests at the web server or reverse proxy layer to strip the _failure_path parameter from POST bodies targeting login endpoints.
  • Implement a custom authentication failure handler that ignores request-supplied failure paths and uses a hard-coded value.
bash
# Update Symfony security-http component with Composer
composer require symfony/security-http:^7.4.13

# Or update the full framework
composer update symfony/*

# Verify installed version
composer show symfony/security-http | grep versions

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.