
// TL;DR
I found three related client-side issues on Magento’s Marketplace, all stemming from the same unsanitised search parameter: HTML injection, cross-frame scripting (a clickjacking/UI-redressing class issue), and reflected XSS. A single crafted search URL was enough to inject arbitrary HTML and execute script in the page’s context. Reported through Bugcrowd, fixed by Magento, and acknowledged in their Hall of Fame.
The vulnerable endpoint
The issues lived in the search functionality of Magento’s Marketplace. The search query parameter was reflected into the results page without proper sanitisation or output encoding — the single defect that made all three findings possible.
A crafted search URL of this shape triggered the behaviour:
https://marketplace.magento.com/catalogsearch/result/?cat=8&q="><script>alert("Hi");</script>
The q parameter — the user’s search term — was echoed back into the page, and because it wasn’t encoded for its output context, the browser parsed the injected markup as HTML rather than displaying it as text.
HTML Injection
HTML injection occurs when an application lets a user control an input that is then rendered into a page, allowing arbitrary HTML to be injected into the output.
Here, supplying HTML in the q parameter caused that markup to be rendered as part of the results page. On its own, HTML injection lets an attacker alter how the page looks and reads — inserting fake content, forms, or links under the trusted marketplace.magento.com domain, which is a strong basis for phishing and content spoofing.

Cross-Frame Scripting (XFS)
The page could also be framed, which opened the door to cross-frame scripting / clickjacking (UI redressing). When a page can be loaded inside an attacker-controlled <iframe> without framing protections, an attacker can overlay or disguise it so that a victim’s clicks land on elements they didn’t intend to interact with.
Combined with the injection above, this increases the impact: an attacker can not only alter page content but also manipulate how the victim interacts with it.

Reflected XSS
Because the injected HTML could include a <script> element (or other script-bearing markup) that executed, the same flaw was also a reflected (non-persistent) XSS. The payload is delivered in the request, reflected straight into the response, and executed by the victim’s browser:
...?cat=8&q="><script>alert("Hi");</script>
The "> closes whatever attribute/tag the value was being placed into, and the <script> block that follows runs in Magento’s origin. Reflected XSS like this is typically delivered by tricking a victim into opening a crafted link.

The common root cause
All three findings trace back to one mistake: user input reflected into the page without context-aware output encoding. HTML injection, XFS exposure, and reflected XSS are three different consequences of the same missing control. Fix the encoding (and add framing protections), and all three close together:
- Encode the search term for its HTML context before reflecting it.
- Validate input as defence in depth.
- Send framing protections —
X-Frame-Options/ aframe-ancestorsContent-Security-Policy — to prevent the page being embedded in hostile frames.
Report & recognition
I reported the vulnerabilities to Magento through Bugcrowd. Their team validated the findings, triaged as P2, fixed the issues, and listed me in the Magento Hall of Fame. A few months later, the report was also rewarded with a $250 bounty.
Thanks for reading — happy hacking!
Leave a Reply