Open Redirect Vulnerability in Unbounce Landing Page Links

Unbounce landing page example

Marketing landing pages are designed with a singular purpose: convert visitors into customers. These pages strip away the navigation, search functionality, and other elements found on a company’s main website to minimize distractions. Services like Unbounce provide drag-and-drop builders that make creating these focused pages accessible to marketing teams without developer involvement.

While examining the link structure on an Unbounce-powered landing page, I discovered an open redirect vulnerability that affects all customers using their platform. This vulnerability allows attackers to craft malicious URLs that appear to originate from trusted domains but redirect victims to attacker-controlled websites.

Understanding Unbounce Landing Pages

Unbounce is a popular landing page platform that allows businesses to create and host marketing pages on their own subdomains. Customers configure a subdomain (such as discover.techsmith.com) to point to Unbounce’s servers using DNS CNAME records. Unbounce provides documentation for this setup process.

The result is a landing page that appears to be hosted on the company’s own domain, building trust with visitors who see a familiar URL in their browser’s address bar.

The Link Tracking Mechanism

Unbounce wraps outbound links on landing pages to track click analytics. Instead of linking directly to a destination, links use a special URL structure:

https://discover.techsmith.com/clkn/https/www.techsmith.com/products.html

The /clkn/ path signals Unbounce’s click tracking system. Everything after /clkn/ specifies the protocol and destination URL. When a visitor clicks this link, Unbounce logs the click for analytics purposes before redirecting to the intended destination.

Unbounce documents this behavior in their help article about link wrapping .

Notably, these wrapped links function independently—they do not require a specific referrer header or session state to work. Clicking the URL directly performs the redirect.

Investigating the Validation Logic

My first test was to modify the destination path:

https://discover.techsmith.com/clkn/https/www.techsmith.com/nonexistent-page.html

This worked, redirecting to the specified (non-existent) page on techsmith.com. This confirmed that the system does not validate against an allowlist of known pages.

Next, I attempted to redirect to a completely different domain:

https://discover.techsmith.com/clkn/https/www.example.com/

This returned an error:

We’re sorry, but the link you followed appears to be invalid.

Through systematic testing, I determined that the validation logic uses pattern matching on the domain portion of the URL. Specifically, it appears to verify that the domain ends with the customer’s configured domain (e.g., .techsmith.com).

The dot prefix in the pattern is significant. Without it, an attacker could register a domain like 1techsmith.com (which was available for under $10/year at the time of testing) and bypass the validation entirely.

Failed Exploitation Attempts

Protocol Downgrade

Changing the protocol from https to http successfully redirected:

https://discover.techsmith.com/clkn/http/www.techsmith.com/products.html

However, this attack vector is impractical because virtually all modern websites redirect HTTP requests to HTTPS automatically via HSTS.

Alternative URL Schemes

I attempted to use the tel: scheme to initiate phone calls:

https://discover.techsmith.com/clkn/tel/4161111111.techsmith.com/

This was blocked by the validation system.

I then tried the FaceTime URL scheme:

https://discover.techsmith.com/clkn/facetime/4161111111.techsmith.com/

This launched FaceTime with the “number” 4161111111.techsmith.com, but the application could not process this malformed input. While this demonstrates that some scheme handling occurs, I could not find a practical exploit path through alternative URL schemes.

Successful Exploitation

After considering which characters could manipulate the URL parsing, I focused on the query string delimiter: the question mark (?).

When a URL contains a question mark, everything after it becomes the query string. Web servers typically ignore unknown query parameters. This meant I could construct a URL where the required domain pattern appears as a query parameter rather than the actual destination:

https://discover.techsmith.com/clkn/https/attacker-controlled-site.com?.techsmith.com/

Testing this with a Pipedream request bin:

https://discover.techsmith.com/clkn/https/eohy2cdup330xo5.m.pipedream.net?.techsmith.com/

The server validated the URL (it ends with .techsmith.com), then issued a redirect to:

https://eohy2cdup330xo5.m.pipedream.net?.techsmith.com

The victim’s browser navigates to eohy2cdup330xo5.m.pipedream.net, treating .techsmith.com as a query parameter.

From within Pipedream, I configured an HTTP 302 redirect to any destination of my choosing, completing the open redirect chain.

Attack Scenarios

Credential Phishing

An attacker could register a typosquatted domain (e.g., techsmlth.com was available for under $10/year) and host a replica of the target company’s login page. The phishing URL would originate from a legitimate subdomain, making it appear trustworthy:

https://discover.techsmith.com/clkn/https/techsmlth.com?.techsmith.com/login

Victims would see discover.techsmith.com in the initial link, establishing false trust before the redirect occurs.

URL Unfurling Exploitation

URL unfurling is the process by which applications generate rich link previews by fetching metadata from a destination URL. Chat applications like Slack, Microsoft Teams, and iMessage use this to display previews of shared links. Because this open redirect requires no user interaction, these applications will display a preview based on the destination’s content rather than the trusted domain in the original URL.

An attacker could craft a link that displays a preview showing a fake invoice, password reset request, or urgent security alert—all appearing to originate from a trusted domain:

https://discover.techsmith.com/clkn/https/attacker-site.com?.techsmith.com/fake-invoice

This would show a preview from attacker-site.com while the shared link displays discover.techsmith.com.

Responsible Disclosure

This vulnerability was reported to Unbounce through their bug bounty program. Unbounce acknowledged the issue and awarded a $40 CAD bounty for the responsible disclosure.

Conclusion

This vulnerability demonstrates how analytics and tracking features can inadvertently introduce security risks. The pattern-matching approach to URL validation—checking only that a domain ends with a specific suffix—is insufficient when special characters can manipulate URL parsing.

Key takeaways for developers implementing similar functionality:

Use strict URL parsing libraries rather than regex patterns to validate redirect destinations
Maintain an explicit allowlist of permitted redirect domains when possible
Validate the parsed hostname, not the raw URL string, to prevent query string injection
Consider the security implications of features that redirect users based on URL parameters

Open redirects are often underestimated in severity assessments, but they serve as powerful tools for phishing campaigns by lending legitimacy to malicious links through trusted domain names.