Bypassing the Current Password Protection at PayPal TechSupport Portal

بسم الله الرحمن الرحيم

Please kindly visit this simple paper directly to looking this release (December, 2017 Article):

[English Version] PayPal — Bypassing the Current Password Protection at PayPal Tech-Support

For completing the explanation, we upload the video at Youtube:


As could be seen previously at another report, for completing the support to all of PayPal’s merchant, PayPal provides the technical support portal (located at: https:/ for their merchant to communicate each other when they would like to discuss about the integration, feedback about the needed new feature, or any technical issue that could be face by PayPal’s merchant.

Figure 1 PayPal Technical Support Portal

Just like a common support portal, for facilitating their customer to track the issue, PayPal providing the feature that could be used by their customer to registering themselves with their own account. With the ability to create their own account with their own credential (password), generally users will meet one of the famous common feature such as “Change Password” feature.

Figure 2 Change Password Feature

But the problem exists when the “Change Password” feature didn’t works well to protecting the customer from unauthorized changes. In this case, the Attacker could bypass the “Current Password” Protection feature at application to change the victim’s password. In other words, without supply the current password / the knowledge of current password, the Attacker could change the victim’s password.


Not much thing that could be explain at this part since this we are very sure if the readers are really familiar with the “change password feature” that protected by “current password” field. By this consideration, then we could go directly about the flow that provides by PayPal to use this feature.

The change password feature at the support portal could be found at or commonly we could see this feature from clicking “My Stuff” URL at

Figure 3 Change Password Feature (Left) and the Location of the Feature (Right)

When user trying to change their Password, normally the application will send a request into with several POST Parameter. Here is the example of the request:

POST /ci/ajaxRequest/sendForm HTTP/1.1
Accept: */*
Content-Length: 477
Cookie: <cookies_over_here>
Connection: close

Table 1 Request for Password Changes

If we try to decode the POST parameter, then we will find it like this:


Table 2 Decoded POST Parameter

As we could see from those full decoded parameter, there is a common interesting part at the “Form” parameter. There is “currentValue” parameter that act as the parameter to receive the input of previous password that type by user to change their password. In those decoded value, it tells us if the current password is “Password!#%” and the new password is “Password!#%!#%”.

The problem in this situation is: if we remove the “currentValue” parameter and leave it only “Contact.NewPassword”, then the application still processing the request and change the user’s password without the needs to validating the current password.


As stated earlier, we should remove the “currentPassword” parameter completely to executing this PoC. Please note, the “complete” word in here means the %2C%22currentValue%22%3A%22%22 parameter (which is: ,”currentValue”:”” )

Here are the step by step to reproducing the issue:

3.1. The first one is put a random password at the “Current Password” Field. For example, asdasdasdasdasdasdas.

Figure 4 Submitting Random Old Password

3.2. The second one is put the new password at the rest of the field just like the picture above;

3.3. Setting up the Burpsuite interceptor and make it “on” so the request could be intercept later;

3.4. Back to the browser and send the request by click the “submit” button or press the “enter” key;

3.5. After the request has been sent, then go to the interceptor again and see the request.

Figure 5 Hold the Request with Interceptor

As we could see, there is a “currentValue” parameter with the asdasdasdasdasdasdas value. It could be seen with: %2C%22currentValue%22%3A%22asdasdasdasdasdasdas%22

So, all the things that we should conduct is remove completely those parameter from %2C%22currentValue (which is ,”currentValue) until asdas%22 (which is asdas”).

If we trying to decode the POST Parameter, then it just leave this:


Table 3 Modify the POST Parameter

Please kindly note: When we send the modify request, the application will showing an error. But it doesn’t matter since at the backend process, the password has been changed completely.


For completing the explanation, we upload the video at Youtube that could act as Proof of Concept related this report:

As a support of explanation, here are some information that could be helpful to looking the video:

4.1. The account of the victim is

4.2. The current password is Sup3rN3wPassw0rd!#

4.3. Attacker put a random password, which is asdasdasdasdasdasdas;

4.4. Attacker tries to change the password into the new one, which is N3wPassw0rd!#!#!#

4.5. Attacker send the request and intercepting it with interceptor;

4.6. Attacker remove the asdasdasdasdasdasdas value from the request;

4.7. Attacker remove the %2C%22currentValue%22%3A%22%22 parameter from the request;

4.8. Attacker send the request to server;

4.9. Application shows an error;

4.10. Attacker refresh the application and get logout automatically;

4.11. Attacker tries to login with the new password that made by the Attacker itself;

4.12. Attacker success to login.


One of the very useful lesson to be learned is we should try to spare our time to read any research that conduct by another researcher. As an information, trick was inspired by the both of research that conduct by Henry Hoggard (PayPal 2FA Bypass) and Suleman Malik (Password Validation bypass at Blackberry).


The initial bounty was sent on August 10th, 2017. And the final bounty was sent on October 27th, 2017.