New Bug Bounty Treasure Map + Scope Update

Lindsey Glovin, Program Manager, Product Security

• We created a new bug bounty treasure map to help researchers find more valuable bugs.
• Our program scope was updated to emphasize security impact of bugs.
• Payment assessments got a reboot to reward what we care about most — protecting user data.

When we launched our public bug bounty program in March 2016, we released a treasure map to tell researchers where to look for security bugs. Since then, feedback from researchers led us to commit to providing more resources like this.

Today, we’re excited to share the second generation of our bug bounty treasure map! This new version helps researchers find the most valuable treasure in our program: high impact security bugs.

We’re also introducing an updated program scope to better reflect the current state of Uber’s technical environment and the security vulnerabilities our bug bounty team cares the most about. This update focuses on defining the security impact of any given issue and will help researchers know which types of vulnerabilities are most important to our program (e.g. will receive the highest potential bounty).

Finally, we’re launching a complete reboot of our previous payment assessments to focus on what we care about most — the security of user data. As a result of these changes, the payment amounts of older reports should not be viewed as precedent for payments going forward.

Updated Program Scope

In the same way Uber’s code is constantly evolving, so will our bug bounty scope. We will continue to make updates as we learn more about our attack surface and roll out new protections.

Since launching our public bug bounty over a year ago, we now believe the traditional model of “domain + vulnerability class” is insufficient for determining bounties. For example, it’s not uncommon to reverse-proxy routes to a specific microservice, meaning an SSRF in partners.uber.com/profile versus partners.uber.com/documents can have different security impacts and therefore warrant different bounty amounts.

Additionally, if a microsite on a domain is not listed as in-scope but has a vulnerability that exposes user data, the traditional model would consider this out-of-scope. However, we care deeply about both of these situations. So, instead of making ongoing exceptions, we’re taking a more holistic approach to address the limitations of a traditional assessment model.

Specifically, we are moving to an updated scope guided by the upper bound of security impact for a report based on what the specific bug can do. As a result, researchers should expect bug assessments and bounty amounts to reflect security impact rather than technical complexity. We strongly suggest researchers explicitly connect the issues they discover into the defined security impact buckets within their report.

Below are more details on the security impact buckets that are now in-scope, along with specific vulnerability examples to illustrate our thinking.

The New Treasure Map: Security Impact Buckets

Helping researchers understand what’s most important to our bug bounty team is one way we hope to ensure the time spent looking for bugs on our platform is worthwhile. Our program guidelines page has the full details on how we define security impact buckets. Please check it out for specific examples of vulnerabilities that are or aren’t in-scope now.

Researchers are encouraged to focus on technical vulnerabilities from the categories below. Traditional social engineering, fraud (e.g. promo code abuse) and credential stuffing are still out-of-scope.

• Exposure of user data: Technical vulnerability that provides access to user or employee data without authorization
• Unauthorized Requests on Behalf of User or Employee: Technical vulnerability that enables forging authenticated requests on behalf of a user
• Monetary Impact: Technical vulnerability that leads to fake payment profiles, widespread service disruption, or loss of IP.
• Phishing: Technical vulnerabilities that collect user or employee credentials (social engineering is still out of scope)
• Physical Safety: technical vulnerabilities that lead to bypassing physical safety controls

The Next Chapter

As we near 18 months since the launch of our public program, we’re increasingly grateful for the hundreds of researchers who participate and help us protect Uber users. We’ve paid more than $1M to date and we’re excited to work with you during this next chapter to continuously improve our program, find new ways to eradicate bugs from our codebase, and give back to the research community.