Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2024-51499

CVE-2024-51499: MarkUs File Write RCE Vulnerability

CVE-2024-51499 is an arbitrary file write flaw in MarkUs web application that allows authenticated users to write files anywhere on the server, leading to remote code execution. This article covers technical details, affected versions, impact assessment, and mitigation strategies.

Published:

CVE-2024-51499 Overview

CVE-2024-51499 is an arbitrary file write vulnerability in MarkUs, a web application used for the submission and grading of student assignments. The flaw resides in the update_files method of the SubmissionsController and affects all versions prior to 2.4.8. Authenticated users, including students, can write arbitrary files to any location on the underlying web server, subject to filesystem permissions. Attackers can escalate this primitive to delayed remote code execution by writing a Ruby file into the config/initializers/ subfolder of the Rails application. The MarkUs maintainers addressed the issue in version 2.4.8. This weakness is categorized as [CWE-434] Unrestricted Upload of File with Dangerous Type.

Critical Impact

Any authenticated MarkUs user can write arbitrary files to the server filesystem, enabling delayed remote code execution when files land in Rails initializer directories.

Affected Products

  • MarkUsProject MarkUs versions prior to 2.4.8
  • Ruby on Rails deployments of MarkUs used for assignment submission and grading
  • Self-hosted MarkUs instances exposing the SubmissionsController to authenticated students

Discovery Timeline

  • 2024-11-18 - CVE-2024-51499 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-51499

Vulnerability Analysis

MarkUs exposes an update_files action inside the SubmissionsController that accepts file inputs from authenticated users. Prior to version 2.4.8, the controller did not properly constrain the destination path when writing submitted files to disk. An authenticated attacker can supply crafted path components that resolve outside of the intended submission directory. The write operation then executes with the permissions of the Rails process, allowing files to be placed anywhere the operating system permits.

The most impactful abuse path leverages Rails initializer semantics. Any Ruby file placed under config/initializers/ is loaded automatically the next time the application boots. An attacker who writes a Ruby payload into that directory achieves code execution on the next restart or worker reload, converting a file write primitive into delayed remote code execution.

Root Cause

The root cause is missing validation and sanitization of user-controlled file destinations in the update_files method. The controller trusts request-supplied path metadata rather than enforcing a canonicalized path prefix inside the submission storage root. Because MarkUs is a Rails application, this file write primitive intersects with framework auto-loading behavior, expanding the impact from data tampering to code execution.

Attack Vector

Exploitation requires only an authenticated MarkUs account, which in academic deployments typically includes student roles. The attacker sends a request to the update_files endpoint containing a filename or path parameter that traverses outside the expected submission directory. When the payload targets config/initializers/, the Ruby file is executed the next time the application initializes, yielding code execution in the context of the Rails process. See the GitHub Security Advisory GHSA-j95p-7936-f75w for maintainer-provided technical details.

No verified public proof-of-concept code is available. Refer to the vendor advisory and the MarkUs Pull Request #7026 for the corrective changes.

Detection Methods for CVE-2024-51499

Indicators of Compromise

  • Unexpected .rb files appearing under the MarkUs Rails application config/initializers/ directory or other non-submission paths.
  • New or modified files on the MarkUs server owned by the Rails process user with timestamps correlating to student submission activity.
  • Unusual application restarts or worker reloads shortly after submission upload requests from non-administrative accounts.

Detection Strategies

  • Review web server and Rails request logs for POST or PATCH requests to the update_files endpoint of SubmissionsController containing suspicious filename components such as .., absolute paths, or Ruby extensions.
  • Enable file integrity monitoring on the MarkUs deployment directory, prioritizing config/, lib/, and application boot paths.
  • Correlate authenticated user identifiers in application logs against file creations outside expected submission subdirectories.

Monitoring Recommendations

  • Alert on any write to config/initializers/ outside of documented deployment or CI activity.
  • Monitor process execution parentage from the Rails application user for shells, network utilities, or interpreters spawned post-initializer load.
  • Track authentication events for accounts that submit unusually large numbers of update_files requests in short intervals.

How to Mitigate CVE-2024-51499

Immediate Actions Required

  • Upgrade MarkUs to version 2.4.8 or later, which contains the fix from Pull Request #7026.
  • Audit the MarkUs application directory for unauthorized files, particularly under config/initializers/, and remove any that were not deployed by administrators.
  • Rotate application secrets and credentials stored in the Rails environment if unauthorized file writes are confirmed.

Patch Information

MarkUs 2.4.8 resolves CVE-2024-51499 by constraining file writes performed by the update_files method of SubmissionsController. Administrators should apply the upgrade through their standard deployment process and restart the Rails application afterward. Details of the code changes are available in MarkUs Pull Request #7026 and the GitHub Security Advisory GHSA-j95p-7936-f75w.

Workarounds

  • No application-level workaround is available according to the MarkUs maintainers; upgrading is the required remediation.
  • As a defense-in-depth measure, restrict filesystem permissions of the Rails process user so that write access is limited to the submission storage directory.
  • Where feasible, place the MarkUs deployment behind a web application firewall configured to inspect and block path traversal patterns in submission-related requests.

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.