Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-accessible endpoint requires authenticated editor access (PR:L); scope change (S:C) because NocoDB proxies requests to cloud IMDS and internal services; no integrity or availability impact described.
Primary rating from Vendor (https://github.com/nocodb/nocodb).
CVSS VectorVendor: https://github.com/nocodb/nocodb
Lifecycle Timeline
4DescriptionCVE.org
Summary
The spreadsheet-fetch endpoint (axiosRequestMake) accepted URLs whose path contained a permitted extension anywhere in the string, and applied a hand-rolled regex blocklist that omitted 127.0.0.0/8 and 169.254.0.0/16, allowing the cloud-metadata endpoint to be reached with a crafted URL.
Details
The extension matcher is now anchored to the end of the path or immediately before the query string (/\.(xls|xlsx|xlsm|ods|ots)(\?|$)/i and /\.(csv)(\?|$)/i), so http://169.254.169.254/credentials/.xlsx no longer satisfies the format gate. The hand-rolled IP blocklist is removed in favour of useAgent(url) from request-filtering-agent, which blocks private and loopback ranges at the socket layer.
Impact
Authenticated users with editor permission could read cloud metadata and other internal HTTP endpoints reachable from the NocoDB process. On affected installs the spreadsheet import path was a credential-exfiltration primitive on cloud hosts.
Credit
This issue was reported by Devel Group Security Research Team through @TREXNEGRO. It was independently reported by @l3tchupkt.
AnalysisAI
Server-Side Request Forgery in NocoDB's spreadsheet-fetch endpoint (axiosRequestMake) allows authenticated users with editor-level permissions to coerce the NocoDB server into issuing HTTP requests to cloud metadata services (e.g., AWS IMDSv1 at 169.254.169.254) and other internal network resources reachable from the NocoDB process. Two distinct defensive failures enabled the attack: an un-anchored file-extension allowlist that accepted .xlsx anywhere in the URL path, and a hand-rolled IP blocklist that omitted 127.0.0.0/8 and 169.254.0.0/16. On cloud-hosted deployments, this functions as a credential-exfiltration primitive. No public exploit has been identified at time of analysis, but the attack pattern is trivially reproducible from the advisory text alone.
Technical ContextAI
NocoDB is an open-source no-code database platform distributed as an npm package (pkg:npm/nocodb). The vulnerable component is the axiosRequestMake spreadsheet import function, which issues outbound HTTP requests on behalf of authenticated editors to fetch remote spreadsheet files. The root cause is CWE-918 (Server-Side Request Forgery), arising from two compounding implementation flaws: first, the extension allowlist (covering .xls, .xlsx, .xlsm, .ods, .ots, .csv) was matched anywhere in the URL path rather than anchored to the path terminus or pre-query boundary, enabling bypass via paths like /credentials/.xlsx; second, the bespoke IP-range blocklist failed to enumerate 127.0.0.0/8 (loopback) and 169.254.0.0/16 (link-local, including AWS/GCP/Azure IMDS). The advisory describes the remediation as anchoring the regex (/\.(xls|xlsx|xlsm|ods|ots)(\?|$)/i) and replacing the custom blocklist with socket-layer filtering via the request-filtering-agent npm library, which enforces RFC-1918 and link-local blocking at the TCP connection level.
RemediationAI
No specific patched npm version number was confirmed in the available data - the advisory GHSA-gprh-27j3-g5h4 (https://github.com/nocodb/nocodb/security/advisories/GHSA-gprh-27j3-g5h4) describes the code-level fix (anchored regex, request-filtering-agent integration) as already implemented, but the fixed in metadata is absent. Operators should monitor the NocoDB npm release page and upgrade to the first release above 0.301.3 that incorporates these changes. As an immediate compensating control, restrict editor-level permissions to fully trusted internal users and revoke editor access for any external or untrusted accounts, since exploitation requires editor authentication. On AWS deployments, enforcing IMDSv2 (token-required mode via HttpTokens=required on the EC2 instance metadata endpoint) prevents unauthenticated IMDS credential fetches and substantially raises exploitation difficulty for the most damaging attack path, though it does not eliminate SSRF against other internal services. Additionally, applying egress firewall rules on the NocoDB host to block outbound connections to 169.254.0.0/16 and 127.0.0.0/8 provides socket-layer protection independent of application logic - note that this may interfere with legitimate metadata access by other host processes, so test carefully before deploying.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-38609
GHSA-gprh-27j3-g5h4