CVE-2026-102811 is a High severity missing authentication flaw in the development server of Marmite, a Rust static site generator. Through version 0.4.2, unauthenticated clients can create and overwrite content and configuration, and path traversal can write outside the project. Version 0.4.3 changes the default bind address.
What's affected
- Product: Marmite, a static site generator written in Rust, from the rochacbruno/marmite project.
- Affected: versions through 0.4.2, per the record.
- Scope: the built in development server started with the serve option. The upstream issue notes that a static site deployed from the output is unaffected.
- Endpoints named in the record: /marmite/content, /marmite/config and /marmite/file/.
- Related change: version 0.4.3 makes the server bind to 127.0.0.1:8000 by default instead of all interfaces.
Source note: the record describes missing authentication and directory traversal. The fix commit linked from the record is titled to keep the development server bound to the requested interface, and its release notes describe a safer default bind address. The pages I read do not say that authentication was added to these endpoints, so check the project's release notes for 0.4.3 or later before assuming the endpoints are now protected.
How to check if you're exposed
Find out which Marmite version your authors and CI use, and whether anyone ever left the dev server running on a shared network.
marmite --version
cargo install --list | grep -i marmite
ss -ltnp | grep 8000
The last command lists listeners on port 8000, the default for the server. A listener on 0.0.0.0 or on a LAN address, rather than 127.0.0.1, is the situation the record describes. Also look at Dockerfiles, devcontainer files and remote dev boxes where the serve option might be exposed on a published port.
If Marmite is only used to build static output in CI and the serve option is never started, the vulnerable code is not running.
What to do now
- Stop any Marmite development server that is reachable from other machines.
- Upgrade to Marmite 0.4.3 or later, and read its release notes.
- Start the server only on 127.0.0.1. Use an explicit bind address on another interface only on a trusted, isolated network.
- Never run the development server on a public host or behind a public port mapping. Deploy the generated static output to ordinary hosting instead.
- If a server was exposed, review your content and configuration files for unexpected changes, and check for files outside the project folder that you do not recognise.
- Add Marmite to your dependency and tool inventory so future advisories reach the right people.
Why it matters
The record classes this as CWE-306, missing authentication for a critical function. The development server was built for a single author on a laptop. It exposes endpoints that create, change and move content, and it started on all interfaces by default, so anyone who could reach the port could use them.
The record adds that unsanitised path parameters in the create and clone handlers allow writes outside the project directory. That turns a content editing convenience into a general file write. The upstream issue lists further file handling paths, so the sensible assumption is that the dev server is unsafe on any untrusted network.
The record does not list this CVE as exploited in the wild. The practical lesson applies well beyond Marmite: development servers are not production servers, and a default bind to all interfaces is a risk worth checking in every tool your team runs.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect sites I already published?
The upstream issue says static site deployments are unaffected. The risk is in the development server process.
Is binding to localhost enough?
It greatly reduces exposure from the network, which is the change in 0.4.3. It does not help if other local users or forwarded ports can still reach the server.
Sources
Last reviewed: 18 October 2026.
