Originally posted March 31, 2020 to

NOTE: The content in this post is solely for educational purposes.

The Substack team was kind enough to allow me to disclose this vulnerability. As stated by the title, I found an Open URL Redirection vulnerability and a Reflected Cross-Site Scripting (XSS) vulnerability in the company’s web application. If you want to learn more about the nature of these types of vulnerabilities and how they can relate in this case, here’s an article that explains it.


While setting up a newsletter for LetterMatch, I noticed that a visitor to a Substack newsletter’s subscribe page will sometimes see a next URL query parameter that describes where they’ll be redirected after subscribing. The URL would follow the{target_endpoint}, where {target_endpoint}  is the location to which the visitor will be directed after subscribing. Note that this applies to any  Substack newsletter, not just LetterMatch’s.


Because redirection schemes that look like this are, at times, susceptible to Open URL Redirection, I tried visiting the URL  and subscribing. After doing so, I was redirected to Now that this case was validated, I tried finding methods of obscuring the destination URL. This is because a victim may notice the second, potentially malicious URL and choose not to visit the link. With that said, I tested several different ways to encode an URL and saw that most of the variations worked in place of the plain


Vulnerabilities of this type are typically used in a chain with others to exploit victims, but conceptually this can be used to redirect users to phishing sites or sites that exploit browsers to install malware on a victim’s device, like when hackers exploited an Open Redirection vulnerability in a U.S. Department of Health & Human Services web page to install malware on visitors’ machines. A bit more detail here.

Increasing the Impact

Some Open Redirect vulns can also lead to Cross Site Scripting (XSS) attacks, most often Reflected XSS attacks, if the payload or, in this case, the destination URL is valid JavaScript.

Interestingly, injecting script tags as the parameter value didn’t have an effect, but injecting JavaScript “URLs” of the form javascript:{some-code-here} as the parameter value results in the injected code being executed. An example of this can be found in the demo below, where I inject a window alert.


Here’s a video demo of the this vulnerability being exploited before the patch. I don’t consider it a proof of concept, as I demonstrate the exploitation with a benign redirection location and injected code.

In Conclusion

I raised this issue with medium severity because of the Reflected XSS that’s involved. The Substack team was very considerate in finding time to fix this vulnerability so quickly. They’re a relatively small team with a lot of responsibilities, so their diligence was appreciated, especially as we all adapt to the circumstances of current events.


Jan 28, 2020 - Initial email disclosing vulnerability details
Jan 31, 2020 - Response from Substack and patch of XSS
Mar 26, 2020 - Notification of full patch (Open Redirect and XSS)
Mar 26, 2020 - Request to fully disclose findings
Mar 30, 2020 - Permission to fully disclose findings granted