Summary
EasyAdmin serves all backend requests through a single dashboard route and, for custom actions (Action::linkToRoute() / MenuItem::linkToRoute()), swaps the executed controller based on the routeName query parameter on the kernel.controller event.
That swap happens after Symfony's security firewall has already evaluated access_control against the original dashboard URL, and the routeName value was not validated. As a result, a path-based access_control rule protecting the target route was never evaluated, so a low-privilege backend user could reach a more restricted route by name.
Impact
Any application where access_control (or another path-based Symfony security rule) protects some routes more strictly than the dashboard URL used to reach EasyAdmin. An attacker who can reach a single EasyAdmin URL and knows a target route's name can execute that route's controller, bypassing the path-based rule.
Only path-based protections are bypassed. Routes whose controller enforces its own authorization with #[IsGranted] / denyAccessUnlessGranted() remain protected, because those checks are recomputed against the swapped-in controller.
Patches
Fixed in 4.29.16 and 5.5.1. Before dispatching a custom-action route, EasyAdmin now re-evaluates the target route's access_control rule and denies the request if the current user is not granted access.
Workarounds
Add controller-level authorization (#[IsGranted] / denyAccessUnlessGranted()) to any sensitive route, since controller-level checks are still enforced. Upgrading is the recommended fix.
Credits
Reported by @TungNGo02.
References
Summary
EasyAdmin serves all backend requests through a single dashboard route and, for custom actions (
Action::linkToRoute()/MenuItem::linkToRoute()), swaps the executed controller based on therouteNamequery parameter on thekernel.controllerevent.That swap happens after Symfony's security firewall has already evaluated
access_controlagainst the original dashboard URL, and therouteNamevalue was not validated. As a result, a path-basedaccess_controlrule protecting the target route was never evaluated, so a low-privilege backend user could reach a more restricted route by name.Impact
Any application where
access_control(or another path-based Symfony security rule) protects some routes more strictly than the dashboard URL used to reach EasyAdmin. An attacker who can reach a single EasyAdmin URL and knows a target route's name can execute that route's controller, bypassing the path-based rule.Only path-based protections are bypassed. Routes whose controller enforces its own authorization with
#[IsGranted]/denyAccessUnlessGranted()remain protected, because those checks are recomputed against the swapped-in controller.Patches
Fixed in 4.29.16 and 5.5.1. Before dispatching a custom-action route, EasyAdmin now re-evaluates the target route's
access_controlrule and denies the request if the current user is not granted access.Workarounds
Add controller-level authorization (
#[IsGranted]/denyAccessUnlessGranted()) to any sensitive route, since controller-level checks are still enforced. Upgrading is the recommended fix.Credits
Reported by @TungNGo02.
References