Verifying a Patched Brotli Decoder in Node.js and .NET
Release notes say the Brotli flaw is fixed. That describes a source tree, not the binary your process is executing. This walkthrough is a method for verifying the decoder fix yourself in Node.js and .NET: check what each runtime actually vendors, hash the executable and the native compression library instead of trusting a semver, and drive a crash-only harness that spawns a child process so a decoder memory bug cannot take down the test run. From there, differential runs of the old decoder against the new one on the same bytes, an output cap you enforce in your own code, and a read of the real patch diff. The post is explicit about what the reported Brotli issue does not include: no CVE identifier, no vendor advisory, no affected version range, no proof-of-concept input, and no statement of bug class. Those gaps are named rather than filled in, so treat every detail here as scoped to a lab. All of it is defensive: generate your own hostile inputs, run them against builds you control, and measure what the process does. One architecture claim is checkable in seconds: both runtimes link the same upstream C decoder rather than reimplementing it, which is why one flaw becomes two very different patching problems. Read the full write-up: https://hackyjs.com/posts/verifying-a-patched-brotli-decoder-in-nodejs-and-net-without-trusting-the-changelog