Esbuild

What it is

An XSS in the esbuild dev server's directory listing (github.com/evanw/esbuild), present since 2022. The page's author found it via depthfirst's automated system, which flagged it as low severity and also drafted the patch. The page gives no esbuild version numbers and no CVE.

How it works

respondWithDirList builds an <h1> breadcrumb of links from the request path. Each link is written as <a href=" + escapeForHTML(path prefix) + /">. escapeForHTML replaces &, < and > but not ". That is enough for text between tags, but not inside a quoted attribute. A directory name containing " closes the href and lets the name inject its own attributes.

esbuild appends /"> after the escaped value, so the payload ends with a dummy attribute, data-x=", to absorb the trailing /". The page's proof-of-concept folder:

mkdir -p 'public/foo"style="position:absolute;top:0;left:0;width:100vw;height:100vh;" onmouseover="alert(`xss`)" data-x="'

The injected style stretches the link over the whole viewport. The onmouseover handler then fires on any cursor movement, so no click is needed. Reloading the dev server and moving the mouse triggers it.

Preconditions / Affected

• The victim runs the esbuild dev server and opens a directory listing that contains a folder with a crafted name.
• The attacker must be able to create that folder in the served tree, for example through a cloned repo or extracted archive. The page does not spell this out, but the PoC uses mkdir.
• Only the dev server's directory listing is affected, not esbuild's bundling output.

What to do

The fix is a one-word swap at the href call site, from escapeForHTML(...) to escapeForAttribute(...). escapeForAttribute calls escapeForHTML and also replaces " and ' with entities. The author says the patch was merged immediately. The page does not name a release containing it, so check your installed esbuild against upstream before assuming you are covered.

Caveats

The maintainers thanked the author but said the dev server assumes a trusted environment, so this is not a security vulnerability in the traditional sense. The author agrees it is not CVE-worthy and describes it as an exploitable bug with no production impact. The "5 billion downloads" figure is the npm package's total, not a count of exposed dev servers.