Piranha CMS version 12.0, which was released approximately halfway through 2025, has a stored cross-site scripting (XSS) vulnerability (CVE-2025-57692). An authenticated user (typically a content editor or administrator) can exploit this vulnerability to insert malicious JavaScript code through the Text content block of any Standard or Standard Archive page. After the page content block is saved, the malicious JavaScript code will execute in the browser of anyone who views, previews, or edits that particular page, including any administrator with higher privileges than the original attacker.
On September 26, 2025, security researcher Chidubem Chukwu (also known as Terminal Venom) made a public disclosure of the vulnerability, including a clean proof-of-concept and complete reproduction steps. There was no publicly available patch at the time of this disclosure, and no patch for the vulnerability existed in version 12.0 as of the time of the disclosure.
Why You Should Care
1. Stored XSS means that the malicious code will live on the server and execute as if it were the authenticated user that visited the site.
2. This could cause problems in Piranha CMS by:
a. Hijacking a session (stealing admin cookies)
b. Stealing local/session storage (ex. auth tokens)
c. Keylogging, hijacking forms, and phishing overlays.
d. Performing a CSRF attack on other users.
e. Defacing the site or redirecting visitors to a malicious website.
3. Since the payload will execute immediately on saving the edited content, if any of the editor accounts were compromised, the whole site would be backdoored for all visitors.
How the Attack Works
1. Log into the admin panel (/manager/login).
2. Go to Pages → Add Page → Choose Standard Page or Standard Archive.
3. Give it any title (e.g., "Test Page").
4. Click the [+] button → Select Text block under Content.
5. Paste one of the payloads directly into the rich text editor.
6. Click Save → The payload executes right away (and will re-execute for anyone who later views/previews the page).
Real-World Impact
1. An attacker with even low-privileged access (e.g., a content contributor) can compromise site administrators.
2. In multi-tenant or agency-managed sites, one tenant could target others.
3. No portion of the client/server/CSP seems to affect the ability for any of these payloads to work correctly on v12.0.
Mitigation & Recommendations (as of Feb 2026)
1. Immediate Workaround
a. Turn off the Text block for non-trusted users and limit who can add/edit pages
b. Manually validate that the content is free of any malicious scripts before saving it. This could be done through middleware or hooks that would sanitize every piece of data prior to saving it.
c. Create and implement a strong content security policy (CSP) by prohibiting the use of inline scripts (set the CSP to script-src 'self' - Do not use 'unsafe-inline')
2. Long Term
a. Monitor the official GitHub repo until a patched version is released and made available to the public
b. Consider upgrading to the newest possible version of the software after a patch has been applied (refer to the release notes for CVE-2025-57692)
c. Deploy a Web Application Firewall such as Cloudflare or ModSecurity with a configuration of XSS rules
d. Enforce the principle of least privilege by not allowing untrusted users to edit any website pages.
3. Identifying risk factors and potential indicators of compromise
a. Reviewing web page content for undesired content (e.g., onerror=, ontoggle=, data:text/html;base64, <iframe src="data,)
b. Reviewing browser console log for unexpected alert() calls or unexpected traffic.
This is a classic example of why even mature CMS platforms need continuous security scrutiny, especially when rich text editors are involved. If you're running Piranha CMS 12.0 in production, treat this as high priority.
Source: Exploit DB
© 2016 - 2026 Red Secure Tech Ltd. Registered in England and Wales under Company Number: 15581067