Hono IP Spoofing: When 255 + 100 Equals Access

Hono has built a reputation as the "Ultrafast" web framework for the edge, running on Cloudflare Workers, Deno, and Bun. It is sleek, minimal, and generally delightful to use. However, when you prioritize speed and minimalism, sometimes the boring, gritty details of input validation get glossed over.

In the world of middleware, the IP Restriction Middleware is the bouncer. It checks your ID (IP address) against a list of VIPs (allowlist) or troublemakers (blocklist). If the bouncer is doing their job, only the right people get in.

But in Hono versions prior to 4.11.7, the bouncer had a serious vision problem. They weren't checking if your ID was valid; they were just checking if it looked like an ID from a distance. This vulnerability isn't a complex memory corruption in C; it's a beautiful example of how loose Regular Expressions and loose typing in JavaScript can combine to create a perfect logic flaw.

The root of the issue lies in how Hono decided what constitutes a valid IPv4 address. You might expect a strict check ensuring four octets, each between 0 and 255. Instead, the developers used a regex that was... optimistic.

Here is the culprit found in src/utils/ipaddr.ts:

const IPV4_REGEX = /^[0-9]{0,3}\.[0-9]{0,3}\.[0-9]{0,3}\.[0-9]{0,3}$/

See the problem? [0-9]{0,3} matches any 0 to 3 digit number. That includes 0, 255, and unfortunately, 999. It creates a syntactic check (is it digit-dot-digit?) rather than a semantic check (is it a valid byte?).

If the validation stopped there, the application might just crash or throw an error when handling invalid IPs. But the second part of the flaw is how this string is converted into a number for comparison. Hono converts IPs to binary integers to perform fast CIDR matching. The math used to convert these octets assumed that no input would ever exceed 255. When that assumption fails, we enter the realm of integer overflows.

Let's look at the convertIPv4ToBinary function. This is where the magic happens—and by magic, I mean the unintended transmutation of numbers.

// The vulnerable logic
return (parts[0] << 24) + (parts[1] << 16) + (parts[2] << 8) + parts[3]

In a strongly typed language, putting 355 into a uint8 container would throw an error or wrap around immediately. In JavaScript, parts[3] is just a number. If parts[3] is 355, it is added to the total sum.

Here is the kicker: parts[2] << 8 shifts the third octet 8 bits to the left. If parts[3] is larger than 255 (8 bits), it spills over into the space occupied by parts[2].

It is effectively performing addition where the developer intended concatenation. This allows an attacker to modify the third octet by overloading the fourth octet.

Let's construct a Proof of Concept. Suppose there is an internal admin panel allowlisted strictly for the IP 1.2.3.99. You are an attacker sitting at 1.2.2.x. You cannot natively change your IP to 1.2.3.99 without routing issues, but you can send a header (if the server trusts proxies) or spoof a packet that Hono interprets as the target.

We need to construct an IP 1.2.2.X that resolves to 1.2.3.99.

The Target: Octet 3 = 3 Octet 4 = 99

The Input: Octet 3 = 2 Octet 4 = ?

We need (2 << 8) + X to equal (3 << 8) + 99.

1. Target Value: (3 * 256) + 99 = 768 + 99 = 867
2. Current Value: (2 * 256) = 512
3. The Difference: 867 - 512 = 355

So, if we send the IP 1.2.2.355:

The middleware sees 1.2.3.99, checks the allowlist, sees a match, and opens the door. You have successfully spoofed an IP address without actually spoofing any packets on the network layer.

The remediation is straightforward: stop accepting garbage input. The Hono team patched this in version 4.11.7 by replacing the lazy regex with a strict one that validates the 0-255 range.

Commit edbf6eea8e6c26a3937518d4ed91d8666edeec37 changes:

// The Fix
const IPV4_OCTET_PART = '(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])'
const IPV4_REGEX = new RegExp(`^(?:${IPV4_OCTET_PART}\\.){3}${IPV4_OCTET_PART}$`)

This new regex explicitly matches:

• 250-255
• 200-249
• 100-199
• 0-99

By ensuring the octets never exceed 255 strictly at the parsing stage, the bitwise math downstream is safe from overflow. It is a classic example of "Input Validation 101": validate constraints at the boundary, not deep in the business logic.