Listen to this Post
The vulnerability, tracked as CVE-2026-46550, arises from the insecure implementation of the refresh-token cookie handling in NocoDB versions prior to the patch. The `setTokenCookie` function in `packages/nocodb/src/services/users/helpers.ts` generates the cookie with only the `httpOnly` flag enabled. It lacks both the `secure` flag and the `sameSite` attribute. The `secure` flag ensures the cookie is only transmitted over HTTPS, preventing network interception. The `sameSite` attribute mitigates Cross-Site Request Forgery (CSRF) attacks by controlling when the cookie is sent with cross-site requests. Without these protections, the cookie is vulnerable to interception on plain HTTP networks, as it can be eavesdropped on by an attacker with network access. Furthermore, because no `sameSite` policy is set, browsers will attach the cookie to cross-site POST requests. The vulnerable endpoint is `POST /api/v2/auth/token/refresh` in auth.controller.ts, which reads the cookie unconditionally and issues a new JSON Web Token (JWT) without any CSRF countermeasures like a token or custom header. An attacker could exploit this by hosting a malicious website that triggers a cross-site POST request to the refresh endpoint, thereby obtaining a new, valid JWT for the victim’s session. The impact is exacerbated by the long expiry of refresh tokens, controlled by the `NC_REFRESH_TOKEN_EXP_IN_DAYS` environment variable, creating a prolonged exposure window.
dailycve form:
Platform: NocoDB
Version: Prior patch
Vulnerability : Cookie misconfiguration
Severity: Medium
date: 2026-05-19
Prediction: 2026-05-21
Analytics under What Undercode Say:
The vulnerable cookie settings can be audited using browser developer tools
Check a cookie's attributes with JavaScript
document.cookie.split('; ').forEach(cookie => console.log(cookie));
Look for 'refresh-token' and verify it has 'secure' and 'SameSite=Lax' attributes
Simulate a network interception on plain HTTP with tcpdump
WARNING: For authorized testing only
sudo tcpdump -i eth0 -A -s 0 'tcp port 80 and (http.request.method eq "POST" and http.request.uri matches "/api/v2/auth/token/refresh")'
Exploit:
A malicious website can force a victim’s browser to send a cross-site POST request to the vulnerable endpoint, obtaining a new JWT.
<!-- index.html -->
<form action="http://vulnerable-nocodb.com/api/v2/auth/token/refresh" method="POST" id="csrf-form">
<input type="submit" value="Click here for a prize!" />
</form>
<script>
document.getElementById('csrf-form').submit();
</script>
If the victim is logged into NocoDB, the browser will include the refresh-token cookie, and the endpoint returns a fresh JWT. The attacker can then use this JWT to make authenticated API calls on behalf of the victim.
Protection from this CVE
Upgrade to the patched version of NocoDB. The fix was applied by modifying `setTokenCookie` to include:
`sameSite: ‘lax’`
`secure: req.ncSiteUrl.startsWith(‘https’)`
This configuration enables the `secure` flag conditionally, maintaining functionality on plain-HTTP localhost environments while securing HTTPS deployments. Additionally, ensure your production NocoDB instance is served over HTTPS and consider deploying a Web Application Firewall (WAF) to detect and block anomalous CSRF patterns.
Impact
- Cookie Interception: On plain HTTP networks, an attacker can intercept the refresh-token cookie (e.g., via ARP spoofing on a public Wi-Fi), leading to session hijacking.
- Cross-Site Request Forgery: An attacker can force a victim’s browser to obtain a new JWT via a CSRF attack. If combined with a same-origin XSS or open-redirect vulnerability on the NocoDB domain, the new token can be exfiltrated.
- Prolonged Access: With a multi-day expiry on refresh tokens, the attacker’s window for token theft and reuse can be several days, leading to persistent unauthorized access to the victim’s account and data.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
