Path traversal in SCORM package uploads affects Frappe Learning Management System (LMS)

Frappe Learning Management System (LMS) is a learning system that helps users structure their content. In versions 2.50.0 and below, a user with course editing role could upload a SCORM ZIP package to write files outside the intended directory. This issue has been resolved in version 2.50.1.

• The normalized record lists Frappe LMS as affected at < 2.50.1, and the supplied source description states 2.50.0 and below.
• The vendor advisory on GitHub instead lists <= 2.49.0 as affected and 2.50.1 as patched.
• These sources disagree on the status of 2.50.0. Do not assume that release is safe or affected solely from one boundary; verify the deployed release directly.
• 2.50.1 is the patched release confirmed by both the record and the advisory. The advisory also instructs users to update to v.2.50.1 or higher. The status of parallel branches has not been independently reconciled in the available evidence.

Frappe Learning Management System (LMS) processes SCORM ZIP packages supplied by users with a course editing role. The flaw is a CWE-22 path traversal issue in which extraction paths are not adequately constrained to the intended SCORM directory, allowing a specially constructed archive to cause writes outside that directory. The vendor describes the fix as validating extraction paths so they remain within the SCORM directory, indicating that the vulnerable operation is the archive extraction and path-validation logic. The documented precondition is access to a course editing role and the SCORM upload functionality; the accompanying assessment indicates network reachability, low complexity, and no additional user interaction. The available evidence does not identify the specific endpoint, archive path syntax, writable target paths, LMS process permissions, or a confirmed code-execution chain.

• Reachability: The flaw is in the network-accessible SCORM package upload function.
• Authentication and authorization: An attacker needs an account with a course editing role; the issue is not described as unauthenticated.
• Interaction and complexity: The supplied assessment indicates that no additional user interaction is required and that attack complexity is low.
• Exploitation status: The normalized record does not identify known exploitation and sets public_exploit to false. However, a public GitHub repository lists a PoC entry describing this issue as leading to remote code execution. The retrieved page did not expose the PoC's technical content, so weaponization or successful remote code execution against deployed systems is not confirmed.

The flaw lets an authenticated user write files outside the intended SCORM directory through ZIP package extraction. The direct technical outcome is arbitrary file write, which may affect application or data integrity and may disrupt service if a sensitive location is overwritten. The final privilege level available to an attacker is not confirmed because the record does not identify the LMS process permissions or target files. A public PoC repository describes the issue in terms of remote code execution, but its technical content and reproducibility were not confirmed in the retrieved evidence. Exploitation is constrained by the requirement for a course editing role.

Writing files outside SCORM storage can modify application files or service data at locations writable by the LMS process. This creates a direct integrity and availability risk; the practical effect depends on the affected path and the process permissions. The supplied evidence does not confirm file disclosure or a specific takeover scenario. A public GitHub repository describes a PoC for the issue as leading to remote code execution, but the PoC content was not retrieved, so that consequence remains unconfirmed.

1. Update to 2.50.1, the confirmed patched release for this issue.
2. Because the sources give different affected boundaries for 2.50.0, verify the exact release running on each site instead of inferring status from a nearby branch or tag.
3. Until patching is possible, reduce the number of accounts with the course editing role and consider temporarily disabling SCORM uploads if the operating model permits it. This is a precautionary risk-reduction measure, not a vendor-confirmed workaround.
4. After upgrading, review files created or modified outside the intended SCORM directory and investigate unexplained changes.

1. Inventory systems running Frappe Learning Management System (LMS) and verify the deployed release, comparing it with the confirmed patched release rather than relying only on the product name.
2. Identify deployments that enable or use SCORM package uploads, and enumerate accounts granted the course editing role.
3. Review application logs, server logs, and filesystem audit logs where available around SCORM upload and extraction activity. Look for changes outside the intended SCORM directory.
4. Check for files created or modified by the LMS service account in locations outside SCORM storage. This is an investigation check based on the documented behavior, not a vendor-confirmed IOC.
5. The available evidence does not define a specific log event or IOC. The absence of suspicious log evidence does not prove that a system was not affected.