Hono formData() after text() silently corrupts binary file uploads

Hono caches each body representation a handler reads (text(), json(), arrayBuffer(), formData() and so on) and converts between them when the body is read again in a different way. In September 2026, honojs/hono#5366 fixed a gap in that conversion. Rebuilding the body through a bare Response dropped the request's media type, so calling formData() after text() threw. The fix carries the original Content-Type over.

We included this pull request in our backtest as a control: no later fix or revert cites it. When we replayed it through Warpway on 2026-10-07, using only what existed before merge, Warpway flagged it anyway, and the finding turned out to be a real bug that nobody had reported. We reproduced it on the latest release and filed it upstream as honojs/hono#5539.

The change

const contentType = anyCachedKey === 'formData' ? undefined : raw.headers.get('content-type');
return new Response(body, {
  headers: contentType ? { 'Content-Type': contentType } : undefined,
})[key]();

How the bug works

When a handler calls c.req.text(), the runtime decodes the whole request body as UTF-8 and Hono caches the resulting string. A multipart upload is not valid UTF-8 when it contains binary file parts, so every invalid byte becomes the replacement character U+FFFD during decoding. That information is gone.

Before #5366, a later formData() call rebuilt a Response from that string without a media type, and the runtime refused to parse it. After #5366, the original multipart/form-data header is carried over, so parsing succeeds, but on the damaged text. The file comes back with EF BF BD (U+FFFD encoded as UTF-8) wherever the upload had a byte such as 0xFF. Nothing throws, so nothing tells you.

Reproduce it

We independently repeated the reproduction with Hono 4.13.13 and Node.js 24 on October 8, 2026. The server returned HTTP 200, with uploaded bytes [255, 0, 65] changed to [239, 191, 189, 0, 65]. The model review identified the scenario through repository investigation; this runtime check separately confirmed the byte transformation.

• Original recorded review JSON
• Reviewed PR and pinned commits
• Recorded models and review configuration
• Reproduction output, version and timestamp
• Download the reproduction script

To repeat the check, use an empty directory with Node.js 24, install hono@4.13.13, save the downloaded script as reproduce.mjs, and run node reproduce.mjs.

import { Hono } from 'hono';

const app = new Hono();
app.post('/', async (c) => {
  await c.req.text();
  const file = (await c.req.formData()).get('file');
  return c.json([...new Uint8Array(await file.arrayBuffer())]);
});

const fd = new FormData();
fd.append('file', new Blob([new Uint8Array([0xff, 0x00, 0x41])]), 'x.bin');
console.log(await (await app.request('/', { method: 'POST', body: fd })).text());

Are you affected?

You are affected on Hono 4.13.8 or later if something reads a multipart request as text before your handler parses the form. Typical cases are middleware that logs or hashes the raw body, and webhook handlers that verify a signature over the body text. Uploads containing only text survive, which is why tests with ASCII form fields pass.

Workaround

Read the raw bytes first and decode them yourself. Hono then rebuilds the form from the original bytes, and file contents are preserved. We verified this on 4.13.13:

app.post('/upload', async (c) => {
  const bytes = new Uint8Array(await c.req.arrayBuffer());
  const text = new TextDecoder().decode(bytes); // for logging or signatures
  const form = await c.req.formData(); // file bytes intact
  // ...
});