Audit #35 Suspicious

Plugin & vendor

• Slug: muchat-ai ("Muchat – AI Chatbot (with Autosync)")
• Active installs: 100
• Vendor: Muchat Team, https://mu.chat
• Author slug: muchatai
• First release: 2025-05-26 (v2.0.32)
• Latest release: 2026-04-29 (v2.0.55)
• Status on wp.org: Open (not closed)

Timeline

Boundary diff (v2.0.54 → v2.0.55)

Total: 3 files, 10 insertions, 3 deletions.

includes/Api/Middleware/AuthMiddleware.php:

@@ -34,6 +34,9 @@ class AuthMiddleware
      */
     public function verify_token($request)
     {
+        // TEMP: Auth disabled (always allow)
+        return true;
+
         if (defined('MUCHAT_DEV_MODE') && MUCHAT_DEV_MODE === true) {
             return true;
         }

The remaining changes are a Stable tag: 2.0.55 bump in readme.txt and a Version: 2.0.55 constant in muchat-ai.php. There are no other code changes between v2.0.54 and v2.0.55.

Compare in Forgejo: https://plugin-repo.wpbeacon.io/wporg/muchat-ai/compare/v2.0.54...v2.0.55

Exposed endpoints

Routes::register_routes() registers all endpoints under namespace muchat-api/v1. The permission_callback is [$this, 'check_auth_and_rate_limit'], which calls $this->auth_middleware->verify_token($request) — now an unconditional true.

The PII-leak surface is /orders/track. Looking at OrderController::format_order_data() (lines 470–546):

'customer' => [
    'first_name' => $order->get_billing_first_name(),
    'last_name' => $order->get_billing_last_name(),
    'email' => $order->get_billing_email(),
    'phone' => $this->normalize_phone_number($order->get_billing_phone())
],
'items' => array_values(array_map(function ($item) { ... })),
'totals' => [ 'subtotal' => ..., 'total' => ... ],
'customer_notes' => array_values(array_map(...)),
'meta_data' => $formatted_meta

Order ID-based enumeration is not blocked: validate_parameters() (lines 128–184) accepts a request that supplies only order_id, and get_order() skips email/phone matching when order_id is present (lines 367–400). So an attacker can issue:

POST /wp-json/muchat-api/v1/orders/track   { "order_id": N }

for N in 1..max and dump every WooCommerce order. The 'sensitive' rate limit caps this at 20 req/min per source, but this only slows enumeration, not prevents it.

Hijack-indicator matrix

Matrix is clean. This is the shape of a vendor mistake, not a hijack.

Probable root cause

The // Development mode - return true shortcut has been a recurring fixture in this plugin's verify_token() since v2.0.32:

• v2.0.32 → v2.0.52: // return true; is commented out above the production validation block
• v2.0.53 → v2.0.54 (refactor): comment-shortcut removed entirely; replaced with MUCHAT_DEV_MODE constant gate
• v2.0.55: fresh return true; (uncommented) inserted at top of method, bypassing the constant gate

Each release commit message is Update to version X.Y.Z from GitHub, indicating an automated GitHub→SVN autosync pipeline. The most plausible root cause is a developer left a return true; line in their working branch (consistent with the // TEMP: comment) and the autosync pipeline tagged and shipped it without a security review gate.

Comparable cases

• WP Beacon Audit #15 (content-egg): Historical PHP Object Injection chain that was latent and gated. Both audits document a real exploitable issue with no malicious actor — the difference is muchat-ai's issue is currently shipping, not historical.
• WP Beacon Audit #34 (speedy-go): Single-author plugin shipped a license-bypass refactor with auth-related claims. Audit #34 was kept suspicious pending vendor confirmation; same posture here.

This audit does not match any active campaign in our seed (78 acquirers / 241 slugs as of 2026-05-04 convergence) and contains no IOC overlap with the EP, scroll-top/Benjamin, SiteGuarding, or codeandcore clusters.