From Bug Bounty Hunter to Offensive Security Engineer Adventure (Short story and reflection)

April 18, 2026 marks exactly four years since I first joined VikingCloud as an Offensive Security Engineer I back in 2022.

Few years ago, I never would have imagined that a college dropout and skidd bug bounty hunter like me would land a proper role in the information security industry. While I had always manifested of breaking into cybersecurity, I had no clear idea of how to get there.

The early days of my bug bounty journey

When I first started in bug bounty hunting, I was completely lost. I had some experience with basic web application security (thanks to my time tinkering in underground communities) but beyond that, I had no structured knowledge. Vulnerabilities like IDOR and SSRF were foreign to me. I didn’t even know how to systematically look for vulnerabilities. Instead, I relied on scattered articles and twitter posts from more experienced hunters, trying to piece things together.

The struggle to learn

Between 2012 and 2015, learning about security vulnerabilities was far more difficult than it is today. Quality write-ups and blogs were scarce, and structured learning paths were almost nonexistent. The best way to learn was to immerse yourself in the bug bounty community. Twitter (now X) became my go-to platform for connecting with experienced hunters. Fortunately, there were pioneers like Bitquark, Neal Poole, Yuji Kosuga, Roy Castillo, and other OGs who shared their findings and techniques. Their insights were invaluable to beginners like me—I would read their posts, analyze their methods, and then apply them to real-world targets.

Finding bug bounty programs was a challenge

Unlike today, where multiple platforms offer structured bug bounty programs, back then, finding targets was an entirely different struggle. Only a handful of companies had bug bounty initiatives, and public programs were rare. My approach? Hunt on any website that seemed promising, especially those shared by other researchers on twitter. I also leveraged google dorking to uncover companies that quietly ran bug bounty programs or had security policies that allowed responsible disclosure.

Transitioning from bug hunter to engineer

Transitioning from independent bug hunting to corporate offensive security required a major mindset shift. In bug bounty hunting, success is often measured by finding high-severity impact bugs as fast as possible. As an Offensive Security Engineer, finding the flaw is only half the battle; Context Matters, you have to understand business risk, threat modeling, and internal architecture rather than focusing solely on isolated vulnerabilities. Methodology over Luck, relying on opportunistic findings gives way to thorough, coverage-based security assessments and comprehensive threat testing.

The resilience, creative problem-solving, and continuous learning mindset I built during those early, chaotic bug bounty days became my greatest strengths when stepping into an engineering role.

Looking back, the journey wasn’t easy. It was filled with uncertainty, frustration, and countless hours of trial and error. But those early struggles laid the foundation for everything that followed.

Four years into my role as an Offensive Security Engineer, I can say with confidence that persistence and community support made all the difference. To anyone just starting out—keep learning, keep hunting, and never underestimate the power of connecting with like-minded people.

“Continuance is power. (継続は力なり)”
— Japanese Proverbs

pWning resources.gcash.com using HTTP PUT method enabled vulnerability (Write Up)

Howdy Readers,

During my random testing for my personal project toolkit for web application assessment, I found a very simple and very interesting vulnerability that allows me to easily pwn my target due to a HTTP method misconfiguration. The target has an HTTP PUT method-enabled vulnerability, and it was detected by Nuclei scan since one of the tools for my project toolkit is Nuclei from ProjectDiscovery. 

What is the HTTP PUT method enabled?

HTTP PUT method allows clients to upload data to the server, often used for creating or modifying resources. If this method is enabled on a server or web application without proper restrictions or authentication, it can become a significant security vulnerability. Unauthorized users could potentially upload malicious files, overwrite existing files, or cause other forms of disruption.

So long story short. during my testing, I was able to upload a test HTML and text file for PoC, and it also allows me to overwrite the index file of the vulnerable target (easy deface).

WordPress TotalPoll Plugin Race Condition vulnerability (Write Up + AI generated blog)

Howdy Readers!

A race condition vulnerability has been discovered in the popular WordPress TotalPoll plugin. The vulnerability allows attackers to generate votes for their favorite streamers by exploiting a race condition in the plugin's voting logic.

The vulnerability exists in the TotalPoll plugin's voting logic. When a user votes for a poll, the plugin calls a function to update the poll's vote count. However, the function does not properly synchronize access to the vote count, which can lead to a race condition.

A race condition occurs when two or more threads of execution try to access the same data at the same time. If the data is not properly synchronized, it can be possible for one thread to overwrite the changes made by another thread.

In the case of the TotalPoll plugin, the race condition can be exploited to generate multiple votes for a poll. This can be done by creating multiple threads that all try to vote for the same poll at the same time.

The vulnerability is particularly concerning because it can be used to manipulate the results of polls. For example, a streamer could use the vulnerability to generate votes for themselves in order to win a poll.

The TotalPoll plugin has been updated to fix the vulnerability. However, users who are running an older version of the plugin are still vulnerable.

To protect yourself from this vulnerability, you should update the TotalPoll plugin to the latest version. You can also disable the plugin if you do not need it.

Here are some additional tips for protecting yourself from race condition vulnerabilities:

• Use a web application firewall (WAF) to block malicious traffic.
• Keep your software up to date.

--Tools--

• BurpSuite

--Proof of Concept--

Found this vulnerability 2 years ago while watching a stream on Twitch, The streamer announced she was nominated for a contest. So I checked the contest link and discovered the vulnerability after around 20-30 minutes of inspecting some of the website's features.

--Report Timeline--

Reported: May 12, 2021

First Response: May 12, 2021 (I'll need to check this with the team so we can decide whether we add "rate limitation" feature to the upcoming versions or not)

After reporting the issue, I didn't receive any updates from them.

I hope you find this article interesting and useful.

“Learn as if you will live forever, live like you will die tomorrow.”

— Mahatma Gandhi