mirror of
https://github.com/makeplane/plane.git
synced 2026-09-02 12:09:14 +02:00
8537b6edfd
Server: validate_next_path (apps/api/plane/utils/path_validator.py) calls urlparse(next_path) and only extracts .path when scheme or netloc is truthy. For "///example.com/" (three or more leading slashes), urlparse() returns both scheme and netloc empty, so that branch never fires and the raw string passes every remaining check unchanged. Fixed by rejecting any next_path starting with "//" outright, right after the existing "must start with /" check. Client: isValidURL (apps/web/core/lib/wrappers/authentication-wrapper.tsx) only regex-blocked a literal http(s)/ftp scheme prefix, so the same authority-relative string passed and was handed to router.push(). Fixed by resolving the URL against location.origin and requiring the result to actually still be same-origin, instead of pattern-matching the input. Browsers resolve a leading "//" as authority-relative even when neither validator's own URL parsing detected a host — the accepted value silently navigates off-domain post-login, a same-origin-trust phishing vector. Checked the advisory's other listed next_path consumers (auth-form components, oauth hooks, api.service.ts) — they only forward the value to a server-side auth redirect or a hidden form field, no independent client-side navigation, so they're covered by the server-side fix. 8 new server-side tests, fail-before verified. Client-side fix verified empirically via Node's URL parser (WHATWG-compliant, matches browser behavior) — no test harness exists for apps/web in this repo. Co-authored-by: Plane AI <noreply@plane.so>