# 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.