GHSA-g2fm-8hr4-j82h EasyAdmin custom-action dispatcher bypasses access_control on other routes

• Packagist easycorp/easyadmin-bundle: >= 4.0.0, < 4.29.16 → fixed in 4.29.16 • Packagist easycorp/easyadmin-bundle: >= 5.0.0, < 5.5.1 → fixed in 5.5.1

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.