## https://sploitus.com/exploit?id=PACKETSTORM:226162
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 <https://payloadforge.io>
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