Skip to content

fix(deps): upgrade dependency hono to v4.11.4 [security] #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
renovate wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix(deps): upgrade dependency hono to v4.11.4 [security] #21

renovate wants to merge 1 commit into from

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Oct 22, 2025 •
edited
Loading

This PR contains the following updates:

Package Change Age Confidence
hono (source) 4.10.2 → 4.11.4 age confidence

GitHub Vulnerability Alerts

GHSA-q7jf-gf43-6x6p

Summary

A flaw in the CORS middleware allowed request Vary headers to be reflected into the response, enabling attacker-controlled Vary values and potentially affecting cache behavior.

Details

The middleware previously copied the Vary header from the request when origin was not set to "*". Since Vary is a response header that should only be managed by the server, this could allow an attacker to influence caching behavior or cause inconsistent CORS handling.

Most environments will see impact only when shared caches or proxies rely on the Vary header. The practical effect varies by configuration.

Impact

May cause cache key pollution and inconsistent CORS enforcement in certain setups. No direct confidentiality, integrity, or availability impact in default configurations.

Resolution

Update to the latest patched release. The CORS middleware has been corrected to handle Vary exclusively as a response header.

CVE-2026-22817

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)

import { jwt } from 'hono/jwt'

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

After (patched configuration)

import { jwt } from 'hono/jwt'

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

CVE-2026-22818

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)

import { jwk } from 'hono/jwk'

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

After (patched configuration)

import { jwk } from 'hono/jwk'

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

Release Notes

honojs/hono (hono)

v4.11.4

Compare Source

Security

Fixed a JWT algorithm confusion issue in the JWT and JWK/JWKS middleware.

Both middlewares now require an explicit algorithm configuration to prevent the verification algorithm from being influenced by untrusted JWT header values.

If you are using the JWT or JWK/JWKS middleware, please update to the latest version as soon as possible.

JWT middleware
import { jwt } from 'hono/jwt'

app.use(
  '/auth/*',
  jwt({
    secret: 'it-is-very-secret',
    alg: 'HS256', // required
  })
)
JWK/JWKS middleware
import { jwk } from 'hono/jwk'

app.use(
  '/auth/*',
  jwk({
    jwks_uri: 'https://example.com/.well-known/jwks.json',
    alg: ['RS256'], // required (asymmetric algorithms only)
  })
)

For more details, see the Security Advisory.

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.11.3...v4.11.4

v4.11.3

Compare Source

What's Changed

  • fix(types): fix middleware union type merging in MergeMiddlewareResponse by @​yusukebe in #​4602

Full Changelog: honojs/hono@v4.11.2...v4.11.3

v4.11.2

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.11.1...v4.11.2

v4.11.1

Compare Source

What's Changed

Full Changelog: honojs/hono@v4.11.0...v4.11.1

v4.11.0

Compare Source

Release Notes

Hono v4.11.0 is now available!

This release includes new features for the Hono client, middleware improvements, and an important type system fix.

Type System Fix for Middleware

We've fixed a bug in the type system for middleware. Previously, app did not have the correct type with pathless handlers:

const app = new Hono()
  .use(async (c, next) => {
    await next()
  })
  .get('/a', async (c, next) => {
    await next()
  })
  .get((c) => {
    return c.text('Hello')
  })

// app's type was incorrect

This has now been fixed.

Thanks @​kosei28!

Typed URL for Hono Client

You can now pass the base URL as the second type parameter to hc to get more precise URL types:

const client = hc<typeof app, 'http://localhost:8787'>(
  'http://localhost:8787/'
)

const url = client.api.posts.$url()
// url is TypedURL with precise type information
// including protocol, host, and path

This is useful when you want to use the URL as a type-safe key for libraries like SWR.

Thanks @​miyaji255!

Custom NotFoundResponse Type

You can now customize the NotFoundResponse type using module augmentation. This allows c.notFound() to return a typed response:

import { Hono, TypedResponse } from 'hono'

declare module 'hono' {
  interface NotFoundResponse
    extends Response,
      TypedResponse<{ error: string }, 404, 'json'> {}
}

const app = new Hono()
  .get('/posts/:id', async (c) => {
    const post = await getPost(c.req.param('id'))
    if (!post) {
      return c.notFound()
    }
    return c.json({ post }, 200)
  })
  .notFound((c) => c.json({ error: 'not found' }, 404))

Now the client can correctly infer the 404 response type.

Thanks @​miyaji255!

tryGetContext Helper

The new tryGetContext() helper in the Context Storage middleware returns undefined instead of throwing an error when the context is not available:

import { tryGetContext } from 'hono/context-storage'

const context = tryGetContext<Env>()
if (context) {
  // Context is available
  console.log(context.var.message)
}

Thanks @​AyushCoder9!

Custom Query Serializer

You can now customize how query parameters are serialized using the buildSearchParams option:

const client = hc<AppType>('http://localhost', {
  buildSearchParams: (query) => {
    const searchParams = new URLSearchParams()
    for (const [k, v] of Object.entries(query)) {
      if (v === undefined) continue
      if (Array.isArray(v)) {
        v.forEach((item) => searchParams.append(`${k}[]`, item))
      } else {
        searchParams.set(k, v)
      }
    }
    return searchParams
  },
})

Thanks @​bolasblack!

New features

  • feat(types): make Hono client's $url return the exact URL type #​4502
  • feat(types): enhance NotFoundHandler to support custom NotFoundResponse type #​4518
  • feat(timing): add wrapTime to simplify usage #​4519
  • feat(pretty-json): support force option #​4531
  • feat(client): add buildSearchParams option to customize query serialization #​4535
  • feat(context-storage): add optional tryGetContext helper #​4539
  • feat(secure-headers): add CSP report-to and report-uri directive support #​4555
  • fix(types): replace schema-based path tracking with CurrentPath parameter #​4552

All changes

New Contributors

Full Changelog: honojs/hono@v4.10.8...v4.11.0

v4.10.8

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.10.7...v4.10.8

v4.10.7

Compare Source

What's Changed
New Contributors

Full Changelog: honojs/hono@v4.10.6...v4.10.7

v4.10.6

Compare Source

Deperecated
bearer-auth options

The following options are deprecated and will be removed in a future version:

  • noAuthenticationHeaderMessage => use noAuthenticationHeader.message
  • invalidAuthenticationHeaderMessage => use invalidAuthenticationHeader.message
  • invalidTokenMessage => use invalidToken.message
What's Changed
New Contributors

Full Changelog: honojs/hono@v4.10.5...v4.10.6

v4.10.5

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.10.4...v4.10.5

v4.10.4

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.10.3...v4.10.4

v4.10.3

Compare Source

Securiy Fix

A security issue in the CORS middleware has been fixed. In some cases, a request header could affect the Vary response header. Please update to the latest version if you are using the CORS middleware.

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.10.2...v4.10.3

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot added dependencies Pull requests that update a dependency file optional labels Oct 22, 2025
@renovate renovate bot changed the title fix(deps): upgrade dependency hono to v4.10.2 [security] fix(deps): upgrade dependency hono to v4.10.2 [security] - autoclosed Oct 22, 2025
@renovate renovate bot closed this Oct 22, 2025
@renovate renovate bot deleted the renovate/npm-hono-vulnerability branch October 22, 2025 18:31
@renovate renovate bot changed the title fix(deps): upgrade dependency hono to v4.10.2 [security] - autoclosed fix(deps): upgrade dependency hono to v4.10.3 [security] Oct 24, 2025
@renovate renovate bot reopened this Oct 24, 2025
@renovate renovate bot force-pushed the renovate/npm-hono-vulnerability branch 2 times, most recently from 94d8971 to 2670eb6 Compare October 24, 2025 19:42
@renovate renovate bot force-pushed the renovate/npm-hono-vulnerability branch from 2670eb6 to b75b019 Compare January 14, 2026 00:53
@renovate renovate bot changed the title fix(deps): upgrade dependency hono to v4.10.3 [security] fix(deps): upgrade dependency hono to v4.11.4 [security] Jan 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file optional

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant