github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 15:42:09 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[PR #5490] [MERGED] chore(deps): update dependency hono to v4.10.2 [security] #22936

New Issue
Closed
opened 2026-04-15 21:22:41 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-15 21:22:41 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/better-auth/better-auth/pull/5490
Author: @renovate[bot]
Created: 10/22/2025
Status: ✅ Merged
Merged: 10/22/2025
Merged by: @himself65

Base: canary ← Head: renovate/npm-hono-vulnerability

📝 Commits (1)

  • 67195e9 chore(deps): update dependency hono to v4.10.2 [security]

📊 Changes

1 file changed (+5 additions, -5 deletions)

View changed files

📝 pnpm-lock.yaml (+5 -5)

📄 Description

This PR contains the following updates:

Package Change Age Confidence
hono (source) 4.9.7 -> 4.10.2 age confidence

GitHub Vulnerability Alerts

GHSA-m732-5p4w-x69g

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:

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.

Release Notes

honojs/hono (hono)

v4.10.2

Compare Source

v4.10.1

Compare Source

What's Changed

Full Changelog: https://github.com/honojs/hono/compare/v4.10.0...v4.10.1

v4.10.0

Compare Source

Release Notes

Hono v4.10.0 is now available!

This release brings improved TypeScript support and new utilities.

The main highlight is the enhanced middleware type definitions that solve a long-standing issue with type safety for RPC clients.

Middleware Type Improvements

Imagine the following app:

import { Hono } from 'hono'

const app = new Hono()

const routes = app.get(
  '/',
  (c) => {
    return c.json({ errorMessage: 'Error!' }, 500)
  },
  (c) => {
    return c.json({ message: 'Success!' }, 200)
  }
)

The client with RPC:

import { hc } from 'hono/client'

const client = hc<typeof routes>('/')

const res = await client.index.$get()

if (res.status === 500) {
}

if (res.status === 200) {
}

Previously, it couldn't infer the responses from middleware, so a type error was thrown.

CleanShot 2025-10-17 at 06 51 48@​2x

Now the responses are correctly typed.

CleanShot 2025-10-17 at 06 54 13@​2x

This was a long-standing issue and we were thinking it was super difficult to resolve it. But now come true.

Thank you for the great work @​slawekkolodziej!

cloneRawRequest Utility

The new cloneRawRequest utility allows you to clone the raw Request object after it has been consumed by validators or middleware.

import { cloneRawRequest } from 'hono/request'

app.post('/api', async (c) => {
  const body = await c.req.json()

  // Clone the consumed request
  const clonedRequest = cloneRawRequest(c.req)
  await externalLibrary.process(clonedRequest)
})

Thanks @​kamaal111!

New features

  • feat(types): passing middleware types #​4393
  • feat(ssg): add default plugin that defines the recommended behavior #​4394
  • feat(request): add cloneRawRequest utility for request cloning #​4382

All changes

New Contributors

Full Changelog: https://github.com/honojs/hono/compare/v4.9.12...v4.10.0

v4.9.12

Compare Source

What's Changed

  • refactor: internal structure of PreparedRegExpRouter for optimization and added tests by @​usualoma in #​4456
  • refactor: use protected methods instead of computed properties to allow tree shaking by @​usualoma in #​4458

Full Changelog: https://github.com/honojs/hono/compare/v4.9.11...v4.9.12

v4.9.11

Compare Source

What's Changed

New Contributors

Full Changelog: https://github.com/honojs/hono/compare/v4.9.10...v4.9.11

v4.9.10

Compare Source

What's Changed

Full Changelog: https://github.com/honojs/hono/compare/v4.9.9...v4.9.10

v4.9.9

Compare Source

What's Changed

New Contributors

Full Changelog: https://github.com/honojs/hono/compare/v4.9.8...v4.9.9

v4.9.8

Compare Source

What's Changed

New Contributors

Full Changelog: https://github.com/honojs/hono/compare/v4.9.7...v4.9.8

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 these updates again.

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

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

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/better-auth/better-auth/pull/5490 **Author:** [@renovate[bot]](https://github.com/apps/renovate) **Created:** 10/22/2025 **Status:** ✅ Merged **Merged:** 10/22/2025 **Merged by:** [@himself65](https://github.com/himself65) **Base:** `canary` ← **Head:** `renovate/npm-hono-vulnerability` --- ### 📝 Commits (1) - [`67195e9`](https://github.com/better-auth/better-auth/commit/67195e9855f234a61e0c499d020fcaf99ecab805) chore(deps): update dependency hono to v4.10.2 [security] ### 📊 Changes **1 file changed** (+5 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `pnpm-lock.yaml` (+5 -5) </details> ### 📄 Description This PR contains the following updates: | Package | Change | Age | Confidence | |---|---|---|---| | [hono](https://hono.dev) ([source](https://redirect.github.com/honojs/hono)) | [`4.9.7` -> `4.10.2`](https://renovatebot.com/diffs/npm/hono/4.9.7/4.10.2) | [![age](https://developer.mend.io/api/mc/badges/age/npm/hono/4.10.2?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/hono/4.9.7/4.10.2?slim=true)](https://docs.renovatebot.com/merge-confidence/) | ### GitHub Vulnerability Alerts #### [GHSA-m732-5p4w-x69g](https://redirect.github.com/honojs/hono/security/advisories/GHSA-m732-5p4w-x69g) ### 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](https://redirect.github.com/honojs/hono/blob/db764c2f1d8a2905d66c78c41aa47e47d3a4165d/src/utils/jwt/jwt.ts#L99-L156), 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. --- ### Release Notes <details> <summary>honojs/hono (hono)</summary> ### [`v4.10.2`](https://redirect.github.com/honojs/hono/compare/v4.10.1...0c6455dc10db6428257bdd601eca559247e27de6) [Compare Source](https://redirect.github.com/honojs/hono/compare/v4.10.1...v4.10.2) ### [`v4.10.1`](https://redirect.github.com/honojs/hono/releases/tag/v4.10.1) [Compare Source](https://redirect.github.com/honojs/hono/compare/v4.10.0...v4.10.1) #### What's Changed - fix(types): cannot `.use` non-return mw from `createMiddleware` by [@&#8203;NamesMT](https://redirect.github.com/NamesMT) in [#&#8203;4465](https://redirect.github.com/honojs/hono/pull/4465) **Full Changelog**: <https://github.com/honojs/hono/compare/v4.10.0...v4.10.1> ### [`v4.10.0`](https://redirect.github.com/honojs/hono/releases/tag/v4.10.0) [Compare Source](https://redirect.github.com/honojs/hono/compare/v4.9.12...v4.10.0) ### Release Notes Hono v4.10.0 is now available! This release brings improved TypeScript support and new utilities. The main highlight is the enhanced middleware type definitions that solve a long-standing issue with type safety for RPC clients. #### Middleware Type Improvements Imagine the following app: ```ts import { Hono } from 'hono' const app = new Hono() const routes = app.get( '/', (c) => { return c.json({ errorMessage: 'Error!' }, 500) }, (c) => { return c.json({ message: 'Success!' }, 200) } ) ``` The client with RPC: ```ts import { hc } from 'hono/client' const client = hc<typeof routes>('/') const res = await client.index.$get() if (res.status === 500) { } if (res.status === 200) { } ``` Previously, it couldn't infer the responses from middleware, so a type error was thrown. <img width="1538" height="724" alt="CleanShot 2025-10-17 at 06 51 48@&#8203;2x" src="https://github.com/user-attachments/assets/7e660db0-6c52-4249-9a3d-2932614bbace" /> Now the responses are correctly typed. <img width="1586" height="876" alt="CleanShot 2025-10-17 at 06 54 13@&#8203;2x" src="https://github.com/user-attachments/assets/ef6136f1-bc26-4625-9238-0aec25110efc" /> *** This was a long-standing issue and we were thinking it was super difficult to resolve it. But now come true. Thank you for the great work [@&#8203;slawekkolodziej](https://redirect.github.com/slawekkolodziej)! #### cloneRawRequest Utility The new `cloneRawRequest` utility allows you to clone the raw Request object after it has been consumed by validators or middleware. ```ts import { cloneRawRequest } from 'hono/request' app.post('/api', async (c) => { const body = await c.req.json() // Clone the consumed request const clonedRequest = cloneRawRequest(c.req) await externalLibrary.process(clonedRequest) }) ``` Thanks [@&#8203;kamaal111](https://redirect.github.com/kamaal111)! #### New features - feat(types): passing middleware types [#&#8203;4393](https://redirect.github.com/honojs/hono/pull/4393) - feat(ssg): add default plugin that defines the recommended behavior [#&#8203;4394](https://redirect.github.com/honojs/hono/pull/4394) - feat(request): add cloneRawRequest utility for request cloning [#&#8203;4382](https://redirect.github.com/honojs/hono/pull/4382) #### All changes - feat(types): passing middleware types by [@&#8203;slawekkolodziej](https://redirect.github.com/slawekkolodziej) in [#&#8203;4393](https://redirect.github.com/honojs/hono/pull/4393) - feat(ssg): add default plugin that defines the recommended behavior by [@&#8203;3w36zj6](https://redirect.github.com/3w36zj6) in [#&#8203;4394](https://redirect.github.com/honojs/hono/pull/4394) - feat(request): add cloneRawRequest utility for request cloning by [@&#8203;kamaal111](https://redirect.github.com/kamaal111) in [#&#8203;4382](https://redirect.github.com/honojs/hono/pull/4382) - fix(proxy): Correct hop-by-hop header handling per RFC 9110 by [@&#8203;sugar-cat7](https://redirect.github.com/sugar-cat7) in [#&#8203;4459](https://redirect.github.com/honojs/hono/pull/4459) #### New Contributors - [@&#8203;slawekkolodziej](https://redirect.github.com/slawekkolodziej) made their first contribution in [#&#8203;4393](https://redirect.github.com/honojs/hono/pull/4393) - [@&#8203;kamaal111](https://redirect.github.com/kamaal111) made their first contribution in [#&#8203;4382](https://redirect.github.com/honojs/hono/pull/4382) **Full Changelog**: <https://github.com/honojs/hono/compare/v4.9.12...v4.10.0> ### [`v4.9.12`](https://redirect.github.com/honojs/hono/releases/tag/v4.9.12) [Compare Source](https://redirect.github.com/honojs/hono/compare/v4.9.11...v4.9.12) #### What's Changed - refactor: internal structure of `PreparedRegExpRouter` for optimization and added tests by [@&#8203;usualoma](https://redirect.github.com/usualoma) in [#&#8203;4456](https://redirect.github.com/honojs/hono/pull/4456) - refactor: use protected methods instead of computed properties to allow `tree shaking` by [@&#8203;usualoma](https://redirect.github.com/usualoma) in [#&#8203;4458](https://redirect.github.com/honojs/hono/pull/4458) **Full Changelog**: <https://github.com/honojs/hono/compare/v4.9.11...v4.9.12> ### [`v4.9.11`](https://redirect.github.com/honojs/hono/releases/tag/v4.9.11) [Compare Source](https://redirect.github.com/honojs/hono/compare/v4.9.10...v4.9.11) #### What's Changed - fix(types): fix 4.9.8 regression by [@&#8203;aadito123](https://redirect.github.com/aadito123) in [#&#8203;4448](https://redirect.github.com/honojs/hono/pull/4448) - feat(reg-exp-router): Introduced PreparedRegExpRouter by [@&#8203;usualoma](https://redirect.github.com/usualoma) in [#&#8203;1796](https://redirect.github.com/honojs/hono/pull/1796) #### New Contributors - [@&#8203;aadito123](https://redirect.github.com/aadito123) made their first contribution in [#&#8203;4448](https://redirect.github.com/honojs/hono/pull/4448) **Full Changelog**: <https://github.com/honojs/hono/compare/v4.9.10...v4.9.11> ### [`v4.9.10`](https://redirect.github.com/honojs/hono/releases/tag/v4.9.10) [Compare Source](https://redirect.github.com/honojs/hono/compare/v4.9.9...v4.9.10) #### What's Changed - fix(context): Fix [#&#8203;4427](https://redirect.github.com/honojs/hono/issues/4427) type regression by removing non-public export by [@&#8203;aantthony](https://redirect.github.com/aantthony) in [#&#8203;4433](https://redirect.github.com/honojs/hono/pull/4433) - fix(aws-lambda): sanitize non-ASCII header values to prevent ByteString errors by [@&#8203;yusukebe](https://redirect.github.com/yusukebe) in [#&#8203;4437](https://redirect.github.com/honojs/hono/pull/4437) **Full Changelog**: <https://github.com/honojs/hono/compare/v4.9.9...v4.9.10> ### [`v4.9.9`](https://redirect.github.com/honojs/hono/releases/tag/v4.9.9) [Compare Source](https://redirect.github.com/honojs/hono/compare/v4.9.8...v4.9.9) #### What's Changed - fix(service-worker): Update service-worker fire() to accept generic variants of Hono app instance by [@&#8203;harmony7](https://redirect.github.com/harmony7) in [#&#8203;4420](https://redirect.github.com/honojs/hono/pull/4420) - fix(service-worker): correct generics for `handle` by [@&#8203;yusukebe](https://redirect.github.com/yusukebe) in [#&#8203;4421](https://redirect.github.com/honojs/hono/pull/4421) - feat(helper/route): enable to get route path at specific index by [@&#8203;usualoma](https://redirect.github.com/usualoma) in [#&#8203;4423](https://redirect.github.com/honojs/hono/pull/4423) #### New Contributors - [@&#8203;harmony7](https://redirect.github.com/harmony7) made their first contribution in [#&#8203;4420](https://redirect.github.com/honojs/hono/pull/4420) **Full Changelog**: <https://github.com/honojs/hono/compare/v4.9.8...v4.9.9> ### [`v4.9.8`](https://redirect.github.com/honojs/hono/releases/tag/v4.9.8) [Compare Source](https://redirect.github.com/honojs/hono/compare/v4.9.7...v4.9.8) #### What's Changed - fix(types): JSONParsed infer unknown values by [@&#8203;BarryThePenguin](https://redirect.github.com/BarryThePenguin) in [#&#8203;4405](https://redirect.github.com/honojs/hono/pull/4405) - refactor(types): remove SimplifyDeepArray from json types by [@&#8203;BarryThePenguin](https://redirect.github.com/BarryThePenguin) in [#&#8203;4406](https://redirect.github.com/honojs/hono/pull/4406) - refactor(types): fix the type definitions in hono-base by [@&#8203;yusukebe](https://redirect.github.com/yusukebe) in [#&#8203;4407](https://redirect.github.com/honojs/hono/pull/4407) - fix(request): return empty string for empty catch-all param by [@&#8203;amitksingh0880](https://redirect.github.com/amitksingh0880) in [#&#8203;4395](https://redirect.github.com/honojs/hono/pull/4395) #### New Contributors - [@&#8203;amitksingh0880](https://redirect.github.com/amitksingh0880) made their first contribution in [#&#8203;4395](https://redirect.github.com/honojs/hono/pull/4395) **Full Changelog**: <https://github.com/honojs/hono/compare/v4.9.7...v4.9.8> </details> --- ### 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 these updates again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/better-auth/better-auth). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS4xNTYuMSIsInVwZGF0ZWRJblZlciI6IjQxLjE1Ni4xIiwidGFyZ2V0QnJhbmNoIjoiY2FuYXJ5IiwibGFiZWxzIjpbImRlcGVuZGVuY2llcyJdfQ==--> --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-15 21:22:41 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#22936
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?