TL;DR

A broken access control vulnerability in the Order Splitter for WooCommerce plugin (versions ≤ 5.3.5; patched in 5.3.6, CVE-2025-12075) allows any authenticated user with Subscriber privileges to retrieve order information belonging to other customers. The technical CVSS equivalent is 4.3 (low), but because order data often contains personal information, store operators should treat this with urgency.

If you run WooCommerce and use this plugin:

• Mettez à jour le plugin à 5.3.6 13. ou ultérieure immédiatement.
• If you cannot update right away: disable the plugin, restrict access to the vulnerable endpoints with your firewall, or temporarily reduce Subscriber capabilities.
• Use a Web Application Firewall (WAF) or equivalent virtual‑patching to block exploit attempts while you update.
• Preserve logs, audit access, notify affected customers if sensitive personal or payment details were exposed, and rotate any keys or credentials found in exposed data.

This article explains the issue, realistic exploitation scenarios, detection guidance, urgent mitigations, incident response steps, and longer‑term hardening from the perspective of an experienced Hong Kong security practitioner.

Background — What happened

A researcher found a missing authorization check in Order Splitter for WooCommerce. The plugin exposes endpoints used to return order information, but in some cases the code verified only that the caller was authenticated — not that the caller owned the order or had permission to view it. As a result, any authenticated account with the Subscriber role could query vulnerable endpoints and receive order data for other customers.

The bug was fixed in plugin version 5.3.6. The issue is classified as Broken Access Control (OWASP) and is tracked as CVE-2025-12075. Exploitation does not grant administrator privileges or execute server commands, but it does allow data exposure — names, addresses, order items and potentially order metadata.

Why this matters even if severity is “low”

• Subscriber accounts are easy to obtain (site registration or low‑value purchases). Attackers can create many accounts to scale probes.
• Order information often contains personal data useful for fraud, social engineering, or doxxing.
• Order metadata can sometimes include API keys or tokens; if so, exposure can lead to greater compromise.
• Attackers can combine exposed order data with other leaks to increase impact.

Do not dismiss “low” CVSS scores. The practical business and privacy impact may be significant; respond promptly.

Résumé technique (non-exploitant)

• A REST or admin‑AJAX endpoint that returns order data lacked an authorization check enforcing ownership or a capability.
• The endpoint returned data based on an order identifier supplied in the request (order ID or order key).
• The plugin only verified that the requester was authenticated, not that the requester owned the order or had permission to read other users’ orders.
• Any authenticated Subscriber account could retrieve orders not belonging to that user.

No exploit code is published here. The developer followed responsible disclosure and released a patch in 5.3.6. The root cause is a missing permission check (e.g., no permission_callback or current_user_can() on the route).

Scénarios d'attaque réalistes

1. Malicious account enumeration: Attacker creates many Subscriber accounts and automates queries to enumerate valid order IDs and harvest order data.
2. Ingénierie sociale ciblée : Attacker finds a high‑value order and uses shipping/name details to craft convincing phishing or impersonation attempts.
3. Data resale: Aggregated order lists can be sold for marketing abuse or fraud.
4. Chaining with other issues: If order meta contains secrets from another integration, those secrets could be abused to pivot to other systems.

How to detect if your site was probed or exploited

Look for these indicators in logs and monitoring systems:

• Webserver, WAF, or access logs showing repeated requests to routes containing strings like order-splitter ou split-order.
• Multiple GET/POST requests from the same IP or small IP range to the same endpoint with varying order IDs.
• Increased REST or admin‑ajax activity from Subscriber accounts.
• Access to orders where the order ID does not match the session user.
• Plugin or application logs that record unexpected order reads.

If you observe suspicious activity: export and preserve logs, block offending IPs temporarily, and proceed with incident response steps below.

Immediate actions — 0–24 hours

1. Update to 5.3.6 — this is the canonical fix. Apply via dashboard or management tooling.
2. If you cannot update immediately, apply one or more temporary mitigations:
   • Deactivate the plugin across affected sites until patched.
   • Use your WAF or reverse proxy to block requests to the vulnerable endpoints (virtual patch).
   • Temporarily restrict Subscriber capabilities or disable public account registration.
   • Harden REST API access for sensitive routes (limit to owners/admins only).
3. Préserver les journaux et les preuves. Capture webserver, WAF and application logs for the last 90 days where available.
4. Notify internal teams. Inform customer support, legal and privacy teams so they can prepare communications if required.

Temporary code mitigations (if you cannot disable the plugin)

If the plugin must remain active, add a permission check on requests to the risky endpoints. Test on staging before production. Example patterns are shown below for illustration only — adapt to the real routes and parameters of your site.

Option A — Enforce ownership on REST endpoints

<?php
// Example: force permission checks on a REST endpoint
add_filter( 'rest_pre_dispatch', function( $result, $server, $request ) {
    $route = $request->get_route();

    // Adjust the route check to match the plugin's endpoint path.
    if ( strpos( $route, '/order-splitter/v1/orders' ) !== false ) {
        $current_user = wp_get_current_user();
        if ( ! $current_user || ! $current_user->ID ) {
            return new WP_Error( 'rest_forbidden', 'Authentication required.', array( 'status' => 401 ) );
        }

        $order_id = $request->get_param( 'order_id' ); // plugin-specific param
        if ( $order_id ) {
            $order = wc_get_order( intval( $order_id ) );
            if ( $order && $order->get_user_id() !== $current_user->ID && ! current_user_can( 'manage_woocommerce' ) ) {
                return new WP_Error( 'rest_forbidden', 'You are not allowed to view this order.', array( 'status' => 403 ) );
            }
        }
    }

    return $result;
}, 10, 3 );
?>

Option B — Unregister the route until patched

<?php
add_action( 'rest_api_init', function() {
    // Replace with actual route names registered by the plugin.
    if ( isset( $GLOBALS['wp_rest_server'] ) ) {
        $routes = $GLOBALS['wp_rest_server']->get_routes();
        if ( isset( $routes['/order-splitter/v1/orders'] ) ) {
            unset( $routes['/order-splitter/v1/orders'] );
            // Note: This is illustrative. Persisting route changes requires robust tests.
        }
    }
}, 5 );
?>

Important: these snippets are examples only. Validate route names and parameters on staging. If unsure, disable the plugin or apply WAF rules instead.

Mitigation and detection (operational guidance)

Use layered controls while you patch:

• Apply WAF rules to block known endpoint patterns and requests containing order identifiers originating from low‑privileged sessions.
• Enable request rate limiting per user and per IP to reduce enumeration speed.
• Monitor for sequential order ID access patterns and rapid repeated accesses by Subscriber accounts.
• Consolidate logs for easier forensic analysis (webserver, application, and WAF logs).

How to validate patch effectiveness

1. Test the updated plugin on staging before production.
2. Attempt authorized and unauthorized order retrievals with test Subscriber and Administrator accounts.
3. Confirm that Subscribers can only retrieve their own orders and that other orders return 403 or similar forbidden responses.
4. Run internal scans to ensure order enumeration is blocked and check WAF logs for no successful accesses post‑patch.
5. If the patch does not prevent unauthorized access, remove the plugin and contact the plugin maintainer immediately.

Liste de contrôle de réponse aux incidents (si vous soupçonnez une exploitation)

1. Update or disable the plugin immediately.
2. Apply firewall/WAF blocking rules for the vulnerable endpoints.
3. Preserve logs and snapshot the environment (database + filesystem) for investigation.
4. Identify scope: collect order IDs, timestamps, IPs, and the accounts that made the requests.
5. Contain: block offending IPs, rate limit, and reset exposed API tokens or webhooks.
6. Remediate: patch or remove the plugin; rotate credentials if sensitive data was exposed.
7. Notify affected customers if PII was exposed, following local breach notification laws.
8. Post‑incident: perform root cause analysis and update development practices to reduce recurrence.

Prevention: secure plugin development and hardening checklist

• Require REST permission callbacks for all registered routes; enforce granular capability or ownership checks.
• Always verify resource ownership before returning user‑specific data like orders or addresses.
• Use nonces for AJAX endpoints and validate them for sensitive actions.
• Follow principle of least privilege for roles; explicitly restrict what Subscribers may access.
• Include authorization tests in unit and integration test suites to simulate low‑privilege access attempts.
• Avoid storing secrets in order metadata; if unavoidable, encrypt or store them externally with strict access controls.
• Maintain a rapid patch release process so emergency fixes can be applied quickly.

Monitoring & logging recommendations for store operators

• Aggregate logs (webserver, WP debug, WAF) into a central store or SIEM for review.
• Monitor REST API access volume from Subscriber accounts and detect sequential order ID access patterns.
• Set alerts for multiple order requests per user within a short window and for order access from unusual geolocations.
• Export and analyze logs regularly depending on transaction volume.

Communication with customers (if exposure occurred)

When notifying customers be factual and concise. Recommended elements:

• Timeline of discovery and containment actions taken.
• What types of data may have been exposed.
• Practical advice for customers to detect misuse and who to contact for support.
• Any remediation offered, where appropriate, and record of notifications for compliance.

Long term: risk management and vendor/plugin governance

• Maintain an inventory of plugins and their maintainers; prioritise updates for plugins that handle sensitive data.
• Implement plugin approval and security scanning before installing on production.
• Subscribe to vendor or public vulnerability feeds to receive timely alerts.
• Keep staging and production separate and run security scans on staging regularly.
• Consider contractual security SLAs with vendors supplying critical plugins.

Exemples de modèles de règles WAF (conceptuels)

Conceptual rule ideas — adapt and test before applying:

• Block requests that target known plugin REST/AJAX route names and include an identifiant_de_commande parameter when originating from low‑privilege sessions.
• Detect and block sequential enumeration patterns (rapid sequential order_id access).
• Rate limit REST/AJAX requests per user and per IP (e.g., 10/min conservative starting point).
• Throttle or geo‑block traffic from regions that do not normally interact with your store.

What to do after everything is patched and calm

• Remove emergency rate limits only after confirming no residual scanning activity.
• Audit user accounts; remove suspicious or mass‑created Subscriber accounts.
• Review order metadata for stored secrets and clean or secure as needed.
• Add the plugin to regular update monitoring or remove it if not essential.
• Schedule a security review for custom code that handles orders or REST endpoints.

Questions fréquemment posées

Q: If I updated right away, do I still need to do anything?

A: Update is the primary remediation. Also review logs for suspicious access prior to the patch. If you find suspicious activity, follow the incident response checklist.

Q: Does this affect other WooCommerce plugins?

A: This issue is specific to Order Splitter ≤ 5.3.5. However, missing authorization bugs can exist in any plugin. Treat plugins that expose order or customer data as higher risk and audit them.

Q: Will disabling Subscribers fix the problem?

A: Preventing account creation reduces the risk of weaponised Subscriber accounts, but it may not be practical. The correct fix is to patch the plugin; in the meantime reduce account registration risk (CAPTCHA, email verification) and apply WAF rules.

Derniers mots d'un expert en sécurité de Hong Kong

Broken access control is a common, preventable class of bug. Sites that expose orders and customer data deserve particular attention because the business and privacy impact can be substantial even when the technical severity is labelled “low”.

Practical steps: prioritise the plugin update, preserve logs, apply temporary firewall rules if needed, review order metadata for secrets, and harden development practices to ensure authorization checks are enforced everywhere. Measured and fast responses reduce customer impact and protect your brand.

— Expert en sécurité de Hong Kong