# The $600 HTML Injection Incident: Standing Up for Your Rights
Written on
Chapter 1: The Encounter with Triagers
For fans of the Harry Potter series, the term "Death Eaters" may ring a bell, but in the world of cybersecurity, we often refer to similar gatekeepers as triagers.
Triaging involves evaluating a security event to assess whether it constitutes an actual security incident, its priority level, and whether it warrants further attention. This process can vary significantly, especially when dealing with potential malware threats.
As you delve into the Bug Bounty scene, you'll quickly learn the importance of carefully navigating conversations with triagers. While identifying a bug might seem straightforward, securing its acceptance is often the real challenge. The nature of the vulnerability plays a significant role, but if your discovery is dismissed as a non-issue, be prepared for disappointment.
This frustrating aspect of Bug Bounty programs is perpetuated by a select group of triagers who wield significant power over the validation of reports. If you fail to communicate effectively with them, your submission may be marked as "Not Applicable" (N/A). Regrettably, these triagers often don't bother to consult with companies about the relevance of your findings.
Section 1.1: The Company Behind the Vulnerability
Atlassian Corporation Plc, an Australian software firm, creates tools for software developers and project managers. Their products are crucial for millions worldwide, enhancing software development, project management, collaboration, and code quality.
In my review of their platform, bitbucket.com, I stumbled upon an HTML injection vulnerability that could lead to stored cross-site scripting (XSS). It was a straightforward find:
<html> <body> <script> alert('Hello, world!'); </script> </body> </html>
Their interface bears a striking resemblance to other platforms like GitHub and GitLab.
Using the description field while saving a repository, I embedded the payload, which triggered a pop-up with each page reload. However, after just one hour of submitting my bug report, it was closed as N/A. The triager claimed that my actions were only possible because I owned the repository, alongside some other dubious justifications.
I attempted to reason with them, but triagers are often unreceptive to feedback, even when it’s warranted. One individual, known as Trim_Bugcrowd, has a notorious reputation for exploiting their authority. Just two weeks prior, an internal investigation was launched regarding this person's conduct, and I will share updates as they become available.
Section 1.2: Seeking Justice
Frustrated by the lack of acknowledgment, I decided to contact Atlassian directly, urging them to revisit my report since it was mishandled. To my astonishment, they responded promptly, assuring me they would investigate the matter.
The security lead at Atlassian recognized the severity of the issue. Not only did he compensate me for my initial report, but he also rewarded me for two additional reports out of the six I had submitted. After identifying the triager’s error, he reopened all my previously closed submissions.
Chapter 2: The Consequences of Advocacy
One cardinal rule in Bug Bounty programs is to refrain from contacting companies after your reports have been closed. Doing so can lead to account termination or temporary bans. Unfortunately, I faced a two-week ban despite having a valid report. The triager responsible for the oversight offered no apologies for the repercussions of their actions.
Final Thoughts
Having faced this situation before, I grew weary of the mistreatment and decided to take matters into my own hands. It’s essential not to allow individuals to misuse their power at your expense. Many would be surprised to learn how often I have achieved favorable outcomes after reaching out to companies directly. The last of my six reports was finally resolved after seven months, thanks to my persistence.