FILTER_SANITIZE_URL is the vulnerability trap you need to stop reaching for. This function strips malformed characters and dangerous sequences from URLs—it does not validate whether a URL points to a safe destination. A sanitized external phishing site is still a phishing site. The function's name creates exactly the false assumption that makes it dangerous: developers see "sanitize" and assume they've handled security, when they've only handled syntax.
Check your codebase for FILTER_SANITIZE_URL applied to redirect parameters, particularly in authentication flows. If you find it, you have an open redirect vulnerability regardless of what the function's output looks like. The fix is straightforward: implement relative URL allowlisting. Accept only paths that start with a forward slash and contain no protocol or hostname. Reject anything beginning with http://, https://, //, or containing domain names entirely.
This matters especially in project management tools like Leantime, where the blast radius extends beyond the application itself. Users likely have active sessions in Okta, Slack, Jira, or other institutional services in the same browser. An open redirect here becomes a targeted credential-harvesting vector informed by the victim's own project data—who they report to, which integrations they access. That's not generic phishing; it's high-fidelity credential theft.
Note that FILTER_SANITIZE_URL was deprecated in PHP 8.1 precisely because it produces this failure pattern. The function remains callable, meaning the trap persists in PHP 8.x deployments. Treat any use of this function on redirect parameters as a confirmed vulnerability, not a finding requiring further analysis.