reported the following via email on: 16 June 2026
There's an open redirect vulnerability in the Dub short-link redirect middleware. The issue allows any unauthenticated person to redirect visitors from any Dub short link (including those on dub.sh, d.to, and dub.link) to an arbitrary external URL.
Vulnerability summary:
Every Dub short link accepts a redir_url query parameter that overrides the link's configured destination. There is no domain allowlist or authentication requirement. Appending ?redir_url=https://any-site.com/ to any Dub short link causes the visitor to be redirected to that URL instead, using Dub's trusted domain in the redirect chain.
The vulnerable code is in apps/web/lib/middleware/utils/get-final-url.ts. When redir_url is present and parses as a valid URL via the URL constructor, it completely replaces the link's stored destination URL. The helper getUrlFromStringIfValid enforces no domain allowlist and no scheme restriction.
Live confirmation:
I confirmed the vulnerability against production Dub infrastructure (d.to) on 2026-06-16. The following command demonstrates the issue:
curl -s -o /dev/null -D - --max-redirs 0
"https://d.to/github?redir_url=https://attacker.example.com/phishing-page"
--user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
The response returns HTTP 302 with Location: https://attacker.example.com/phishing-page.
Additional impact:
-
The destination URL blacklist enforced during link creation (isBlacklistedDomain in process-link.ts) is completely bypassed because redir_url is evaluated at redirect time, not at link creation time.
-
When a link has "Link Cloaking" (rewrite mode) enabled, redir_url still substitutes the destination, so the visitor's browser address bar shows the Dub domain while content is served from the attacker's site.
-
The Location header accepts javascript: scheme URIs, which some non-browser clients may execute.
Suggested fix:
Remove the redir_url parameter entirely if it is not required as a public-facing feature, or restrict it to a workspace-configured allowlist of approved domains. If the feature is needed internally (e.g. for Stripe redirect), consider validating it against the link's workspace domains or a signed token to prevent external abuse.
reported the following via email on: 16 June 2026
There's an open redirect vulnerability in the Dub short-link redirect middleware. The issue allows any unauthenticated person to redirect visitors from any Dub short link (including those on dub.sh, d.to, and dub.link) to an arbitrary external URL.
Vulnerability summary:
Every Dub short link accepts a redir_url query parameter that overrides the link's configured destination. There is no domain allowlist or authentication requirement. Appending ?redir_url=https://any-site.com/ to any Dub short link causes the visitor to be redirected to that URL instead, using Dub's trusted domain in the redirect chain.
The vulnerable code is in apps/web/lib/middleware/utils/get-final-url.ts. When redir_url is present and parses as a valid URL via the URL constructor, it completely replaces the link's stored destination URL. The helper getUrlFromStringIfValid enforces no domain allowlist and no scheme restriction.
Live confirmation:
I confirmed the vulnerability against production Dub infrastructure (d.to) on 2026-06-16. The following command demonstrates the issue:
curl -s -o /dev/null -D - --max-redirs 0
"https://d.to/github?redir_url=https://attacker.example.com/phishing-page"
--user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
The response returns HTTP 302 with Location: https://attacker.example.com/phishing-page.
Additional impact:
The destination URL blacklist enforced during link creation (isBlacklistedDomain in process-link.ts) is completely bypassed because redir_url is evaluated at redirect time, not at link creation time.
When a link has "Link Cloaking" (rewrite mode) enabled, redir_url still substitutes the destination, so the visitor's browser address bar shows the Dub domain while content is served from the attacker's site.
The Location header accepts javascript: scheme URIs, which some non-browser clients may execute.
Suggested fix:
Remove the redir_url parameter entirely if it is not required as a public-facing feature, or restrict it to a workspace-configured allowlist of approved domains. If the feature is needed internally (e.g. for Stripe redirect), consider validating it against the link's workspace domains or a signed token to prevent external abuse.