↓ Skip to main content
An empty toll plaza with its barrier raised and the roadway continuing straight through the lanes.
Photo by Niyazi Gökdoğan on Unsplash
  1. Research/

PayPal Stored XSS via a Signup Flow Bypass

·2 mins
Stored XSS Second-order delivery img onerror Business logic flaw
Patrik Grobshäuser
Author
Patrik Grobshäuser
Security researcher at Assetnote / Searchlight Cyber. Before that, seven years triaging other people’s reports at HackerOne and Shopify. Hunting bugs since 2012, published as Patrik Fehrenbach until 2025.
Table of Contents

I recently discovered a stored cross-site scripting vulnerability on PayPal’s core site. The scenario is a little convoluted, but I will try to explain it as clearly as possible.

Finding the bug
#

During testing I often create accounts with malicious JavaScript content in the name, organisation and similar fields. While testing PayPal I did the same, and tried to register an account with the username:

"><img src=x onerror javascript=alert(1337)">.jpg

The vulnerability
#

When I tried to complete the registration, PayPal’s security module returned an error saying there was a problem with my request. Looking at the URL, I saw that it tracked the progress of the signup flow:

https://www.paypal.com/webapps/merchantboarding/webflow/unifiedflow?execution=e1s1

The first thing that came to mind was that this is the same URL you land on once logged in to a legitimate account, so I tried erasing everything after /webapps/ — and suddenly I was inside my new PayPal account, with the malicious JavaScript content intact. I went to the profile settings page and saw that three of my JavaScript snippets had executed. So far so good. As some of you know, you need a scenario in which other PayPal users can actually be exploited in order to qualify for a bounty. So I thought about how to deliver this payload to other PayPal users. A few months earlier I had also found a stored cross-site scripting issue inside an invoice created by PayPal. If you look at the PayPal landing page you will see that every invoice you receive includes the name of the user who sent it to you. So: my username is malicious JavaScript, and PayPal lets me send an invoice to any PayPal user knowing only their email address. So I created an invoice and sent it to my second PayPal account. I logged in to that account, and the JavaScript prompt appeared on screen.

Proof of concept
#

To summarize the progress:

  1. Create an account with the malicious Payload

  2. At the point where the PayPal system stops you from continuing, truncate the URL to /webapps/ (this bypasses the security check)

  3. Create an invoice, send it to the victim

  4. Victim logs in to their account and the payload executes

I recorded a short proof-of-concept video demonstrating the impact. (The video did not survive the migration of this site.)

Related