PortSwigger Web Security

Vulnerabilities of interest

Here are some examples of vulnerabilities that we could consider to be valid, and rough guidelines as to what kind of payout you can expect:

Critical - $15,000

• SQL injection on portswigger.net
• Remotely retrieving arbitrary users' Burp Collaborator interactions
• Retrieve arbitrary users' AI interaction logs, with no user-interaction
• Unauthenticated RCE on Burp Suite DAST
• Complete authentication bypass on portswigger.net

High - $5,000

• Stored XSS on portswigger.net or the Burp Suite Enterprise Edition web interface
• File path traversal on portswigger.net
• A website accessed through Burp Suite can make Burp execute arbitrary code
• A project file loaded in untrusted mode can achieve make Burp execute arbitrary code with no user-interaction

Medium - $1,000

• A website accessed through Burp Suite can retrieve local files from the user's system
• A website accessed through Burp Suite can extract cross-domain data from Burp's sitemap
• Given a collaborator payload, an attacker can retrieve interactions generated from the same key
• Exploitable reflected XSS on portswigger.net or Burp Suite Enterprise Edition
• A project file loaded in untrusted mode can write or retrieve files from the filesystem with no user-interaction.
• CSRF on critical actions

Any medium severity issue involving unlikely user interaction - $100-$1000

• Reflected XSS that is unexploitable due to CSP
• CSP bypass via trusted domain, JSONP, etc
• Header injection in Burp Suite
• Open redirect

If a report does not qualify but we find it useful, we may reward it with reputation or swag as a goodwill gesture.

Forbidden activities

The following are strictly forbidden and may result in you being barred from the program, the website, or both:

• Denial of service attacks
• Physical or social engineering attempts
• Attacks targeting PortSwigger employees or customers. If you obtain employee credentials indirectly, eg via a public password dump, please report these including the source. Leaked customer credentials are not in scope but can be reported by email.
• Targeting subdomains of portswigger.net
• Bruteforcing subdomains
• Spamming orders
• Unthrottled automated scanning - please throttle all tools to one request per second.

We are not interested in low severity, purely theoretical and best-practice issues.

Here are some examples:

• Prompt injection with no security impact. Note that prompts are not considered private.
• Broken links
• Denial of service vulnerabilities
• Missing rate-limits
• Local privilege escalation that requires write access to the installer/program directory (eg most DLL hijacking)
• HTTP Options header
• Server errors with no sensitive information like https://portswigger.net/careers%22%3E
• Headers like Server/X-Powered-By disclosing version information
• XSS issues in non-current browsers
• window.opener related issues
• Unvalidated reports from automated vulnerability scanners
• CSRF with minimal security implications (logout, DoS, etc.)
• Issues related to email spoofing (eg SPF/DMARC)
• DNS issues
• Content spoofing
• Reports that state that software is out of date or vulnerable without a proof of concept
• Missing autocomplete attributes
• Missing cookie flags on non-security sensitive cookies
• SSL/TLS scan reports (this means output from sites such as SSL Labs)
• Client-side caching issues
• Concurrent sessions
• HPKP / HSTS preloading
• Implausible bruteforce attacks

There are a few known issues we consider to be low severity, but may fix eventually:

• Project files loaded in untrusted mode are only safe for read-only use.
• We are hardening our prompt injection defenses so this is not in scope. Note that if you can achieve RCE via plausible indirect prompt injection with no user-interaction, that would be accepted.
• You can use prompt injection to obtain prompts.
• Generic N-day vulnerabilities in the embedded Chromium browser will not typically be rewarded.
• Upstream TLS verification needs hardening
• Project files and configuration files may contain passwords, and are stored in plaintext by design. We recommend using full-disk encryption.

We do not accept PoCs that rely on local code execution, unless they are targeting an external system. For example, if you want to demonstrate "a malicious website can read local files", please host that site yourself for the PoC. This is to enable efficient triage.

Some other caveats and common mistaken reports:

• Issues relating to license enforcement and free-trial abuse are out of scope.
• Extensions, and configuration files such as user & project settings are considered trusted.
• login.portswigger.net is served by Auth0 - on this domain we're interested in PortSwigger-misconfigurations only.
• Non-whitelisted subdomains of portswigger.net are strictly out of scope. Do not test these.
• Our Web Security Academy is full of intentional vulnerabilities including SSRF and RCE, and completely isolated from the rest of our infrastructure. As such, it's excluded from our bounty program.
• If you wish to test the Burp Collaborator functionality, please configure your own private Collaborator server and test that.
• The Paypal price can be tampered with but underpayment will result in product non-delivery so this isn't a security issue.
• Just like extensions, Bambdas can execute arbitrary code by design
• Invoices, quotations and receipts can be accessed by anyone who is given the link. This is an intentional design decision to enable sharing (the ability to view someone's invoice without being given the link would be considered a serious vulnerability)
• Collections can be accessed by anyone who is given the link until they expire - the encryption key is stored in the URL fragment. Support for in-product deletion will be added in the future.
• Changing the proxy settings to listen on a non-loopback IP exposes the web interface to people with network access by design.
• Deleting a request in Burp does not overwrite it in the underlying project file. If you want to remove a request from a project file before sharing it, delete it then use Project->Save Copy to create a sanitised project file.
• We use Content-Security-Policy (CSP) site-wide. This means you will have a hard time doing alert(1). We pay for HTML/JavaScript injection regardless but to maximize your payout, see if you can make a payload that will steal some sensitive information.
• We deliberately allow unauthenticated access to Academy lab URLs (*.web-security-academy.net).
• Some scanners report a false positive STARTTLS vulnerability on the Collaborator Server.
• The collaborator server creates an interaction for every valid ID it sees in a message, so one message can create multiple interactions.
• Our voting system under /polls/ makes a token effort to discourage people from voting multiple times. We know you can bypass this.
• As the makers of Burp Suite, we can assure you that we have already scanned our website with it. Don't waste your bandwidth.

What constitutes a vulnerability in Burp Suite?

The system that Burp Suite runs on is trusted, and every system that can access the Proxy listener is trusted to access the data within Burp. Extensions, and configuration files such as user & project settings are considered trusted. Websites accessed through Burp are untrusted, so anything a website could do to read files of the user's computer, read data out of Burp Suite, or gain remote code execution would be considered a vulnerability. Also, any way to get someone else's Collaborator interactions would be considered a vulnerability. Detection of Burp usage, denial of service vulnerabilities, and license enforcement/obfuscation/free-trial issues are all out of scope. Please refer to the payout guidelines for some example vulnerabilities.

Project files are trusted by default. If a project file is loaded in non-trusted mode, it should be harmless provided you don't proxy traffic through it, or use it to send requests. Please note that users will be automatically prompted to load unrecognised project files in non-trusted mode, but this prompt is not a security boundary and can be bypassed in some scenarios.

About Burp extensions & BApps

Extensions in the BApp store are out of scope for this program, unless they're authored by PortSwigger. You can report a vulnerability in a BApp directly to the maintainer by going to its page on GitHub and clicking the repo under "forked from". If a critical issue is not getting fixed, you can escalate it to [email protected]

Contact

If you have any questions, or want to report a vulnerability without opting in to the reward program, you can contact us at [email protected]

Good luck and have fun!