A stored cross-site scripting (XSS) vulnerability in the blog post feature of ERPNEXT v15.67.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the content field.# CVE-2025-56379 — Stored Cross-Site Scripting (XSS) in ERPNext 15.67.0 / Frappe 15.72.4
📌 **Summary**
A stored Cross‑Site Scripting (XSS) vulnerability exists in the Blog module of ERPNext (v15.67.0) / Frappe (v15.72.4). An authenticated user who can create or edit blog posts may inject crafted HTML/JavaScript into the `content` field. That payload is stored and will execute in the browser of any user who views the blog-post page, allowing arbitrary script execution, information disclosure, denial of service, and other client-side attacks. Admin privileges are **not** strictly required — any user with permission to create/edit blog posts may exploit it.
---
## 🛠 Technical Details
* **Vulnerability Type:** Stored Cross‑Site Scripting (CWE‑79)
* **Affected Product(s):** ERPNext / Frappe
* **Affected Versions (reported):**
* Frappe — **15.72.4**
* ERPNext — **15.67.0**
* **Affected Component:** ERPNext Blog Module
* **Route:** `/app/blog-post/<blog_name>`
* **Vulnerable Field:** `content` (blog post creation / edit form)
* **Attack Type:** Remote (requires authentication and blog-post creation privileges)
* **Severity:** High (client-side code execution, data theft, session hijacking possibility)
* **Estimated CVSS v3.1 Score:** **7.5 (High)** — *estimate; authoritative assigner should compute final score*
* **Status:** Not fixed (as reported)
* **Discovered by:** Mohammed Aloli
* **Date Discovered:** Not specified
* **CVE ID:** **CVE-2025-56379**
---
## 🚀 Proof of Concept (PoC) — Stored XSS
> **Only test in authorized / lab environments. Do NOT run against systems you do not own or have explicit permission to test.**
**Steps to reproduce**
1. Authenticate to the target ERPNext instance as a user with permission to create/edit blog posts.
2. Navigate to blog-post creation/edit route for a blog, e.g.:
```
/app/blog-post/<blog_name>
```
<img width="709" height="829" alt="image" src="https://github.com/user-attachments/assets/f3b4a0a0-5726-4601-a4bb-62f113f7244f" />
3. In the **content** field insert the payload and save the post:
```html
<img src=x onerror=alert("xss")>
```
4. Open the blog-post page (`/app/blog-post/<blog_name>`) as another user (or same user in a fresh browser). The payload executes in the viewer’s browser (here, `alert("xss")`).
**Notes:** the PoC uses a simple `onerror` alert. Real attacks could exfiltrate cookies, perform actions on behalf of the victim, or load remote scripts (subject to CSP and cookie flags).
---
## 🧪 Exploitation Scenario
An attacker who can create or edit blog posts stores a malicious script in the `content` field. Any user — including administrators — who visits the blog-post page will execute the attacker's script in their browser context. Consequences include session theft (if cookies are not `HttpOnly`), forced actions in the victim’s session, data exfiltration from pages the attacker can access, UI redress attacks, and potential DoS of client-side components.
---
## 🔐 Mitigation Recommendations
1. **Sanitize/encode stored HTML** — Sanitize the `content` HTML on input and/or escape on output using a secure HTML sanitizer that removes dangerous tags and attributes (remove `on*` attributes, `javascript:` URIs, `<script>`, `<iframe>`, etc.). Prefer well‑maintained libraries.
2. **Whitelist (allowlist) HTML** — Only permit a minimal set of safe tags/attributes required for formatting (e.g., `<p>`, `<b>`, `<i>`, `<ul>`, `<li>`, `<a href>` with strict href validation). Disallow inline event handlers.
3. **Content Security Policy (CSP)** — Deploy a strict CSP to reduce the impact of XSS (restrict script sources, avoid `'unsafe-inline'`, use nonce/hash-based script allowances where necessary).
4. **Server-side enforcement** — Enforce sanitization on the server before storing content (don’t rely solely on client-side checks).
5. **HttpOnly & SameSite cookies** — Ensure session cookies are `HttpOnly` and set appropriate `SameSite` attributes to reduce cookie theft and CSRF-like risks.
6. **Least privilege for content creation** — Limit who can create/edit blog posts and audit those permissions.
7. **Contextual encoding** — Encode user-supplied content correctly when inserted into HTML attributes, JS contexts, or URLs.
8. **Reject unsafe input** — Consider rejecting or stripping dangerous attributes and tags at save time, logging blocked attempts.
9. **Testing & monitoring** — Add unit/integration tests to assert sanitization behavior. Monitor logs for suspicious post creation/editing activity.
10. **Patch release** — Developers should update the sanitization pipeline in Frappe/ERPNext and publish a security update; operators should apply updates promptly.
---
## 🔗 References
* ERPNext GitHub: `https://github.com/frappe/erpnext`
* Frappe Framework GitHub: `https://github.com/frappe/frappe`
* OWASP XSS Prevention Cheat Sheet: `https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html`
* NVD / CVE database — check for **CVE-2025-56379** entry when published
---
## 🙏 Acknowledgments
author : Mohammed Aloli
---
## 📢 Disclaimer
This write-up is intended for defensive, remediation, and awareness purposes only. Do **not** attempt to exploit this vulnerability against systems you do not own or have explicit authorization to test. If you operate ERPNext/Frappe, apply fixes, enforce sanitization, and follow the mitigation guidance above.
Log in to view the POC file snapshot cached by Shenlong Bot
Log in to view