# GHSA-gxxh-8vcj-w2mh: livewire-markdown-editor has arbitrary file upload that allows stored XSS via attachment handler

> Authenticated users can upload malicious files to achieve stored XSS or code execution due to missing validation in the Livewire markdown editor package.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 4 May 2026

## What is GHSA-gxxh-8vcj-w2mh?

GHSA-gxxh-8vcj-w2mh is a vulnerability in mckenziearts/livewire-markdown-editor, published on 4 May 2026. Any signed-in user can exploit it over the network, with no action from the victim.

### Official description

### Impact
All versions of `mckenziearts/livewire-markdown-editor` prior to **v1.3** contain a critical arbitrary file upload vulnerability in the `MarkdownEditor::updatedAttachments()` Livewire handler. The handler calls `$file->store()` with no server-side validation of MIME type, extension, or file content.

Any authenticated user with access to a page embedding `<livewire:markdown-editor>` can upload files of any type (`.html`, `.svg`, `.js`, `.php`, `.exe`, etc.) to the disk configured by `livewire-markdown-editor.disk`. When that disk is a public cloud bucket (S3, DigitalOcean Spaces, Cloudflare R2, Scaleway Object Storage — the common configuration when `FILESYSTEM_DISK` points to such a disk), uploaded files are served publicly with a guessed `Content-Type` header.

The consequences include:

- **Stored XSS** on the storage domain via uploaded `.html` or `.svg` files
- **Phishing page hosting** on the application's own storage domain (trust laundering)
- **Malware distribution** from a domain users associate with the application
- **Markdown injection** in the editor output via crafted filenames (the client-supplied `getClientOriginalName()` value was inserted verbatim into the markdown)

A real-world exploitation of this vulnerability was observed in production on a community platform using this package.

### Patches

Upgrade to **v1.3** or later.

### Workarounds

If developers cannot upgrade immediately, disable the upload UI on every instance of the editor by passing `:show-upload="false"`:

```blade
  <livewire:markdown-editor wire:model="content" :show-upload="false" />
```

This hides the file input and prevents the vulnerable code path from being reached.

### Resources

- Patch commit: https://github.com/mckenziearts/livewire-markdown-editor/pull/12
- Release: https://github.com/mckenziearts/livewire-markdown-editor/releases/tag/v1.3
- CWE-434: https://cwe.mitre.org/data/definitions/434.html
- CWE-79: https://cwe.mitre.org/data/definitions/79.html

## Which versions are affected by GHSA-gxxh-8vcj-w2mh?

2 open source packages ship an affected version, including mckenziearts/livewire-markdown-editor.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `mckenziearts/livewire-markdown-editor` | Packagist | All versions | 1.3 |
| `mckenziearts/livewire-markdown-editor` | Packagist | All versions | 1.3 |

## How do I fix GHSA-gxxh-8vcj-w2mh?

Upgrade mckenziearts/livewire-markdown-editor to 1.3 or later.

## Is GHSA-gxxh-8vcj-w2mh being exploited?

There is no known exploitation of GHSA-gxxh-8vcj-w2mh in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-gxxh-8vcj-w2mh and fix it if it is affected.

What it is: GHSA-gxxh-8vcj-w2mh is a vulnerability in mckenziearts/livewire-markdown-editor, published on 4 May 2026. Any signed-in user can exploit it over the network, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-gxxh-8vcj-w2mh in the wild and no public exploit code.

Affected packages and fixed versions:
- mckenziearts/livewire-markdown-editor (Packagist): affected all versions; fixed in 1.3
- mckenziearts/livewire-markdown-editor (Packagist): affected all versions; fixed in 1.3

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-gxxh-8vcj-w2mh/ (Markdown: https://insights.sbomify.com/GHSA-gxxh-8vcj-w2mh/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-gxxh-8vcj-w2mh

---
From sbomify Insights: https://insights.sbomify.com/GHSA-gxxh-8vcj-w2mh/
Summaries are generated and may contain mistakes; the official description above is the record.