NocoDB: Refresh Token Cookie Set Without `secure` and `sameSite` Flags
Description
Summary
The refresh-token cookie was set with httpOnly: true but missing both the secure flag and the sameSite attribute. Over plain HTTP the cookie could be intercepted on the network; without sameSite, browsers attached it to cross-site POSTs, enabling CSRF against the token-refresh endpoint.
Details
In packages/nocodb/src/services/users/helpers.ts, setTokenCookie produced the cookie with only httpOnly, an expires date, and an optional domain from NC_BASE_HOST_NAME — no secure, no sameSite. The refresh endpoint POST /api/v2/auth/token/refresh (auth.controller.ts) read the cookie unconditionally and returned a new JWT, with no CSRF token.
The fix sets httpOnly: true, sameSite: 'lax', and conditional secure: req.ncSiteUrl.startsWith('https') so the flag is active under HTTPS while still functional on plain-HTTP localhost development.
This is distinct from GHSA-x4vh-j75g-268g (refresh-token lifecycle on password reset) — different root cause, different attack vector.
Impact
- Cookie interception on plain HTTP networks (no
secure). - Cross-site refresh: malicious cross-origin pages could trigger token refresh and, combined with any same-origin XSS or open-redirect on the NocoDB domain, capture the new JWT.
- Refresh tokens have multi-day expiry (
NC_REFRESH_TOKEN_EXP_IN_DAYS), so the exposure window is long.
Credit
This issue was reported by @ik0z.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Missing `secure` and `sameSite` attributes on refresh-token cookie in NocoDB allows cookie interception over plain HTTP and CSRF attacks, potentially leading to JWT theft and long-term session compromise.
The vulnerability is in the setTokenCookie function in packages/nocodb/src/services/users/helpers.ts, where the refresh-token cookie was set with httpOnly: true but missing both the secure flag and the sameSite attribute [1][2]. The refresh endpoint POST /api/v2/auth/token/refresh reads the cookie unconditionally without any CSRF token [1][2].
Over plain HTTP networks, the cookie can be intercepted because there is no secure flag [1][2]. Without sameSite, browsers attach the cookie to cross-site POST requests, enabling CSRF attacks against the token refresh endpoint [1][2]. Combined with a same-origin XSS or open redirect on the NocoDB domain, an attacker can capture the newly generated JWT [1][2].
The impact includes long-term session compromise because refresh tokens have multi-day expiry configured via NC_REFRESH_TOKEN_EXP_IN_DAYS [1][2]. The fix implemented sets sameSite: 'lax' and conditional secure flag based on whether the request uses HTTPS [1][2].
This issue is distinct from GHSA-x4vh-j75g-268g, which involves a different root cause and attack vector [1][2].
AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
2News mentions
0No linked articles in our index yet.