GHSA-gxxh-8vcj-w2mh json
livewire-markdown-editor has arbitrary file upload that allows stored XSS via attachment handler
published 6mo ago modified 6mo ago
- cvss
- 7.1
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### 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
Patch / fix
- packagist mckenziearts/livewire-markdown-editor 1.3
Is GHSA-gxxh-8vcj-w2mh in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 7.1 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| packagist | mckenziearts/livewire-markdown-editor | <1.3 |
1.3 |
Classification
References
-
github.com
/mckenziearts/livewire-markdown-editor/commit/1e60eaa5781e89704e112425f832774be85cd71f
web
-
github.com
/mckenziearts/livewire-markdown-editor/security/advisories/GHSA-gxxh-8vcj-w2mh
web
-
github.com
/mckenziearts/livewire-markdown-editor
package
-
github.com
/mckenziearts/livewire-markdown-editor/releases/tag/v1.3
web
Sources
- GitHub Advisory GHSA-gxxh-8vcj-w2mh
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.