Stored XSS in model description + workflow bypass lets any logged-in user publish malicious marketplace listings

[sonw-vh]

Describe the bug
A seller can publish (“commercialize”) a model to the public marketplace with a malicious HTML payload in model_desc and with essentially empty/invalid metadata. A server-side moderation/cleanup step appears to try deleting or clearing tasks after creation, but this can be bypassed by dropping the DELETE request and then posting tasks back.

Impact: The result is stored cross-site scripting (XSS) available to all visitors, which can be abused for session hijacking, credential theft, account takeover and large-scale phishing.

CVSS v3.1: 8.7 (High) - Vector: AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N

To Reproduce: (Use Burp Suite or any man-in-the-middle proxy tool)
Prerequisite: If you are using Burp Suite, learn this technique to catch the http response. Turn Intercept on all the time, right-click to the observed http request and choose `Do intercept > Response to this request".

1. Go to https://app.aixblock.io/models-seller/add and fill in random content.

2. Submit a model via POST /api/model_marketplace/commercialize-model (multipart/form-data) with minimal fields and a malicious description, e.g. model_desc=<svg onload=alert('XSS')>; leave many fields empty (docker_image, docker_access_token, model_token, etc.).
   • Example success response: HTTP/2 200 with {"messages":"Commercialize Model Successfully","id":857} and the model status becomes created → visible later as in_marketplace.

3. Intercept the follow-up DELETE /api/model_marketplace_tasks/{id} (which appears intended to remove/sanitize the listing) and drop it.
   • In the observed flow, a DELETE /api/model_marketplace_tasks/857 with body {"task_ids":[]} returned 200 but was ineffective.

4. Immediately send POST /api/model_marketplace_tasks/{id} with a valid task id (e.g., {"task_ids":[2]}) to “add” tasks back.
   • Example success response: HTTP/2 200 with {"detail":"Tasks added successfully"}.

5. Verify with GET /api/model_marketplace/list-sell?page=1&page_size=12.
   • The created items (e.g., ids 857) are returned with status:"in_marketplace", model_source:"HUGGING_FACE", and model_desc containing the injected markup (e.g., encoded <script> or raw SVG depending on view).

6. Open the model page (e.g., GET /marketplace/models/857). The model remains listed despite the malicious description and missing/invalid required fields.

Expected behavior

• Server should reject or quarantine submissions that contain HTML/JS in model_desc (e.g., strip to a safe allowlist or store as plain text) and block SVG/script execution in all render contexts.
• Commercialization should validate business rules (required fields present, trusted sources/tokens, allowed tasks, etc.) before setting status to a publicly visible state.
• Post-creation automation should be atomic and enforced server-side; a client dropping a moderation/cleanup DELETE must not allow the listing to remain public.
• DELETE /api/model_marketplace_tasks/{id} with an empty payload should not succeed or should deterministically revert the model to a non-public state.

Desktop (please complete the following information):

• OS: Windows 10 (reported by User-Agent)
• Browser: Chrome 140
• Version: 140.0.0.0

Smartphone (please complete the following information):

• Device: N/A
• OS: N/A
• Browser: N/A
• Version: N/A

Technical Details:

• Vulnerable Components:

  • frontend/src/components/ModelMarketplace/ModelDetail/Index.tsx:881
  • frontend/src/pages/Project/Settings/ML/ModelDetail/Index.tsx:691
  • frontend/src/pages/Project/Settings/ML/ModelMarketPlace/ModelItem/Index.tsx:35

• Vulnerable Code Pattern:

  <div dangerouslySetInnerHTML={{ __html: item?.model_desc }} />

[tqphu27]

Thank you for your submission.

After reviewing the report and validating the proof-of-concept, we confirm this is a Stored XSS vulnerability caused by rendering model_desc with dangerouslySetInnerHTML.

Based on the program’s rules:

• XSS vulnerabilities fall under Medium severity (CVSS 4.0–6.9).
• Reward tier: $200 cash + 500 worth of AIxBlock tokens & rev-share .

The report is therefore accepted at Medium severity.
We will implement proper server-side sanitization and enforce stricter checks in the commercialization flow.

Please confirm the email address you'd like to use for receiving the reward, and then send an email to contact@aixblock.io from that same address.

[sonw-vh]

Hi @tqphu27,

Thank you for the response. I’d like to respectfully raise a concern regarding the severity and reward assessment.

In Issue #278, the Stored XSS is not only persistent but also combined with a workflow bypass that ensures the malicious payload remains public in the marketplace. This means any visitor, not just editors or testers, is exposed to exploitation, which allows large-scale phishing, session hijacking, and account takeover. In other words, the attack surface is broad, the exploit chain is reliable, and the real-world impact is high.

By contrast, Issue #132 (General Editor XSS) required a crafted error condition inside a limited feature, and the exploit would only trigger if a user actively interacted with that editor. While still serious, its impact radius was narrower and the exploitability lower compared to Issue #278.

However, I noticed that Issue #132 in the past was rewarded at a higher tier, despite being objectively less severe in scope and impact than Issue #278. This raises questions about consistency in how severity and reward tiers are applied.

Could you please clarify how you are aligning your severity model with actual exploitability and impact, and consider whether the reward for Issue #278 should be adjusted accordingly? From my perspective, the marketplace vulnerability represents a higher security risk to your users and platform than the editor issue did.

[tqphu27]

Hi,

Thank you for your detailed report. We’ve reviewed the issue and acknowledge it. Previously, there was a slight oversight in how similar reports were assessed, but for this submission, we have recorded it at Medium severity according to our current program criteria. This will not be changed.

We appreciate your contribution and will take this as a learning point to ensure more consistent assessments in the future. We encourage you to continue submitting any findings.

Best regards,
AIxBlock Security Team

[sonw-vh]

Thank you again, @tqphu27. I've sent an email with the title [Bug bounty] Reward Payment Information for issues/278, via the address dibongaodu123@gmail.com.

[eMKayRa0]

Hey @sonw-vh did you get any reward from them

[sonw-vh]

@eMKayRa0 Yes I was paid within a week, need to send some reminders but they're still cool after all

[eMKayRa0]

I don't know what happened but they haven't paid me and they always says we're in processing

[sonw-vh]

@eMKayRa0 Kindly tell your issue to contact@aixblock.io, they're the guy holding the money, not the devs on github :) they once said my email fell in spam, just send another reminder to them