EasyAdmin custom-action dispatcher bypasses access_control on other routes

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.