daywire
25 October 2026

Technology, in perspective.
New editions around 6am.

Daywire.

A daily read.
Something to take away.

Sunday, 25 October 20263 stories · 2 lessonsAbout 5 min to read

Critical denial‑of‑service flaws have been uncovered in popular Node.js middleware packages body‑parser and multer, prompting urgent upgrades. Meanwhile, Go 1.27’s experimental SIMD libraries promise a new performance frontier for pure‑Go numeric code.

Take it with you

body-parser versions <2.4.0 and <1.20.9 vulnerable to denial-of-service via trailing bytes in compressed requests

Security1 source

A single crafted compressed request can crash any Express app using body-parser default options, affecting versions ≥2.0.0 < 2.4.0 and < 1.20.9.

The OpenJS Security Advisories published a new advisory (CVE‑2026‑111181) on 22 Oct 2026 reporting that body-parser ≥ 2.0.0 < 2.4.0 and < 1.20.9 can be forced to crash an application with a single crafted request. When a request includes a Content‑Encoding such as gzip, body-parser streams the payload to a decompressor. If the compressed frame is followed by trailing bytes, the decoder finishes, then receives the extra bytes, emits an error without a listener, and the error bubbles up as an uncaught exception, terminating the Node process. No authentication or route matching is required because parsing occurs before routing.

The issue is fixed in body-parser 2.4.0 and 1.20.9. Upgrading to either version eliminates the crash. As a temporary mitigation, applications can pass inflate: false to the middleware to reject compressed bodies entirely, at the cost of losing support for gzip/deflate payloads.

Our take. Engineers should upgrade body-parser to 2.4.0 or 1.20.9 immediately, or disable compression handling, to prevent unexpected process termination in production services.

multer 2.5.0 patches denial‑of‑service crash caused by pending async fileFilter

Security1 source

A high‑severity DoS bug in multer 2.0‑2.4.x that crashes Node.js when an async fileFilter is pending during request teardown is fixed in version 2.5.0.

The OpenJS advisory (CVE‑2026‑113872, published 2026‑10‑22) reports that any multer configuration using an asynchronous fileFilter can be forced to crash the process. If a request is aborted while another file’s async filter is still pending, the callback resumes a parsing stream that busboy has already torn down, emitting an unhandled error event that terminates Node.js. A single unauthenticated request is sufficient, affecting all applications that rely on async fileFilter regardless of storage engine. Synchronous fileFilters are not vulnerable.

The fix is released in multer 2.5.0; upgrading eliminates the race condition. As a temporary mitigation, developers can replace async fileFilters with synchronous ones until they can apply the update. The advisory notes the vulnerability’s CVSS score of 7.5 (High).

Our take. Engineers should upgrade to multer 2.5.0 or later, or switch to a synchronous fileFilter, to prevent unexpected process termination in production services handling file uploads.

Go 1.27 adds experimental SIMD packages, enabling vectorized loops in pure Go

Engineering1 source

Go 1.27 introduces experimental simd/archsimd and portable simd packages that let developers write ordinary Go loops which compile to SIMD instructions, boosting numeric loop performance on amd64.

The new simd/archsimd package (available since Go 1.26) and its higher‑level portable simd wrapper (Go 1.27) turn a plain loop that adds two []float32 slices into code that uses the CPU’s eight‑wide SIMD units. Previously this required hand‑written assembly; now the compiler emits vector instructions when the GOEXPERIMENT=simd flag is set. The packages are experimental, limited to amd64, and their names may change in future releases.

Because the feature is gated behind an experiment flag, developers must opt‑in and accept that the API could evolve. Benchmarks in the article show noticeable speedups for simple element‑wise addition, but the benefit depends on data alignment and the specific CPU’s SIMD capabilities.

Our take. Engineers can prototype vectorized numeric code in Go without writing assembly, but must enable GOEXPERIMENT=simd, target amd64, and be prepared for possible API changes as the packages mature.

Leave knowing more.

Two ideas behind the headlines.

Trailing bytes after decompression can crash Express apps

Lesson 1 · From this edition

When an Express application uses body‑parser with its default settings, any incoming request that claims to be compressed (e.g., with `Content‑Encoding: gzip`) is piped straight into a decompression stream. The middleware does not attach an error listener to that stream, assuming the decoder will finish cleanly.

If the compressed payload ends with a valid gzip frame followed by arbitrary trailing bytes, the decoder finishes the first frame, then receives the extra data and emits an error. Because no listener is present, the error propagates as an uncaught exception, crashing the Node process before routing or authentication can occur.

In practice

POST /api/data HTTP/1.1\nHost: example.com\nContent-Encoding: gzip\nContent-Length: 42\n\n<gzip‑compressed‑frame><trailing‑bytes>

Keep this. Upgrade body‑parser to 2.4.0 or 1.20.9, or set `inflate: false` to reject compressed bodies, preventing the uncaught‑exception crash.

Async fileFilter callbacks can race with request teardown, causing unhandled errors

Lesson 2 · From this edition

Multer parses multipart uploads with busboy. When a fileFilter is declared async, Multer invokes it and waits for the callback before continuing. If the client aborts the request while that callback is still pending, Multer tears down the busboy stream. Later, the pending callback tries to resume the same stream, which now has no error listener. Busboy emits an "error" event that Node treats as unhandled, terminating the process.

The situation is a classic race condition: the request‑teardown path and the asynchronous filter completion path intersect. Because the error event is emitted after the stream has been destroyed, Node raises an uncaught exception, resulting in a denial‑of‑service crash. Upgrading to Multer 2.5.0 clears pending callbacks, and using a synchronous fileFilter avoids the race entirely.

In practice

// async fileFilter that delays validation function asyncFilter(req, file, cb) { setTimeout(() => { // simulate async check if (file.mimetype !== 'image/png') return cb(null, false); cb(null, true); }, 1000); } // If the client aborts the upload within that second, Multer 2.0‑2.4 will crash.

Keep this. Never let asynchronous validation continue after a request is closed; either use synchronous filters or ensure the callback is cancelled, and keep Multer updated to the patched version.

Make it stick.

5 questions. A little less forgetting.

Answers are saved on this device when storage is available.

1 / 5What condition in a gzip‑compressed request causes the uncaught‑exception crash when using body‑parser with default settings?

Read the answer

The compressed payload ends with a valid gzip frame followed by arbitrary trailing bytes

The lesson explains that when the gzip payload finishes a valid frame but includes extra trailing bytes, the decoder emits an error that has no listener, leading to an uncaught exception.

2 / 5Which mitigation does the lesson recommend to stop the crash caused by trailing bytes?

Read the answer

Upgrade body‑parser to version 2.4.0 (or 1.20.9)

The takeaway specifies upgrading body‑parser to 2.4.0 or 1.20.9 (or setting inflate:false) as the fix; the other options do not address the specific vulnerability.

3 / 5Why does the error from the decompression stream become an uncaught exception?

Read the answer

Because body‑parser does not attach any error listener to the decompression stream

The lesson states that the middleware assumes the decoder will finish cleanly and does not attach an error listener, so the emitted error propagates uncaught.

4 / 5What causes the process to crash when an async fileFilter is pending and the client aborts the request?

Read the answer

The pending callback tries to resume a destroyed busboy stream

When the client aborts, Multer tears down the busboy stream. The async fileFilter’s pending callback then attempts to resume that stream, which has no error listener, causing an unhandled error and crash.

5 / 5Which approach avoids the race condition by removing the asynchronous step?

Read the answer

Use a synchronous fileFilter

Using a synchronous fileFilter eliminates the pending callback that could race with request teardown, thereby preventing the race condition.

About this edition 3 sources

A curated selection of technology stories, with original reporting linked beneath each article. Written with AI assistance and checked against those sources.

Collected 24 October 2026–25 October 2026. Stories may refer to earlier events.