A Lesson in HTML Injection & Content Spoofing

Not every vulnerability comes from new features.

Sometimes, it comes from fixes themselves.

In 2016, after HackerOne patched an HTML injection issue, I decided to test the fix instead of moving on. The idea was simple:

What if the patch introduced something new?

Testing the Markdown Parser

HackerOne relies on Markdown to render user input. A typical Markdown link looks like this:

[text](url "title")

The parser expects clean input and properly closed quotes. I wanted to see what would happen if I added extra quotes and unexpected attributes.

The Payload

I submitted this input:

[test](http://www.torontowebsitedeveloper.com "test ismap="alert xss" yyy="test"")

This included:

• additional double quotes

• ismap (a valid HTML attribute)

• yyy (an invalid attribute)

The goal wasn't XSS – it was to test how flexible (or fragile) the parser really was.

What Happened

The Markdown editor generated unexpected HTML and accepted arbitrary attributes inside the <a> tag.

Even though the issue wasn't directly exploitable, it proved something important:

the fix introduced unintended HTML injection behavior.

Because arbitrary HTML generation can lead to content spoofing and client-side issues, HackerOne reverted the fix and implemented a safer solution.

The report was accepted, and a $500 bounty was awarded.

Strong Takeaways

• Fixes can introduce new vulnerabilities

• Markdown parsers are easy to confuse with malformed input

• HTML Injection doesn't require <script> to be dangerous

• Content spoofing can be just as impactful as XSS

• Always test after a fix, not just before