Description

The MasterStudy LMS WordPress Plugin WordPress plugin before 3.7.42 does not correctly restrict access to order information, allowing any user with the instructor role to read other users' order billing details, including name, email address, phone number and postal address, by enumerating order IDs.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "2.7",
  "pubDate": "2026-08-29T06:17:58.587Z",
  "pubdate": "2026-08-29T06:17:58.587Z",
  "executiveSummary": "The MasterStudy LMS WordPress plugin before version 3.7.42 is susceptible to an Insecure Direct Object Reference (IDOR) vulnerability. This flaw exists due to improper access control validation within the plugin's order management functionality, which fails to verify if the requesting user has the appropriate authorization to access specific order records. An authenticated user possessing the 'instructor' role can bypass intended access restrictions and systematically exfiltrate sensitive customer billing information, including names, email addresses, phone numbers, and physical postal addresses. By manipulating order ID parameters in requests, attackers can enumerate and retrieve private order data across the entire platform. The vulnerability poses a significant privacy and data security risk, as it permits unauthorized access to personally identifiable information (PII). Given that exploitation requires only an authenticated instructor account, the attack surface is relatively accessible for any user with basic elevated privileges on the platform. Immediate remediation is required to implement robust authorization checks on all server-side order retrieval endpoints to prevent unauthorized data exposure.",
  "technicalDetails": "The root cause of this vulnerability is a failure to implement server-side access control checks within the MasterStudy LMS plugin when processing requests for order billing details. While the system is designed to segment data access based on user roles, the specific endpoints responsible for retrieving order information do not validate whether the authenticated user has legitimate ownership or authorization to view the requested record.\nThe vulnerability manifests as an Insecure Direct Object Reference (IDOR) where the backend logic trusts the user-supplied order ID parameter without cross-referencing the requestor's permissions against the target data. An attacker authenticated with an instructor-level account can initiate requests to order retrieval endpoints. By identifying the sequential or predictable nature of these order IDs, an attacker can utilize automated scripts or simple iterative requests to traverse and scrape billing details belonging to other users.\nThe attack flow proceeds as follows: First, the attacker identifies an endpoint used by the plugin to fetch order metadata. Second, the attacker captures an authorized request for an order they are legitimately allowed to see. Third, the attacker systematically modifies the integer-based order ID parameter in the request payload. Because the application logic lacks a 'check_user_permission' or ownership verification step for the requested ID, the server processes the request and returns the sensitive PII associated with the arbitrary ID. This allows for mass exfiltration of billing information without triggering security alerts or requiring administrative privileges beyond the standard instructor role.\nThe affected components are the order management modules within MasterStudy LMS versions prior to 3.7.42. The exploitation occurs over the network via standard HTTP/HTTPS requests that the plugin exposes for backend order management. Post-exploitation, the attacker gains full access to customer billing details, which significantly increases the risk of downstream attacks such as social engineering, identity theft, or unauthorized data dissemination. The lack of input validation or authorization enforcement allows an instructor to act as a malicious crawler, undermining the confidentiality of the LMS user database. The vulnerability remains effective as long as the application relies on client-side or implicit assumptions of authorization rather than explicit verification for every object access attempt."
}