CSRF Vulnerability in SeaCMS 13.3 Enables Admin Password Change
CSRF Vulnerability in SeaCMS 13.3 Enables Admin Password Change
Vulnerability Description
A Cross-Site Request Forgery (CSRF) vulnerability exists in SeaCMS 13.3 that allows an attacker to change an administrator’s password without consent. By tricking a logged-in admin into visiting a crafted page, a hidden form auto-submits to the admin management endpoint, resulting in unauthorized password changes and potential account takeover.
Affected Product
- Product: SeaCMS
- Version: 13.3
- Component: Admin management (
/1j2jdm/admin_manager.php?action=save&id=1) - CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Technical Details
The environment was set up locally using PHPStudy, accessing the site at http://seacms/1j2jdm. After logging into the admin panel and navigating to the administrator edit page (target user password from 111111), a request to change the password was captured for analysis.
Admin edit interface and captured request:


Generating a CSRF PoC from the captured request:

Proof of Concept (PoC)
Save the following as csrf3.html. When a logged-in admin visits the page, the form auto-submits to change the administrator’s password to 111111 without interaction.
1 | |
Open the PoC in Edge while logged into SeaCMS as admin and submit:

The request succeeds and the user’s password is changed:

Impact
- Type: Cross-Site Request Forgery (CSRF)
- Who is impacted: Any authenticated administrator who can be lured to visit an attacker-controlled page
- Consequences:
- Unauthorized password change and administrator account takeover
- Further compromise of the application by performing privileged actions
Remediation
To mitigate this issue, SeaCMS should:
- Enforce strong CSRF protections (unpredictable per-session/per-request tokens validated server-side)
- Validate
Origin/Refererheaders for state-changing requests - Require re-authentication (current password) for sensitive operations like password changes
- Apply SameSite cookies and restrict cross-site requests where appropriate
Timeline
- 2025-10-05: Vulnerability documented and PoC prepared
- [Future Date]: Vendor notified
- [Future Date]: CVE requested/assigned