magento

// TL;DR


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.

magento-htmli

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.

magento-xfs

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.

magento-xss

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 / a frame-ancestors Content-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!

Anas Mahmood

Web & API penetration tester and bug bounty hunter. I write up the bugs I find and the methods that found them.

Leave a Reply

Your email address will not be published. Required fields are marked *