Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
52 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
serveStatic decodes the request path a second time after Hono has already decoded it for routing. A crafted request can be routed as one path and served as another, so middleware mounted on a static prefix does not run for a file under that prefix. Details Hono decodes the request path once before routing. serveStatic decoded it again before resolving the file. With a malformed percent-encoded sequence, the first decode leaves part of the path encoded, the router matches the encoded form, and the second decode resolves the real directory. The file is still resolved inside the configured root; this is not a traversal outside it. Impact An unauthenticated attacker may reach static files without the middleware on their prefix running, for example an authentication check. This affects applications that mount middleware on part of the directory served by serveStatic. Applications that serve only public files are not affected.
Recommended action: Upgrade to 4.13.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
hono/jsx does not HTML-escape a plain string placed directly as a child or fallback of Suspense or ErrorBoundary, as the only child of a Context.Provider, or as the root value of renderToString() / renderToReadableStream() from hono/jsx/dom/server. Such a string is emitted as markup instead of text. Details These paths stringify their input and treat the result as already-escaped HTML, so a plain string passes through unchanged. Notable cases: - Suspense: a string child, or a string fallback while a child suspends. With streaming, the fallback reaches the browser in the initial chunk. - ErrorBoundary: a string child alongside an asynchronous sibling. The all-synchronous case was fixed in 4.11.7 (GHSA-9r54-q6cx-xmh5). - Context.Provider: a single string child. Multiple children are escaped. - hono/jsx/dom/server: a string, or an array containing strings, passed as the root. A lone {children} forwarded by a wrapper component is enough to reach these paths. Strings wrapped in an…
Recommended action: Upgrade to 4.13.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix released for CVE-2026-39408 does not cover every traversal sequence. toSSG() can still write files outside the configured output directory when a route parameter contains consecutive parent-directory segments. Details Static site generation builds each output path from the route path and the values supplied through ssgParams, then verifies that the result stays inside the output directory. That check normalizes the path with the same routine that built it, and the routine did not fully collapse runs of consecutive parent-directory segments. A value carrying enough of them produces a path the check accepts, but the filesystem resolves outside the output directory. The earlier fix handled a single parent-directory segment, so it blocks the sequence reported at the time while leaving longer runs unhandled. The check also treated output directories that differ only in how they are rooted as equivalent. This arises when an application generates a static site from route…
Recommended action: Upgrade to 4.13.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When parseBody() expands dot-separated form field names into nested objects, it does not limit the nesting depth or the total number of objects created. A request body well within a normal size limit can therefore allocate an object graph far larger than the request itself, and concurrent requests can exhaust the heap and terminate the process. Details Each dot-separated segment of a field name creates an intermediate object. Neither the segments within a single field name nor the total across a request was bounded, and empty segments were preserved, so a field name could encode one nesting level per byte. Both shapes produce the effect: a single deeply dotted field name, and a large number of shallowly dotted ones within one body. A request body size limit does not prevent it, because the amplification happens after the body has been accepted. Dot-notation parsing is not enabled by default. Impact An attacker who can reach an endpoint that parses request bodies with…
Recommended action: Upgrade to 4.13.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Hono's query parsing does not stop at the URL fragment: a ? appearing after a is treated as the start of a query string. As a result, the application can read request parameters that no other component involved in handling the request can see. Details A fragment is never part of the query, and every standard URL consumer — browsers, new URL(), reverse proxies — ignores everything from the first onward. Hono's routing followed that rule; its query helpers did not. For one and the same request, this produces an interpretation differential: - A component in front of the application that inspects the query string — filtering rules, parameter allow/deny lists, access logging — observes no parameters, while the application reads and acts on them. - The cache middleware removed the fragment when building its cache key, so a response influenced by parameters carried inside the fragment could be stored under a key that did not reflect them and later returned to other users. The…
Recommended action: Upgrade to 4.13.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
memo() from hono/jsx retains the result of a server-side render and reuses it for later renders with comparator-equal props. Request-scoped values read inside the component take no part in that comparison, so a response can contain HTML rendered for another user's request. Details Components wrapped with memo() are compared by props alone. Values read implicitly during rendering do not participate: JSX Context through createContext() and useContext(), useRequestContext() from hono/jsx-renderer, and getContext() from hono/context-storage. The retained result lives as long as the wrapped component, so it outlives the request that produced it. Per-request context isolation is not what fails: the current request's values are established correctly, but the memoized component is skipped before anything reads them. This issue arises when a component wrapped in memo() obtains user- or request-specific data from an ambient context instead of through props. Impact A user may receive a…
Recommended action: Upgrade to 4.12.34 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Proxy Helper (hono/proxy) does not remove response headers named by the origin's Connection header. Headers that the origin marked as connection-scoped are therefore forwarded to clients. Details Per RFC 9110 Section 7.6.1, an intermediary must remove the header fields listed in a message's Connection header field before forwarding the message, in addition to the well-known hop-by-hop headers. The proxy() function removed the well-known hop-by-hop headers (including Connection itself) from origin responses, but did not remove the headers that the response's Connection header field designated as connection-scoped. This issue arises when an application proxies responses from an origin that declares additional, non-standard headers as hop-by-hop via the Connection response header. Impact A client may receive response headers that the origin intended only for its immediate peer. This may lead to: - Disclosure of connection-scoped or internal metadata contained in such headers…
Recommended action: Upgrade to 4.12.34 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The languageDetector middleware is vulnerable to algorithmic complexity denial of service when processing a crafted language tag containing a large number of hyphen-separated subtags. Details To implement progressive language-tag truncation, normalizeLanguage() repeatedly calls parts.slice(0, i).join('-') for every possible prefix. The total amount of string processing grows quadratically with the number of subtags. Language values may come from a query parameter, cookie, Accept-Language header, or URL path, depending on the detector configuration. The default detector order enables query-string, cookie, and header detection, so applications using languageDetector() may expose this processing to unauthenticated requests. Request-size limits reduce the maximum cost of a single request but do not eliminate the issue. Inputs accepted by common JavaScript runtimes can still cause noticeable synchronous event-loop blocking. Impact An attacker may repeatedly send requests…
Recommended action: Upgrade to 4.12.34 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The built-in CORS middleware (hono/cors) parses the attacker-controlled Access-Control-Request-Headers request header during a preflight (OPTIONS) request using a regular expression whose running time is quadratic in the input length. A single request carrying a long run of whitespace can consume seconds of CPU, and repeated requests can render the service unresponsive. This parsing runs under the default configuration. Details On a CORS preflight, when allowHeaders is not configured - the default - the middleware reflects and parses the Access-Control-Request-Headers value. The parser used a whitespace-tolerant regular expression whose backtracking makes the work grow quadratically (O(n²)) with the length of the value when it contains a long whitespace sequence without a delimiter. Because the header value is bounded only by the deployment's maximum HTTP header size, a single preflight can block request processing for a noticeable amount of time; on runtimes that share one…
Recommended action: Upgrade to 4.12.34 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.12.27 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.12.27 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The AWS API Gateway v1 adapter can drop a distinct repeated request header value. When a header appears multiple times, the adapter de-duplicates values using a substring comparison instead of an exact match, so a value that is a substring of another value of the same header is omitted (for example, 203.0.113.1 is dropped when another value is 203.0.113.10). Details A repeated request header carries an ordered list of values. Middleware or application logic that depends on the complete list — such as IP restriction that walks the X-Forwarded-For chain, rate limiting, audit logging, or proxy-chain validation — can therefore receive incomplete data that differs from what the client actually sent. This issue arises on deployments using the AWS API Gateway v1 adapter (the same pattern also affects the VPC Lattice adapter), for requests that contain the same header more than once. Impact An attacker can craft repeated header values so that one value is omitted before the…
Recommended action: Upgrade to 4.12.27 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Body Limit Middleware trusts the request's Content-Length header to decide whether a body is within the limit. On AWS Lambda (API Gateway v1/v2, ALB, VPC Lattice, and Lambda@Edge) the body is delivered fully buffered and the adapter builds the request with the client-declared Content-Length, which need not match the actual payload. A client can declare a tiny Content-Length while sending a much larger body, slipping past the limit. Details When Content-Length is present and Transfer-Encoding is absent, the middleware compares the declared value against the limit and passes the request through if it is small enough. On standards-based runtimes the transport enforces that Content-Length matches the body, so this is safe. The Lambda adapters instead reconstruct the request from a buffered payload and copy the client's Content-Length verbatim, so the declared length and the real body size are decoupled. This issue affects applications deployed on AWS Lambda that rely on the…
Recommended action: Upgrade to 4.12.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On AWS Lambda@Edge, CloudFront delivers a request header that appears more than once as several separate entries. The adapter writes each value with Headers.set instead of Headers.append, so every value overwrites the previous one and only the last reaches the application. Repeated request headers such as X-Forwarded-For, Forwarded, and Via are silently truncated to a single value. Details A repeated request header carries an ordered list of values. The adapter iterates the list but overwrites on each step, keeping only the final value. Middleware that depends on the full list — for example IP restriction that walks the X-Forwarded-For chain, or auditing based on Forwarded/Via hops — receives incomplete data. The API Gateway adapter already appends repeated values and is not affected. This issue arises only on Lambda@Edge deployments, for requests that contain the same header more than once. Impact Request middleware sees only the last value of a repeated header instead of…
Recommended action: Upgrade to 4.12.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
With credentials: true and no explicit origin (the default wildcard), the CORS Middleware reflects the request's Origin and sends Access-Control-Allow-Credentials: true. Any site can then make credentialed cross-origin requests and read the responses, exposing cookie-authenticated endpoints to arbitrary origins. Details The spec forbids Access-Control-Allow-Origin: with credentials and browsers reject it, so this configuration used to fail closed. In affected versions the middleware reflects the request Origin instead, so it now succeeds for every origin, including null. The preflight also echoes the requested headers back, approving non-simple credentialed requests too. This issue arises when an application enables credentials: true and leaves origin unset or set to the wildcard. Impact Any third-party page a logged-in user visits can read the application's cookie-authenticated endpoints and perform credentialed state-changing requests. This affects applications that enable…
Recommended action: Upgrade to 4.12.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On Windows hosts, an encoded backslash (%5C) in the request path decodes to \, which the Windows path resolver treats as a separator. serve-static then resolves a single URL segment such as admin\secret.txt into a nested file under the root and serves it, letting an attacker read static files meant to be protected behind prefix-mounted middleware. Directory escape (..) remains blocked. Details The router splits paths only on /, so /admin%5Csecret.txt is one segment and middleware on /admin/ does not run. The serve-static guard rejects ./.. and consecutive separators but lets a lone \ through; on Windows the file resolver re-splits it into the protected subtree. This affects Windows hosts serving static files via the Node, Bun, or Deno adapters that guard a static subtree with prefix-mounted middleware. Impact An unauthenticated attacker can read static files under a middleware-guarded prefix on Windows hosts. The read stays within the configured root; escape outside the root…
Recommended action: Upgrade to 4.12.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On AWS Lambda, the ALB single-header response and the VPC Lattice v2 response join multiple Set-Cookie headers into one comma-separated value. Because commas also appear inside cookie attributes (for example Expires dates), clients cannot split the value back into individual cookies and silently drop or misparse them. Details Per RFC 6265, each cookie must be its own Set-Cookie header line, and commas may appear inside attribute values. Joining cookies with ", " collides with those commas, producing a value that clients cannot reliably split. Only ALB single-header mode and VPC Lattice v2 are affected; API Gateway v1/v2 and ALB with multi-value headers enabled already use an array and are unaffected. Impact A client may receive only one of the cookies, a malformed cookie, or none. Session, CSRF, or preference cookies can silently fail to apply, breaking sessions or forcing re-authentication. This affects applications that set multiple cookies per response and run on AWS…
Recommended action: Upgrade to 4.12.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
app.mount() strips the mount prefix from the incoming request path using the raw URL pathname, while route matching is performed against the percent-decoded path. This inconsistency causes the prefix to be stripped at the wrong position when the path contains percent-encoded multi-byte characters, resulting in the mounted sub-application receiving an incorrect path. Details When app.mount(prefix, subApp) is called, Hono calculates the number of characters to strip based on the decoded mount prefix length, but then applies that slice to the raw URL pathname. When the URL contains percent-encoded characters that expand to fewer characters when decoded (such as encoded non-ASCII characters), the two representations have different lengths, so the prefix is stripped at the wrong byte offset. As a result, the sub-application receives a path that does not correspond to the intended sub-path — it may receive a partial or garbled path instead of the expected value after the mount…
Recommended action: Upgrade to 4.12.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.12.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The serialize() function in hono/cookie validates domain and path options against characters that corrupt Set-Cookie header syntax (;, \r, \n), but does not apply the same validation to sameSite and priority. An application that passes user-controlled input into either option may produce a Set-Cookie response header containing attacker-chosen additional attributes. Details When constructing a Set-Cookie header value, serialize() appends the sameSite and priority option values directly into the output string after a presentation-only transformation (capitalizing the first character). Although the TypeScript type signature constrains these options to specific string literals, that constraint is not enforced at runtime; any string value, including one containing ; or line-feed characters, passes through unchanged. The validation guard that rejects ;, \r, and \n from domain and path is not applied to sameSite or priority. An application that passes a request-derived value to…
Recommended action: Upgrade to 4.12.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 —…
Recommended action: Upgrade to 4.12.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The JSX renderer escapes style attribute object values for HTML but not for CSS. Untrusted input in a style object value or property name can therefore inject additional CSS declarations into the rendered style attribute. The impact is limited to CSS and does not allow JavaScript execution or HTML attribute breakout. Details style object values are serialized into a CSS declaration list and escaped for HTML attribute context only. Characters that act as CSS declaration boundaries — such as ;, comment markers, quoted strings, and block delimiters — are valid in HTML attribute content and can extend a value beyond its assigned property. This issue arises when untrusted input is interpolated into a JSX style object and rendered server-side. Impact An attacker who can control the value or property name of a style object may inject arbitrary CSS declarations. This may lead to: - Visual manipulation of the page, including full-viewport overlays usable for phishing - Outbound…
Recommended action: Upgrade to 4.12.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Improper validation of the JWT NumericDate claims exp, nbf, and iat in hono/utils/jwt allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches verify() — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control. Details The validation routine combined option, presence, and threshold checks in a single short-circuiting expression, so several classes of malformed values were silently skipped instead of rejected: - A falsy numeric value short-circuited the presence check. - A non-finite numeric value compared as never-after-now and never-expired. - A non-numeric type produced NaN comparisons that evaluated false. This deviates from RFC 7519 §4.1.4, which defines NumericDate as a finite JSON numeric value. Impact An actor able to issue tokens accepted by the application may craft…
Recommended action: Upgrade to 4.12.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.12.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.12.16 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.