Responsible Disclosure: Using GitHub Search (without logging in using SSO) still allows searching

Featured image for sharing metadata for article

I've responsibly disclosed my first security vulnerability πŸ‘ Not only that, but it was actually a problem, and it was fixed very quickly, and I've ended up getting a payout for it! Not bad for my first, lucky, discovery πŸ˜„


Below is the report that I shared with GitHub on HackerOne.

This is my first report, so any feedback would be appreciated!


  • Proposed CSSS V3 Calculation: High 8.3
  • Accepted severity: Medium
  • Reward: $4000 plus a GitHub Pro (individual) subscription for life, and 40 points of swag in the GitHub Bounty Swag Store


It appears that GitHub Search does not correctly perform authorization checks when a user is set up with GitHub SSO.

A user who is not logged into GitHub SSO (i.e. on a different machine, or they've been logged out of GitHub SSO, but not GitHub) can search for content that is in non-public repos.

Note that this only works for Internal repos, not Private repos.

The user must already be added to the organisation, so some level of trust is required.

However, this could i.e. allow exfiltration of data onto unsecured machines.

Steps To Reproduce:

  1. A user is added to an organisation that requires GitHub SSO
  2. The user does not log in via SSO
  3. Use GitHub search to look for a string that exists in an Internal repo, such as org:Elastic

See attached example of searching for a known string in the Elastic organisation.

First image (search results) is using my personal machine, which is not logged in with GitHub SSO.

A screenshot of the GitHub search page for the search query A number of the repositories' results are minimised to highlight the code snippet that can be seen in the elastic/dependency-management-data repository. The code snippet is not very sensitive (hence being safe to share here) and just shows that there is a Dockerfile that's installing the dmd-web command-line tool

Second image (repo view) is using my work machine, which is logged in with GitHub SSO.

A screenshot of the GitHub repository header showing the repo name dependency-management-data and an "Internal" label, indicating it's a repository with Internal privacy settings


This allows an attacker - who has compromised a GitHub account of an employee, but who does not have access to log in via GitHub SSO - to exfiltrate data from Internal repos, which could be onto unsecured machines, or as a means to gather intelligence about the organisation.


  • 2024-04-14: Issue discovered and reported to GItHub via HackerOne
  • 2024-04-15: Issue acknowledged by GitHub
  • 2024-04-22: Issue fixed by GitHub
  • 2024-05-09: Issue scored
  • 2024-05-09: Blog post published
    • As it was noted that it's now fine to publicly post about this


As mentioned, this was my first security finding of an external tool, and it was very exciting. I spent a bit of time trying to confirm the behaviour I was seeing, to avoid logging a false finding, and narrowed down whether it was just this repo I was testing with, as well as a few other Internal and Private repos that I had access to, inside the Elastic organisation and others I'm part of.

I appreciate the engineers at GitHub for their timely responses, detailed replies where possible, and their patience with my excitement to find out whether it a) was a valid finding and b) how it'd be scored.

I will say that knowing that GitHub has an excellent Bug Bounty program and with some very modest rewards led me to spend some time considering which of the reward tiers this may sit within.

It was my first time doing a CVSS rating, so although I feel I rated it fairly, I wasn't sure if I was maybe overblowing it when it came out as a High rating. I appreciate that GitHub have rated it as a Medium based on their own scoring, and am very appreciative and excited by my first finding being a big one!

It's not at all my first time reporting a security vulnerability, but I'm generally used to it being at the company I'm currently working at (for instance around dangerous things in logs or access control being a bit funky), so it was cool to see the process elsewhere.

And also a big thank you to Terence Eden whose responsible disclosure writeups have been very interesting to read in the past, and I appreciate your public posts post-disclosure.

Written by Jamie Tanna's profile image Jamie Tanna on , and last updated on .

Content for this article is shared under the terms of the Creative Commons Attribution Non Commercial Share Alike 4.0 International, and code is shared under the Apache License 2.0.

#responsible-disclosure #github #sso.

This post was filed under articles.

Interactions with this post

Interactions with this post

Below you can find the interactions that this page has had using WebMention.

Have you written a response to this post? Let me know the URL:

Do you not have a website set up with WebMention capabilities? You can use Comment Parade.