Please report privately rather than in a public issue, using GitHub's private vulnerability reporting on this repository. That opens a channel visible only to you and the maintainer.
This is a one-person project. You should get an acknowledgement within a few days; if a week passes with no reply, feel free to nudge by opening a public issue that says only that you are waiting on a private report, no details.
Please include what an attacker can do, not only what looks wrong: the affected version or commit, the configuration that exposes it, and the smallest reproduction you have.
Duvlify builds a static site and, optionally, deploys a Worker in front of it. The interesting surface is small and worth naming:
- The agent surfaces:
/mcp,/api/docs/*, and the WebMCP bridge. Anything that lets a caller read something the site does not publish, exceed the rate limits, or make the Worker act as a proxy. - The build: anything in
content/or an OpenAPI document that can inject script into a rendered page, or escape astyleattribute into a second declaration.src/lib/css-value.tsexists for that second case, andsrc/lib/spec-markdown.tsfor prose arriving from a spec. - Publication rules: anything that makes a
draftornoindexpage reach an output it should not. That is a correctness bug with a confidentiality consequence, and it is treated as a security issue. - Secret handling: anything that puts
AI_SEARCH_TOKENorCLOUDFLARE_ACCOUNT_IDinto the built output. Neither should ever reach the Worker bundle.
agents.feedback.webhook. It is read at build time and compiled into the bundle, so it is served to anyone who asks. That is documented rather than fixed: use a receiver that authenticates some other way, and do not put a token in the URL.- A site's own misconfiguration: a committed
.env, a public bucket, a WAF rule that was never added. The repository documents what to set; it cannot enforce it. - Rate limits as a quota. The Workers rate limiting binding counts per datacenter and is eventually consistent by design, so a distributed client gets a multiple of the configured numbers. It is an abuse damper. The real ceiling is a WAF rule on the zone, and the documentation says so.
- Denial of service by volume against a deployment you control.
Pre-1.0, only the main branch is supported. There are no backports; a fix lands
on main and is released from there.
This file describes the upstream project, and it arrived in your repository with the code. Replace it. The reporting link above opens an advisory on this repository, so anyone who finds a vulnerability in your deployment and follows it reports to the wrong maintainer. A report about your content, your configuration, or your Worker secrets is not upstream's to receive.
Keep the two lists above as a starting point for your own threat model; they describe the framework, which you are still running. Add whatever your deployment adds.