CVE-2026-82848 in Masteriyo LMS Plugin
Summary
by MITRE • 09/09/2026
The Masteriyo LMS WordPress plugin before 3.4.0 does not perform any authorization check before returning a course enrolment record over its REST API, allowing unauthenticated users to read any learner's enrolment status, timestamps and course-progress data by walking sequential record identifiers. A related gap lets any enrolled user retrieve other learners' enrolment records as well.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Masteriyo LMS WordPress plugin versions prior to 3.4.0 represents a critical failure in access control mechanisms within the application's REST API implementation. This flaw specifically affects how course enrollment data is retrieved and served to clients interacting with the platform. The core technical issue lies in the absence of proper authorization checks before the system processes requests for individual course enrollment records. In a secure architecture, any request accessing sensitive user-specific information must verify that the requester has explicit permission to view that specific resource. However, in this vulnerable version, the API endpoint responsible for returning enrollment details does not validate whether the authenticated user is the owner of the data or an administrator with appropriate privileges. This oversight creates a direct path for unauthorized data access, fundamentally breaking the principle of least privilege and failing to enforce role-based access control effectively.
The operational impact of this vulnerability allows unauthenticated users to retrieve sensitive information about any learner enrolled in courses on the platform. By exploiting the lack of authorization checks, an attacker can iterate through sequential record identifiers associated with enrollment records. This technique, known as insecure direct object reference or IDOR, enables the enumeration of user data without needing valid credentials for each target account. The exposed data includes detailed course progress metrics, specific timestamps indicating when enrollments occurred, and current enrollment statuses. For enrolled users who do have some level of access to the platform, a related gap permits them to retrieve enrollment records belonging to other learners as well. This expands the attack surface significantly, allowing malicious actors with even minimal legitimate access to harvest comprehensive profiles of their peers or competitors within the educational ecosystem.
From a classification perspective, this vulnerability aligns directly with CWE-284, which describes Improper Access Control, and more specifically CWE-639, Authorization Bypass Through User-Controlled Key. The exploitation method corresponds to ATT&CK technique T1078, Valid Accounts, as it involves leveraging existing credentials or lack thereof to access resources intended for other users. Furthermore, the exposure of personal data such as learning progress and timestamps may trigger compliance concerns under regulations like GDPR or CCPA, depending on the jurisdiction and nature of the educational institution using the software. The ability to walk sequential identifiers suggests that the API relies on predictable integer-based primary keys without additional obfuscation or validation layers, which is a common but dangerous pattern in RESTful service design when combined with weak server-side checks.
To mitigate this vulnerability, immediate action must be taken by upgrading the Masteriyo LMS plugin to version 3.4.0 or later, where these authorization gaps have been addressed. For organizations unable to upgrade immediately due to compatibility constraints, implementing a web application firewall rule that restricts access to the specific REST API endpoints involved can provide temporary protection. Additionally, developers should review all custom code interacting with enrollment data to ensure that every read operation includes rigorous verification of user permissions against the requested resource ID. It is also advisable to implement rate limiting on these endpoints to prevent rapid enumeration attacks and consider using non-sequential identifiers for internal records to make walking IDs more difficult if such a change is feasible in future updates. Regular security audits focusing on API authorization logic are essential to maintain robust protection against similar access control failures.