Description

The Tutor LMS WordPress plugin before 4.0.6 does not enforce per-object ownership checks on its course content type, allowing any user with the instructor role to read the content of private courses belonging to other instructors.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "2.7",
  "pubDate": "2026-08-22T06:16:11.597Z",
  "pubdate": "2026-08-22T06:16:11.597Z",
  "executiveSummary": "An access control vulnerability has been identified in the Tutor LMS WordPress plugin affecting versions prior to 4.0.6. The flaw specifically resides in the handling of the course content type, where the application fails to enforce rigorous per-object ownership checks during retrieval operations. Consequently, the vulnerability permits unauthorized information disclosure regarding private course content.\nThe primary impact of this security issue is the compromise of data confidentiality across multi-instructor environments. An authenticated remote attacker possessing low-privileged access, specifically the instructor role, can leverage this authorization flaw to read sensitive data belonging to private courses owned and managed by other distinct instructors on the same WordPress platform.\nExploitation of this vulnerability requires the attacker to hold an active account with the instructor role, meaning complete unauthenticated exploitation is generally not applicable unless self-registration grants such privileges. The risk implications include unauthorized access to proprietary educational materials, draft curricula, and student interaction data restricted to specific course creators. Remediation requires updating the Tutor LMS plugin to version 4.0.6 or later, where proper object-level authorization checks are presumably enforced.",
  "technicalDetails": "The root cause of the vulnerability stems from an insecure direct object reference (IDOR) or a broken object-level authorization (BOLA) flaw within the Tutor LMS plugin architecture prior to version 4.0.6. When requests are processed for the course content type, the underlying logic validates whether the incoming request originates from a user with the instructor role, but it fundamentally omits a granular, per-object ownership validation step.\nIn a secure implementation, the access control mechanism must verify not only that the requesting principal holds the instructor capability globally, but also that the specific course ID being requested maps directly to the authenticated user ID within the access control lists or database relationships. Because this secondary check is absent, any user authenticated with the instructor role can iterate through or directly query course identifiers to access private courses they do not own.\nThe attack flow begins with the malicious or unauthorized instructor authenticating to the WordPress instance via standard HTTP/HTTPS protocols. The attacker then crafts or intercepts a request targeting the course content type endpoints. By manipulating parameters associated with the course identifier, the attacker issues a request to read private course data. Due to the lack of per-object ownership validation, the application processes the query and returns the private course content in the HTTP response payload.\nThe vulnerable component is the access control logic governing the course custom post type or related REST API/AJAX endpoints within the Tutor LMS plugin. Affected versions include all installations of the Tutor LMS WordPress plugin prior to version 4.0.6. The prerequisites for a successful attack include network access to the WordPress site and valid user credentials possessing the instructor role. No specialized payloads or memory corruption techniques are required, as the vulnerability is purely logical and authorization-based, manifesting as an unauthorized data read operation."
}