EasyAdmin, Authorization Bypass Through User-Controlled Key, CVE-2026-81892 (High) -DC-Sep2026-2095

Listen to this Post

EasyAdmin is a modern admin generator for Symfony applications. From version 4.0.0 up to (but not including) 4.29.16, and from 5.0.0 up to (but not including) 5.5.1, EasyAdmin processes all backend requests through a single dashboard route. For custom actions, such as `Action::linkToRoute()` and MenuItem::linkToRoute(), it swaps the executed controller based on the `routeName` query parameter during the `kernel.controller` event.
The critical flaw is in the order of operations: Symfony’s security firewall evaluates `access_control` rules against the original dashboard URL before the `kernel.controller` event listener performs the controller swap. The `routeName` parameter is not validated before this swap occurs. As a result, if an administrator has configured path-based `access_control` rules to protect specific routes more strictly than the generic dashboard URL, these rules are never evaluated for the request. An attacker who can reach any EasyAdmin URL and knows the name of a target route can craft a request with `?routeName=…` to execute that route’s controller, thereby bypassing the path-based security rule.
This vulnerability only bypasses path-based protections. Routes whose controllers enforce their own authorization using `

` or `denyAccessUnlessGranted()` remain secure because these checks are recomputed against the swapped-in controller. The issue is fixed in versions 4.29.16 and 5.5.1. The fix involves re-evaluating the target route's `access_control` rule before dispatching the custom-action route and denying the request if the user is not granted access.

<h2 style="color: blue;">DailyCVE Form:</h2>

Platform: EasyAdminBundle
Version: 4.0.0-4.29.15, 5.0.0-5.5.0
Vulnerability: Authorization Bypass
Severity: High (CVSS 8.1)
date: 2026-08-31

<h2 style="color: blue;">Prediction: 2026-09-15</h2>

<h2 style="color: blue;">What Undercode Say:</h2>

Analytics show exploitation activity has been observed. The EPSS score is 0.25%, indicating a very low probability of exploitation in the next 30 days. No public exploit is currently available. The attack requires authenticated access to the EasyAdmin dashboard and knowledge of a target route name.
To verify if your application is affected, check the `security.yaml` file for path-based `access_control` rules that protect routes more strictly than the EasyAdmin dashboard URL. You can test by sending a request to the dashboard with a `?routeName=` parameter pointing to a protected route and observing if access is granted to a low-privilege user.

<h2 style="color: blue;">Exploit: (Educational Purposes!)</h2>

An attacker with low-privilege backend access can exploit this by sending a GET or POST request to the EasyAdmin dashboard URL with the `routeName` parameter set to the internal name of a protected route. For example:
[bash]
curl -X GET "https://target.example.com/admin/dashboard?routeName=app_admin_sensitive_action" \
-H "Cookie: PHPSESSID=low_privilege_session"

If the target route `app_admin_sensitive_action` is protected only by a path-based `access_control` rule in security.yaml, the firewall will evaluate the rule against the dashboard URL (/admin/dashboard) instead of the target route’s actual path, allowing the request to proceed and execute the protected controller.

Protection:

  1. Upgrade: Update the `easycorp/easyadmin-bundle` to version 4.29.16 or 5.5.1 or higher using Composer:
    composer update easycorp/easyadmin-bundle
    
  2. Controller-Level Authorization: Add `
    ` attributes or `denyAccessUnlessGranted()` checks to all sensitive controllers. These checks are enforced even if the route is reached through EasyAdmin's `?routeName=` dispatch:
    [bash]
    use Symfony\Component\Security\Http\Attribute\IsGranted;
    [IsGranted('ROLE_ADMIN')]
    public function sensitiveAction(): Response
    {
    // ...
    }
    
  3. Event Listener (Workaround): If you cannot upgrade immediately, register a custom event listener for `kernel.controller` to validate the `routeName` parameter against a whitelist of allowed routes before the controller swap occurs:
    // In services.yaml, register an event listener for kernel.controller
    // Example listener code:
    public function onKernelController(ControllerEvent $event): void
    {
    $request = $event->getRequest();
    if ($request->attributes->has('routeName')) {
    $allowedRoutes = ['allowed_route1', 'allowed_route2'];
    if (!in_array($request->attributes->get('routeName'), $allowedRoutes)) {
    throw new AccessDeniedException('Invalid route');
    }
    }
    }
    

Impact:

A low-privileged backend user could access sensitive administrative functionality or data by invoking controllers that should be restricted. This could lead to unauthorized information disclosure, data manipulation, or privilege escalation if the invoked controllers have side effects. The impact is limited to applications that rely on path-based `access_control` rules in security.yaml. Applications that use controller-level authorization ([bash] or denyAccessUnlessGranted()) are not affected by this bypass.

🎯Let’s Practice Exploiting & Learn Patching For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top