GHSA-f74w-272x-mqcv — nocodb
MEDIUMGHSA-f74w-272x-mqcv is a medium-severity (CVSS 5.4) CWE-614 vulnerability in nocodb. No vendor fix is recorded yet; mitigation options are listed below.
NocoDB: Refresh Token Cookie Set Without `secure` and `sameSite` Flags
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-f74w-272x-mqcv.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-f74w-272x-mqcv by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 381,682 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
nocodbnpmDescription
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | nocodb | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nocodb, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of nocodb has shipped for GHSA-f74w-272x-mqcv yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Frequently Asked Questions
Is GHSA-f74w-272x-mqcv in your dependencies?
Find it across npm, including transitive dependencies.