Full Disclosure mailing list archives
CVE-2026-56877 - Skillable SCORM userId authorisation bypass
From: Greg via Fulldisclosure
Date: Sun, 12 Jul 2026 10:19:54 +0000
Skillable's SCORM lab launch endpoint validates a launch token but enforces per-user allocation limits using a browser-supplied userId that is not bound to the validated token. An authenticated learner can modify this identifier to bypass configured limits, launch concurrent lab instances, and consume another learner's allocation. Skillable states that no fix is planned for the legacy SCORM launch path. CVE-2026-56877 was assigned by MITRE. 1. Advisory information ----------------------- Title: CVE-2026-56877 - Skillable SCORM userId authorisation bypass Advisory: https://github.com/GregDurys/security-advisories/tree/main/skillable CVE: CVE-2026-56877 (assigned; record publication pending) Class: CWE-639 (Authorization Bypass Through User-Controlled Key) CVSS: 6.5 (Medium) - AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Date: 2026-07-12 Author: Greg Durys 2. Affected software -------------------- Vendor: Skillable (formerly Learn on Demand Systems) Service: Hosted SCORM lab provisioning (cloud service, no on-premises deployment) Endpoint: scorm.skillable.com/scorm/launch Tested: 2026-04-28 to 2026-05-03 (production endpoint, via the Red Team Ops course on the Zero Point Security platform) Fix: None. The vendor states that no server-side identity validation will be added to the SCORM launch path. Remediation is migration to an API or LTI 1.3 launch integration. 3. Testing scope ---------------- All validation was performed within a normal student workflow on the Red Team Ops course. The bypass and the cross-user denial of service were confirmed against the production endpoint. The certification exam endpoint was not tested; Skillable subsequently confirmed to an affected customer that the same weakness could affect exam allocations and could return details associated with another learner's session. 4. Summary ---------- The SCORM launch request is assembled and initiated client-side. Loading a lab unit builds a launch URL and requests it from scorm.skillable.com with a SCORM token and userId as query parameters. Skillable validates the token sufficiently to authorise the launch, then evaluates the per-user launch limit against the supplied userId. The token is server-validated, while the userId is client-controlled, and no binding between the two is enforced. The userId accepts arbitrary strings with no format validation. Values with a non-hexadecimal character in an otherwise expected-length identifier, and entirely fabricated structures, were both accepted and provisioned lab instances. The same SCORM token launches labs under different userId values, demonstrating that the token does not bind the launch to the supplied userId. The token remained unchanged across the tested launches, indicating that it did not provide a user-specific binding to the supplied userId. (a) Rate-limit bypass. Launching with a modified userId bypassed the per-user limit and provisioned a fresh LabInstanceId. Two concurrent instances under different userId values were confirmed. (b) Cross-user denial of service. A consenting colleague's userId was obtained through an authenticated learner enumeration vector on the LMS. A lab launched under that userId consumed the colleague's allocation. The colleague then attempted to launch the same lab and was locked out, while other labs launched normally. (c) Cost. Each instance provisions cloud VMs (typically a domain controller plus one to three machines, active 30 to 60 minutes) at the course provider's expense. An authenticated learner enumeration vector on the LMS would scale any of the above across the enumerable enrolled population. 5. Remediation -------------- Bind the launch to a server-validated learner identity, for example through a user-scoped signed token or server-to-server integration. Do not enforce per-user limits using an unverified browser-supplied userId. Skillable states that it will not add this binding to the legacy SCORM path and recommends migration to its API or LTI 1.3 integration. 6. Disclosure timeline ---------------------- 2026-04-28 Per-user rate-limit error observed; userId modification returned a new LabInstanceId 2026-04-29 Concurrent lab instances confirmed against a single account 2026-05-03 Cross-user denial of service confirmed with a consenting fellow student 2026-05-08 Findings documented; Skillable support ticket #4043837 raised; disclosure channel provided 2026-05-11 Report submitted to Disclosures () skillable com (encrypted archive) 2026-05-13 Skillable acknowledged receipt (Nat Shere, Manager, Product Security) 2026-05-19 CVE request submitted to MITRE (Skillable is not a CNA) 2026-05-27 Status request to Skillable; no response 2026-06-08 Second follow-up, restating the 60-day disclosure window (closing 2026-07-12) 2026-06-10 Skillable responded that the issue is "an inherent flaw in the SCORM technology" and requested no disclosure without written permission 2026-06-10 Pushback sent; open-ended embargo declined; 2026-07-12 date held 2026-06-23 MITRE assigned CVE-2026-56877; coordinated disclosure remained under embargo until 2026-07-12 2026-06-26 Skillable sent at least one affected customer an advisory ("SCORM-based lab launches and recommended migration"; no CVE, no CVSS), stating no server-side fix and recommending migration 2026-06-26 Coordination update sent to Skillable 2026-07-12 Advisory published 7. Current status ----------------- Vendor fix: The vendor states that no fix is planned for the SCORM launch path Vendor remediation: Migration to an API or LTI 1.3 launch integration Customer communication: Sent to at least one affected customer on 2026-06-26 (private notification, no CVE, no CVSS) CVE: CVE-2026-56877, assigned by the MITRE CNA of Last Resort 8. References ------------- - https://github.com/GregDurys/security-advisories/tree/main/skillable - https://www.cve.org/CVERecord?id=CVE-2026-56877 - https://cwe.mitre.org/data/definitions/639.html - https://payloadforge.io/beyond-crto-skillable _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
Current thread:
- CVE-2026-56877 - Skillable SCORM userId authorisation bypass Greg via Fulldisclosure (Jul 15)
Facts Only
* The endpoint scorm.skillable.com/scorm/launch validates a launch token but uses a browser-supplied User ID for per-user allocation limits.
* An authenticated learner can modify the User ID to bypass configured limits and launch concurrent lab instances.
* A lab launched under a modified User ID consumed the allocation of another learner.
* The system failed to enforce any binding between the validated launch token and the supplied User ID.
* The User ID accepts arbitrary strings without format validation, allowing for fabricated structures.
* Launch requests using different User IDs confirmed concurrent instances were provisioned under different identities.
* Lab instances provision cloud VMs at the course provider's expense.
* Remediation recommended is binding the launch to a server-validated identity, such as a signed token or server-to-server integration.
Executive Summary
The Skillable SCORM launch endpoint is vulnerable to an authorization bypass due to a failure to bind the requested user identity to the session token. An authenticated learner can manipulate the supplied User ID parameter in the launch request to circumvent per-user allocation limits, allowing for concurrent lab launches and consumption of another user's quota. The vulnerability exists because the system validates the SCORM token for authorization but does not enforce that the User ID provided by the client is bound to that validated token. This flaw permits the provisioning of lab instances under arbitrary or fabricated user identifiers.
The vendor has indicated that no fix is planned for the legacy SCORM launch path, recommending migration to API or LTI 1.3 integrations instead. The disclosure timeline shows that initial observations led to customer communication and subsequent reporting through standard channels, culminating in a published advisory.
Full Take
The core mechanism of this vulnerability lies in a breakdown between authorization (token validation) and resource control (user ID enforcement). The system correctly authenticates *who* is making the request via the token but incorrectly delegates the authority over resource limits to an untrusted client-supplied identifier. This establishes a weak control boundary: authentication grants access, but context/authorization relies on insecure client input. The implications extend beyond simple rate-limiting; the ability to cross-pollinate allocations demonstrates a systemic failure in identity management across service layers.
The vendor's stance—that no fix is planned for the legacy SCORM path and recommends migration—highlights a tension between technical debt, the difficulty of patching legacy systems, and security posture. This creates an environment where users must choose between accepting unpatched risk or undertaking costly migration efforts. The finding itself represents a pattern where complex, layered systems inherit fragility from deprecated protocols, forcing remediation onto higher-level architectural shifts rather than simple patch deployment.
What does this suggest about systemic trust? When control mechanisms are established across multiple layers (token validation, user management, resource allocation), failure at any single intersection allows for emergent, large-scale exploitation. The cost is borne by the entity trusting that the legacy path remains secure; here, the cost appears to be deferred to the end-user via potential denial of service or cost escalation, underscoring the need to treat identity boundaries as immutable architectural invariants rather than runtime variables.
Bridge Questions: If migration to API/LTI 1.3 is the recommended fix, what specific security properties does LTI 1.3 enforce that SCORM lacks regarding identity binding? How can organizations architecturally mandate that client-supplied identifiers must be cryptographically bound to server-validated identities in legacy protocols without requiring a full system overhaul? Does this incident indicate a general pattern where reliance on end-user context for resource management becomes an intractable design limitation in educational technology infrastructure?