Description

The WC Vendors WordPress plugin before 2.7.2.1 does not have CSRF protection on some of its front-end order shipment status actions, which could allow attackers to make a logged-in vendor change the shipment status of their own orders via a crafted request.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-02T06:17:19.180Z",
  "pubdate": "2026-09-02T06:17:19.180Z",
  "executiveSummary": "The WC Vendors WordPress plugin is vulnerable to Cross-Site Request Forgery (CSRF) due to a failure to implement anti-CSRF tokens on front-end order shipment status modification endpoints. This vulnerability permits a remote, unauthenticated attacker to induce a logged-in vendor into performing unauthorized state-changing actions on their own orders. By tricking a victim into visiting a malicious URI or interacting with a crafted web page, an attacker can force the application to execute shipment status changes without the user's consent or knowledge. The impact is primarily limited to order management integrity, potentially disrupting business workflows or creating inconsistencies in shipment tracking data. Successful exploitation requires the victim to have an active administrative or vendor-level session within the WordPress environment while interacting with the attacker-controlled content.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient security design of the order shipment status update functionality within the WC Vendors plugin. Specifically, the affected controller actions handling these requests do not perform cryptographically secure nonce verification, nor do they enforce any CSRF-mitigation mechanisms to validate the origin or intent of the HTTP request.\nBecause the plugin processes these requests without verifying that the request was initiated through an authorized UI element containing a valid nonce, it is susceptible to state-injection attacks. An attacker can craft a malicious HTTP request (GET or POST) targeting the specific shipment status modification endpoint. When a logged-in vendor visits a third-party site containing an embedded malicious script, an auto-submitting form, or a crafted image tag pointing to this endpoint, the browser will automatically include the victim's session cookies in the request.\nThe server-side application processes the request, associates it with the victim's authenticated session, and updates the shipment status of an order as specified in the attacker's parameters. This bypasses the intended authorization workflow because the application assumes that any request originating from the authenticated session is legitimate.\nAffected versions: WC Vendors plugin before 2.7.2.1.\nAuthentication: Required (Victim must be authenticated).\nPrivilege: Vendor or user with order management capabilities.\nImpact: Unauthorized modification of order shipment statuses. While the scope is restricted to the vendor's own orders, this allows for the malicious manipulation of transaction records, potential trigger of unauthorized email notifications to customers, and the compromise of operational data integrity within the store management interface. Since the action is performed via the victim's session, the server-side logs will correctly attribute the action to the legitimate user, complicating incident response and forensic analysis."
}