How I Earned a $617 Bounty from GitHub

Bits and Bytes with Richard: How I Earned a $617 Bounty from GitHub Saturday, June 14, 2025 How I Earned a $617 Bounty from GitHub Not Essential (Intro) Hey folks, it's been a while since my last blog post. To be honest, i suffer from a serious case of procrastination when it comes to writing, and I have huge respect for everyone who does it consistently. I've decided that instead of not sharing my findings at all, it would be better to switch things up. So, this blog is about to become more of a vlog. Expect more proof-of-concept (PoC) videos and a bit less text. Please bear with me as I try out this new format. This first post is special. It covers my first validated bug on HackerOne  ever since,i temporarily stopped hacking on bugcrowd. The Vulnerability Explained The core issue I discovered was a two-part authorization bypass within the GitHub Rulesets feature, stemming from the application improperly trusting a client-side check to gate sensitive actions. By intercepting the /sessions/in_sudo endpoint and using a match-and-replace rule to change the API's response from false to true , I could trick the front-end into believing my session had elevated sudo privileges. This allowed me to perform two critical actions without the required password re-authentication: first, creating a new ruleset (Report #3075134), and second, deleting an existing one (Report #3094044). Because both vulnerabilities relied on the same flawed validation mechanism, they were essentially two sides of the same coin, and the server-side fix for the first report ultimately resolved both. Why This Worked: The Client-Side Trust Issue The vulnerability existed because of a classic security anti-pattern: the back-end trusted the client's state . Think of it like a security checkpoint with two guards. The first guard (the front-end UI) is supposed to ask for your password. It determines whether to do this by asking a separate endpoint, /sessions/in_sudo , "Is this person already in sudo mode?" When that endpoint returned false , the UI knew it had to show the password prompt. However, by intercepting the response and changing it to true , I essentially told the first guard, "Don't worry, I'm already cleared." The crucial mistake was that the second guard (the back-end API that actually creates or deletes the ruleset) never performed its own check. It trusted that the first guard had done its job and blindly accepted the request. The single source of truth for security must always be the server; in this case, the sensitive action was gated by a UI element that could be manipulated, rather than by a strict, non-negotiable server-side permission check. The Proof of Concept (PoC) Video Talk is cheap, so here's the video. It demonstrates exactly how this vulnerability worked in practice, from intercepting the request to successfully creating and deleting a ruleset without the proper authorization. ---------------------------------------------------------------------------- Thanks For Coming Here!! I hope this was interesting and a good look into both the technical and human side of the issue. I'm excited to share more in this new format soon. Before I sign off, I need to give a few important shout-outs. A huge thanks to the Critical Thinking team for their excellent video on client-side match and replace techniques. A big thank you to the teams at HackerOne and GitHub for running an awesome bug bounty program and for graciously allowing me to disclose this finding, even as a low-severity vulnerability. Finally, a special shout-out to dev.ai   who thinks it's chatgpt for  some weird reason   for being a fantastic brainstorming partner and helping me structure this post to bring it all together. Byeeeeee!!!!!!!!!!!! at June 14, 2025 Email This BlogThis! Share to X Share to Facebook Share to Pinterest Labels: Client-Side-Validation-Bugs 3 comments: Anonymous June 14, 2025 at 6:23 AM Thanks for sharing dude Reply Delete Replies Anonymous June 17, 2025 at 6:40 AM THANKS MATE FOR READING Delete Replies Reply Reply Anonymous June 16, 2025 at 1:58 AM Thank Reply Delete Replies Reply Add comment Load more... Older Post Home Subscribe to: Post Comments (Atom) How I Earned a $617 Bounty from GitHub Not Essential (Intro) Hey folks, it's been a while since my last blog post. To be honest, i suffer from a serious case of procrasti... How I Earned a $617 Bounty from GitHub Not Essential (Intro) Hey folks, it's been a while since my last blog post. To be honest, i suffer from a serious case of procrasti... THE FIRST ONE Welcome to My Blog Hey there, I’m Richard, and I’m super excited to kick off this blogging journey with you. As a part-time bug bounty hunt... Navigating the Cybersecurity Landscape: My Journey to Becoming a Source Code Reviewer My Journey to Becoming a Source Code Reviewer Hey guys! I’m Richard, and I’ve been interested in cybersecurity for a while now. My journe...