📄 ERPNext 15.67.0 / Frappe 15.72.4 Cross Site Scripting

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