The vulnerability in Grav's Login plugin (CVE-2026-53654) is an unauthenticated external redirect via a client-supplied _redirect parameter. That's the surface flaw. What's actually dangerous is the architectural pattern beneath it: Grav's Controller::execute() method silently applies a client-supplied _redirect field when the task doesn't explicitly set one. This means any task that doesn't actively opt out inherits redirect capability it may never have asked for. The twofa_cancel task—where this manifests—is a user-facing flow that reasonably expects CSRF protection, but the developer implementing it was thinking about session state, not upstream parameter inheritance. The cognitive load problem is baked into the framework: tasks must defend against parameters they may not know exist.
Three compounding factors make this severe: no authentication required (anyone can trigger it), no CSRF token needed, and the redirect executes from a trusted domain—the victim's own Grav instance. That's a multiplicative phishing surface that CVSS 5.3 doesn't capture. An attacker doesn't need a foothold, doesn't need to chain exploits, and can weaponize trusted-domain redirects against every email filter and browser warning system trained to flag suspicious domains.
The 3.8.5 patch fixes twofa_cancel. It does not fix the pattern. Controller::execute() still silently propagates client-supplied _redirect to every other task in the Login plugin—and beyond. Unless Grav audited every task that inherits this behavior, you have a codebase where developers know twofa_cancel was vulnerable but have no systematic way to identify the other tasks sharing its structural DNA. The fix is necessary but insufficient. What you should check: audit every task in your Grav installation that uses Controller::execute() and verify whether it intentionally handles redirects or silently inherits the behavior. Treat the absence of explicit redirect handling as a potential vulnerability until proven otherwise.