Arbitrary File Upload and Stored XSS in mckenziearts/livewire-markdown-editor

The mckenziearts/livewire-markdown-editor package provides a GitHub-style markdown editor for Laravel applications, utilizing Livewire and Alpine.js for interactivity. The package includes functionality allowing users to attach files to their markdown content via drag-and-drop or file selection. This feature relies on Livewire's internal file upload mechanisms and component lifecycle hooks to process incoming files.

The vulnerability exists in the handling of these file attachments, specifically within the MarkdownEditor component. The system exposes two primary attack vectors: an unrestricted arbitrary file upload (CWE-434) and a subsequent stored Cross-Site Scripting (CWE-79) vulnerability. These flaws stem from a systemic lack of input validation and output encoding during the file processing phase.

Any authenticated user with access to the markdown editor component can exploit this vulnerability. The impact ranges from hosting malicious files on the application's storage infrastructure to executing arbitrary JavaScript in the browsers of users viewing the rendered markdown content.

The root cause of this vulnerability lies in the implementation of the updatedAttachments lifecycle hook within the Livewire component. In the Laravel Livewire framework, updated* methods are automatically executed when a public property changes state. When a user uploads a file, the attachments property is populated, triggering the updatedAttachments method.

In versions prior to 1.3, this method processed the uploaded files without invoking any validation routines. The component omitted calls to Laravel's validation engine (e.g., $this->validate()), meaning constraints on file types, extensions, MIME types, and file sizes were completely absent. The framework accepted any file provided by the client, including potentially dangerous formats like .html, .svg, or .js.

Furthermore, the application handled the storage and reference of these files insecurely. The code utilized $attachment->store('', $disk), a method that preserves the client-provided file extension and stores the file directly on the configured storage disk. The original client-provided filename was then embedded directly into the generated markdown string, such as ![filename](url). This direct concatenation without sanitization created a secondary injection vector where the filename itself became the payload.

The remediation implemented in commit 1e60eaa5781e89704e112425f832774be85cd71f addresses the vulnerability across three distinct logical layers: input validation, secure storage, and output sanitization. Prior to the patch, the component implicitly trusted all client input during the file upload process.

The most critical addition is the enforcement of server-side validation. The patch introduces a rules() method that applies Laravel's comprehensive file validation directives. This ensures that incoming files are strictly validated against allowed extensions, MIME types, and size constraints before any storage operations occur.

// Added validation rules in v1.3
public function rules(): array {
    $config = config('livewire-markdown-editor.upload');
    $extensions = implode(',', $config['allowed_extensions']);
    return [
        'attachments.*' => array_values(array_filter([
            'required', 'file',
            $config['images_only'] ? 'image' : null,
            'mimes:'.$extensions, 'extensions:'.$extensions,
            'max:'.$config['max_size'],
        ])),
    ];
}

Additionally, the patch modifies the storage mechanism to utilize randomized filenames. By switching to $attachment->storeAs('', Str::random(40).'.'.$extension, $disk), the application neutralizes path traversal risks and prevents attackers from controlling the final stored filename on the server. The patch also introduces a sanitizeFilename method that strips markdown syntax characters ([]()<>) and control characters from the original filename before embedding it into the markdown response, effectively closing the XSS injection vector.

Exploitation of this vulnerability requires an attacker to interact with the markdown editor component, typically necessitating an authenticated session. The attacker intercepts the file upload request generated by the Livewire component and modifies the payload. Because the server lacks validation, the attacker can submit a file with an .html or .svg extension containing a malicious script payload.

Once the file is successfully uploaded, the server returns the storage URL. If the application is configured to use a public cloud storage disk (such as Amazon S3 or DigitalOcean Spaces) that does not force a generic Content-Type or Content-Disposition: attachment header, the browser will execute the script when a user navigates directly to the file URL. This facilitates malware distribution or direct script execution under the context of the storage domain.

The secondary exploitation vector involves Markdown syntax injection via the filename. The attacker modifies the filename parameter in the upload metadata to contain markdown control characters. For example, supplying the filename image.png](javascript:alert(1)) causes the server to construct the string ![image.png](javascript:alert(1))](storage_url). When the application renders this markdown into HTML, the injection breaks out of the expected image tag structure, executing the arbitrary JavaScript whenever the page is viewed.

The following diagram illustrates the vulnerable execution flow, demonstrating how unvalidated input traverses the Livewire component and results in stored XSS.

This flow highlights two distinct termination points for the attack. The first termination point occurs via direct access to the hosted file on the storage disk. The second termination point occurs when the injected markdown string is persisted to the application database and subsequently rendered to victim users.

The attack surface is heavily dependent on the application's specific storage configuration. Applications utilizing local storage disks may mitigate the direct file execution vector if the web server (e.g., Nginx or Apache) restricts execution in the storage directory. However, the markdown injection vector remains viable regardless of the underlying storage infrastructure.

The successful exploitation of this vulnerability leads to high-impact security compromises within the application. The primary consequence is Stored Cross-Site Scripting (XSS). An attacker can permanently inject malicious scripts into application pages that render user-generated markdown. This allows for session hijacking, credential theft, and unauthorized actions performed in the context of the victim's authenticated session.

The arbitrary file upload component of the vulnerability poses additional risks. Attackers can leverage the application's infrastructure to host phishing pages, distribute malware, or store illicit content. Because the application processes these files and serves them from its designated storage location, the malicious content benefits from the domain reputation of the target application.

The severity is amplified in environments utilizing public cloud storage buckets without strict object-level security policies. In such configurations, the uploaded files are publicly accessible by default, expanding the reach of hosted malware and facilitating broader exploitation campaigns.

The definitive remediation for this vulnerability is upgrading the mckenziearts/livewire-markdown-editor package to version 1.3 or higher. This version contains the comprehensive fix detailed in commit 1e60eaa5781e89704e112425f832774be85cd71f, implementing strict server-side validation, randomized file storage, and filename sanitization.

Administrators should execute composer update mckenziearts/livewire-markdown-editor to retrieve the patched version. Following the upgrade, development teams must review the newly introduced livewire-markdown-editor.upload configuration options to ensure the allowed file extensions and maximum file size align with their application's specific security requirements.

If an immediate upgrade is not feasible, a temporary workaround exists. Developers can disable the upload feature entirely by passing the show-upload property to the component as false: <livewire:markdown-editor :show-upload="false" />. Additionally, security teams should audit existing stored attachments for anomalous file types or filenames containing markdown syntax control characters.