EUVD-2026-38585
GHSA-f74w-272x-mqcv
Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Primary rating from Vendor (https://github.com/nocodb/nocodb) · only source for this CVE.
CVSS VectorVendor: https://github.com/nocodb/nocodb
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
NocoDB's refresh-token cookie in versions up to and including 0.301.3 was misconfigured in setTokenCookie - issued with only httpOnly: true and no secure or sameSite attributes - exposing two distinct attack paths: cookie interception over plain HTTP networks and CSRF against the POST /api/v2/auth/token/refresh endpoint, which returns a new JWT without validating any CSRF token. Because refresh tokens carry multi-day expiry windows via NC_REFRESH_TOKEN_EXP_IN_DAYS, successful exploitation yields a long-lived credential for follow-on account access. No public exploit has been identified at time of analysis and no released patched version is confirmed, despite a documented fix in the GitHub advisory GHSA-f74w-272x-mqcv.
Technical ContextAI
CWE-614 (Sensitive Cookie in HTTPS Session Without 'Secure' Attribute) identifies the root cause class: the setTokenCookie function in packages/nocodb/src/services/users/helpers.ts constructed the refresh-token cookie with only httpOnly, an expires date, and an optional domain drawn from the NC_BASE_HOST_NAME environment variable, omitting both the secure flag and sameSite attribute. The affected package is pkg:npm/nocodb, NocoDB's open-source no-code database backend. The companion flaw is in auth.controller.ts - the POST /api/v2/auth/token/refresh endpoint reads the cookie unconditionally and returns a new JWT with no CSRF token check. Without sameSite, browsers default to permissive behavior (pre-2020 engines) or Lax (modern engines), but cross-origin POST subresource requests remain allowed in many scenarios, enabling CSRF. This vulnerability is distinct from GHSA-x4vh-j75g-268g, which involved refresh-token lifecycle on password reset with a different root cause and attack vector. The documented fix adds sameSite: 'lax' and conditionally sets secure based on whether req.ncSiteUrl starts with https, preserving functionality on plain-HTTP localhost development.
RemediationAI
No vendor-released patched version is confirmed at time of analysis - the advisory states 'fixed in: None,' meaning the fix logic is documented (adding httpOnly: true, sameSite: 'lax', and conditional secure based on whether req.ncSiteUrl starts with https) but no released version number is independently verified. Monitor the NocoDB advisory at https://github.com/nocodb/nocodb/security/advisories/GHSA-f74w-272x-mqcv and the npm package page for a patched release. As immediate compensating controls: enforce HTTPS exclusively for all NocoDB deployments via a reverse proxy (nginx, Caddy), which eliminates the cookie interception path entirely - the missing secure flag becomes irrelevant when plain HTTP is blocked. To partially mitigate the CSRF path, configure a reverse proxy to inject SameSite=Lax into Set-Cookie headers; note this may not fully replicate application-level CSRF token validation and could interfere with any legitimate cross-origin flows. Additionally, restrict the /api/v2/auth/token/refresh endpoint at the proxy layer to enforce same-origin Origin or Referer header validation, rejecting cross-origin POST requests. Organizations should treat deployment behind HTTPS-only infrastructure as the minimum baseline until an official patch is released.
Share
External POC / Exploit Code
Leaving vuln.today