I thought I had a P1, but… the second paid valid bug in 2026

I thought I had a P1, but… the second paid valid bug in 2026 | by Hoi Huynh - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original I thought I had a P1, but… the second paid valid bug in 2026 It's me, c0nyy. This is a my journey with the second paid valid bug in 2026, fasten your seatbelt and… just relax. Hoi Huynh Follow ~4 min read · April 5, 2026 (Updated: April 5, 2026) · Free: Yes Hello friends! Let's get started! How a Simple SSRF led to third-party token exposure and SQL Injection 05 Jan 2026: Found a token leakage via an SSRF vulnerability. The target entry point looked like: " https://target.com/bla/bla/url=https://third-party- service.com/some_path/another_path/q?bla&bla" This was clearly an SSRF endpoint, right? So I tried multiple payloads to reach internal services and external website via the url parameter but… nothing worked 😐 Due to configuration restrictions, the request only worked when the referer was from https://target.com and access was limited strictly to: https://third-party-service.com/some_path/another_path/q?bla&bla . You know what? I removed part of the q parameter value. Now, the request looked like: " https://target.com/bla/bla/url=https://third-party-service.com/some_path/another_path/q" And… boom!!! A backend page was returned, exposing a token directly in the HTML response. That's when i knew, this might be my first P1 of 2026. 12 Jan 2026: After the Bugcrowd team triaged the report. The client response: "This feature only captures user activity and is therefore not critical in nature. We will be processing this as Informational and marking it as closed." I thought I had found a valid bug, but it was classified as P5, and the report was closed 😐 Not accepting this decision, I continued abusing the exposed token to further explore the third-party backend service. I started researching the backend service in depth. During this process, I noticed that several vulnerabilities — such as XSS, SQL Injection — had recently been discovered in this product. That gave me an idea 💡 What if I could exploit a vulnerability in the backend service to modify its data? If successful, I could potentially manipulate the data reflected in the target application's frontend. This opened up a potential attack chain. Let's take a deep dive into that product… After a few days of analysis, I identified and reproduced a stored XSS vulnerability in the backend service. However, I was unable to find any frontend vector to load and trigger the payload, so I pivoted to SQL injection. Using my "Kenbunshoku Haki" I quickly identified an endpoint vulnerable to SQLi and successfully reproduced the issue using a common payload: '); WAITFOR DELAY Ɔ:0:5' — Kenbunshoku Haki 14 Jan 2026: Submitted another report with a newly discovered SQL Injection vulnerability in the backend service using the leaked token. At this point, the full attack chain was clear: SSRF → Token Leakage → SQL Injection By exploiting this SQLi vulnerability, an attacker could manipulate data in the target application. There you go — a complete attack chain leading to my first P1 of 2026. 11 Feb 2026: The client asked me to provide methods to extract database metadata (e.g., hostname, database name, database user). → Provided a full Python script with some help from Gemini :) At the same time, while waiting for their response, I realized this issue could potentially impact other clients as well. → I decided to report this SQLi vulnerability to the third-party backend security team . 12 Feb 2026: The client had issues reproducing my PoC → Resolved. 20 Feb 2026: The third-party security team requested additional steps to reproduce the vulnerability. 23 Feb 2026: The client confirmed they could reproduce the issue. However, they noted that the affected data belonged to third-party infrastructure. "This could be a bug, but it is owned by third-party infrastructure… and the app team cannot edit any of our own data." They then asked me to attempt modifying an existing data to demonstrate potential impact on client data. 24 Feb 2026: Although the user account did not have high privileges, I was still able to modify data as requested. I quickly identified the relevant table and used an UPDATE query to modify the data. 17 Mar 2026: After a month of waiting the client finally responsed, but… "We spoke with the app and data owners, and it was determined that the impact of the bug found was not as severe as anticipated…Furthermore, our critical systems do not rely on that data… We will be marking the severity as P3." Oh my P1!!! :( Not exactly how I imagined my first P1 would end. 21 Mar 2026: I realized I hadn't sent the reproduction steps to the third-party security team earlier. → Sent them the detailed steps to reproduce. 23 Mar 2026: Retested the vulnerability, but it appeared that a patch had been implemented for the affected endpoint. The issue was no longer exploitable. 02 Apr 2026: Followed up with the third-party security team for updates, but haven't received any response yet. Still waiting for the third-party security team to confirm this bug. And see you next time! #bug-bounty #pentesting #hacking #hacker Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).