CVE-2026-97702 in Open edX Platform
Summary
by MITRE • 11/05/2026
Open edX Platform enables the authoring and delivery of online learning at any scale. From the Ulmo release until release/ulmo.4 and release/verawood.1, the GET /api/support/v1/manage_course_team/ endpoint in CourseTeamManageAPIView requires only IsAuthenticated and omits the global support-role authorization check intended for this help-desk surface. Any authenticated learner can supply an email, username, or user_id for an arbitrary target and use the 200 and 404 response discrepancy to distinguish an active account from an absent or inactive account. A caller with a course-level or organization-level instructor role can additionally obtain the target user's staff or instructor assignments within the caller's course or organization scope. Anonymous callers remain blocked, and the separately authorized PUT behavior is outside this vulnerability. This issue is fixed in release/ulmo.4 and release/verawood.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/05/2026
The Open edX platform serves as a robust infrastructure for authoring and delivering online learning experiences at scale, yet specific implementation flaws within its API layer can expose sensitive user data to unauthorized actors. A critical vulnerability was identified in the GET /api/support/v1/manage_course_team/ endpoint of the CourseTeamManageAPIView class during the Ulmo release through version ulmo.4 and verawood.1. This endpoint is designed as a support-desk tool intended for administrative use, requiring strict global support-role authorization to ensure that only privileged personnel can access sensitive user management data. However, due to an oversight in the permission configuration, the endpoint relied solely on the IsAuthenticated check rather than enforcing the necessary role-based access control. Consequently, any authenticated learner with a valid session could interact with this administrative interface without possessing the requisite support privileges, effectively bypassing the intended security boundary between standard users and system administrators.
The technical flaw manifests as an information disclosure vulnerability that allows for user enumeration and privilege mapping within specific scopes. By submitting various email addresses, usernames, or user IDs to the endpoint, a malicious actor can analyze the HTTP response codes returned by the server. A 200 OK status indicates that the target account exists and is active, while a 404 Not Found status suggests the account does not exist or is inactive. This discrepancy in responses creates a reliable side-channel for enumerating valid user accounts within the platform. Furthermore, if the attacker holds an instructor role at either the course level or organization level, they can leverage this endpoint to retrieve detailed information about other users' roles and assignments. Specifically, the attacker can determine whether specific individuals hold staff or instructor positions within the same course or organization scope where the attacker has authority. This capability transforms a simple authentication bypass into a powerful reconnaissance tool that aids in mapping out the internal hierarchy and identifying high-value targets for further exploitation attempts.
From an operational impact perspective, this vulnerability compromises the confidentiality of user identity data and role assignments. While it does not directly allow for account takeover or arbitrary code execution, it significantly lowers the barrier for social engineering attacks and targeted phishing campaigns by confirming which users are active on the platform. Additionally, knowledge of staff and instructor roles enables attackers to identify individuals with elevated privileges who may be more susceptible to credential harvesting or whose accounts could provide greater access if compromised. The vulnerability is limited in scope as anonymous callers remain blocked from accessing this endpoint, and the PUT method behavior remains properly secured by separate authorization checks. However, the ability to enumerate users and map roles within an organization undermines trust in the platform's security model and violates principles of least privilege.
To mitigate this risk, organizations running affected versions must upgrade immediately to release/ulmo.4 or release/verawood.1, where the permission logic has been corrected to enforce global support-role authorization on the GET endpoint. Until upgrading is possible, administrators should consider implementing network-level access controls such as IP whitelisting for administrative API endpoints if feasible within their infrastructure architecture. Additionally, monitoring logs for unusual patterns of requests to this specific endpoint can help detect ongoing enumeration attempts by malicious actors. This incident highlights the importance of rigorous code review processes that explicitly verify authorization checks on all administrative interfaces, ensuring that role-based access controls are consistently applied across both read and write operations in sensitive API endpoints. The vulnerability aligns with CWE-284 Improper Access Control and is relevant to ATT&CK techniques involving Account Enumeration and Discovery of Privileged Accounts within enterprise environments.