mdBook's search fix requires rebuilding published books

A static documentation site can execute substantial code in its readers' browsers. Its generator may run only during publication, but the JavaScript it emits remains active whenever someone uses the site. The mdBook security advisory makes that distinction operationally important. Updating the build tool alone leaves already generated pages carrying the vulnerable search implementation.

The January 4 advisory identifies CVE-2020-26297 as a cross-site scripting vulnerability in mdBook search. It says the search feature introduced in version 0.1.4 is affected and that version 0.4.5 fixes the problem by escaping the query correctly. Site owners need to upgrade and rebuild their website contents.

I am interested in Rust's ability to make low-level code safer, but a tool's implementation language does not establish the safety of JavaScript it generates. This issue lives in the browser-facing search code. The relevant question is how that code turns a user's search text into another interpreted representation.

A query can arrive through a link

The advisory describes two ways to trigger the issue. An attacker can persuade a reader to type a malicious search query. Alternatively, the attacker can provide a link to the search page with the query already filled in. The second path means the reader does not need to invent or paste the problematic input into a search field.

The result is arbitrary JavaScript execution on the page, according to the advisory. That is a browser-side impact. It should not be described as the attacker running code inside the Rust build process or gaining execution on the documentation host. The vulnerable component receives the search query when the reader uses the generated website.

This input boundary is easy to underestimate in documentation. A site may publish only trusted prose, yet its search interface still processes text from the reader or from a URL. Trust in the book's author does not make a query supplied by someone else trustworthy. The search code must preserve that distinction when it constructs results.

The prefilled-link case also shows why reviewing only the visible input box is insufficient. A query can pass through a URL before search consumes it. The program needs the right encoding at each representation boundary, rather than relying on where a reader appears to enter the text.

The patch encodes search terms in generated links

The 0.4.4 to 0.4.5 diff locates the change in src/theme/searcher/searcher.js. Before returning the result link markup, the code joins the search terms, applies encodeURIComponent, and replaces apostrophes with their percent-encoded representation. The patch comment explains that the additional replacement handles a character the JavaScript function leaves unescaped.

The encoded terms become a query-parameter value in the link returned for a search result. That construction combines a document path, a query component, and a fragment. Search text belongs inside the query value. It must not gain control of the surrounding markup or the other structural parts of the link.

The change makes the representation step explicit. User-supplied text is not already a safe component merely because it is stored in a string or organized into an array of terms. Joining those terms produces another string. Encoding gives that string the representation expected at the destination where the result builder inserts it.

This is also why a general statement about escaping can be too vague. The patch does a specific transformation before constructing a specific kind of link. An explanation needs to identify that destination. Otherwise, it can leave the impression that any replacement of angle brackets, or any encoding performed earlier in the pipeline, would establish the same property.

The release diff is small. Apart from version changes in Cargo metadata, the security-relevant modification is the searcher change. That makes it possible to connect the advisory's instruction to the artifact a site owner actually publishes. The repaired generator includes a different search script in its output.

The output is the deployed program

The advisory gives an installation command for the fixed generator. This is the published command for selecting version 0.4.5, including replacement of an existing installation.

cargo install mdbook --version 0.4.5 --force

Installation changes the local tool available for future builds. It does not modify a book that has already been generated and uploaded. Rebuilding with the repaired version produces output carrying the fix. Publishing that output makes it available to readers of the site.

The sequence matters wherever build and hosting are separate. A documentation host may serve files produced elsewhere without having mdBook installed at all. Its deployed assets still depend on which generator produced them. The vulnerable logic remains in those assets even when the original build environment has been deleted or replaced. A tool-version inventory and an inventory of published output therefore answer different questions.

I find the advisory's rebuild requirement more useful than a generic instruction to update a package. It identifies the step that changes the reader's execution environment. The browser loads the generated search code, so that is the code that must be replaced.

Disclosure identifies the repaired version

The Rust Security Response Working Group records the initial report on December 30 at 20:14 UTC and acknowledgment eighteen minutes later. Its timeline says the cause and a patch were ready that evening. The fixed release and public disclosure occurred January 4 at 15:00 UTC. The group credits Kamil Vavra with responsible disclosure.

Those dates explain why the public action is a January event even though investigation began in December. They also identify a version that site owners can use for the rebuild. The advisory's mitigation applies to websites built with mdBook, including already published documentation whose search assets came from an affected generator.

The practical consequence is a dependency on generated output that persists after a build finishes. A repaired tool produces repaired search code on the next build. The published site needs that output before its readers receive the corrected handling of search queries.