Security Advisory - Published 2026-06-07 - SQL injection

Chanjet CRM CVE-2026-11456: SQL Injection Self-Check

CVE-2026-11456 is a newly disclosed SQL injection issue in Chanjet CRM 1.0. The reported affected endpoint is /tools/jxf_dump_systable.php, where the gblOrgID argument is handled unsafely. Public exploit signal exists, so exposed CRM systems should be checked today.

Scope: This guide is for defenders and site owners. It does not include exploit payloads. The goal is to confirm whether you run the affected product, whether the risky endpoint is exposed, and whether logs show suspicious access.

What is affected

  • Product: Chanjet CRM 1.0
  • CVE: CVE-2026-11456
  • Weakness: SQL injection, mapped to CWE-89
  • Endpoint: /tools/jxf_dump_systable.php
  • Parameter: gblOrgID
  • Remote attack surface: yes, if the CRM is reachable from the public internet
  • Known exploited in CISA KEV: no, as of this publication

The vendor response status is unclear from the public disclosure. If you run this CRM in production, treat internet exposure as the immediate risk and isolate first. Wait for a vendor build only after you have reduced access to the vulnerable endpoint.

5-minute exposure check

Step 1: Confirm whether you run Chanjet CRM

Check the application name in the login page, admin dashboard, installation package, or deployment notes. If the CRM is managed by a vendor or hosting provider, ask them to confirm the exact product and version.

Step 2: Find the reported endpoint on the server

On Linux hosting, search your web roots:

find /var/www /www /home -path "*tools/jxf_dump_systable.php" -type f 2>/dev/null

On Windows/IIS hosting, run from the site root:

dir /s jxf_dump_systable.php

If the file exists and the CRM is reachable from the public internet, assume the endpoint needs immediate access control until the vendor confirms a fix.

Step 3: Check public exposure without sending attack input

Use your browser or a safe HTTP status check against the endpoint path only. Do not append test payloads. You only need to know whether the path is reachable. 

curl -I https://example.com/tools/jxf_dump_systable.php

A 200, 302, 401, or 403 response still means the route exists. A 403 is better than 200, but it is not enough if attackers can bypass it through alternate hosts, direct IP access, or misconfigured reverse proxies.

Step 4: Review web logs for access to the endpoint

Search Nginx or Apache logs:

grep -R "jxf_dump_systable.php" /var/log/nginx /var/log/apache2 /usr/local/apache/logs 2>/dev/null
grep -R "gblOrgID" /var/log/nginx /var/log/apache2 /usr/local/apache/logs 2>/dev/null

If you find requests from unknown IPs, scanners, or countries that should not access your CRM, preserve the logs before making changes. You may need them to understand whether this was only scanning or a real compromise.

Step 5: Check for database and account anomalies

  • Unexpected CRM administrator accounts
  • New integrations, API tokens, or export jobs you did not create
  • Unusual database read volume or slow-query spikes near suspicious requests
  • CRM records exported, modified, or deleted outside normal business hours
  • New files in the CRM web root after the first suspicious request

Immediate mitigation

  1. Restrict CRM access. Put the CRM behind VPN, Zero Trust, or an IP allowlist.
  2. Block the endpoint if it is not required. Deny access to /tools/jxf_dump_systable.php at Nginx, Apache, IIS, or WAF level.
  3. Enable SQL injection WAF rules. This should be defense in depth, not the only control.
  4. Disable direct IP access. Make sure the CRM cannot be reached by bypassing the normal hostname.
  5. Preserve evidence. Copy web logs, database logs, and access logs before cleanup.
  6. Rotate credentials if logs show suspicious access. Start with CRM admin users and database credentials.
  7. Ask the vendor for a fixed build. Keep a written record of the version they say is safe.

Example Nginx temporary block

If you confirm the endpoint is not needed for normal business workflows, block it while you wait for vendor guidance: 

location = /tools/jxf_dump_systable.php {
    deny all;
    return 403;
}

If your CRM is behind Apache, IIS, Cloudflare, or another WAF, create the same exact-path deny rule there. Test after applying the rule.

When to treat this as an incident

Treat it as a possible incident, not just a patch task, if any of these are true:

  • The endpoint was publicly reachable before today.
  • Logs show requests containing gblOrgID from unknown IP addresses.
  • CRM data changed unexpectedly after suspicious requests.
  • New CRM admin users, API tokens, or exports appeared.
  • You cannot prove whether the CRM was exposed.

References

Related Ping7 checks

Need help checking it?

Ping7 can run a defensive exposure check and log review for CRM, WordPress, cPanel, and small business web stacks. The useful paid offer here is a fixed $99 compromise check: endpoint exposure, log timeline, account review, and a written cleanup plan. Start from Ping7 CVE repair.