701 NocoDB fingerprints and 365 titles leave version risk unresolved
NocoDB is a self-hosted data platform with APIs, sharing features, and OAuth support. A ZoomEye query for app="NocoDB" returned 701 matches on November 4, 2026. The title query for NocoDB returned 365.
The useful fact is not that 701 instances are vulnerable to CVE-2026-121736. It is that the two evidence paths disagree and neither one exposes a software version. An unauthenticated OAuth authorization-code issue requires a version and configuration check that a fingerprint cannot perform.
Observation
| Query | Matches |
|---|---|
app="NocoDB" |
701 |
title="NocoDB" |
365 |
The application query completed at 2026-11-04T23:43:31Z and the title query at 2026-11-04T23:43:32Z. Both used page 1, page size 1, sub_type=all. No failed query was treated as zero.
The application count is higher than the title count. A NocoDB deployment may present a title that changes with branding, a reverse proxy, or a tenant-specific page. The product fingerprint can remain visible while the page title does not.
What the counts can support
The counts support a discovery statement: NocoDB has a measurable presence in the indexed internet population, and the application fingerprint is the better first query if the goal is to find candidates. They do not establish ownership, version, public reachability of the OAuth endpoint, or exposure of sensitive data.
An internet-facing NocoDB installation may be a public demo, a partner portal, or a test deployment. A count cannot tell a security team which records belong to its organization. Use the query as a lead, resolve the host through DNS and certificate records, then confirm the service through an authorized management interface or an internal CMDB.
Review OAuth and data permissions
CVE-2026-121736 affects NocoDB 0.300.0 before 2026.08.0. The public description identifies POST /api/v2/oauth/authorize as the vulnerable handler. Upgrade to 2026.08.0 or later and verify the running release.
After patching, review registered OAuth clients, redirect URIs, scopes, and token lifetimes. An authorization code should be issued only after authentication and consent and should be bound to the correct client. Test with an unauthenticated request and confirm that the service rejects it before creating a code.
Check the data boundary behind the API. A token that can read a base, attachment, user list, or webhook is not an abstract identity. It can expose structured business data. Review which NocoDB workspaces are public, which users can create tokens, and whether a compromised token can reach other bases.
A measured response
Treat the 701 application matches as a review queue, not a breach list. Prioritize hosts whose certificates, domains, or network locations connect them to the organization under review. Validate the release and OAuth configuration, then check logs for unexpected authorize requests and token issuance.
For teams with no public NocoDB footprint, the internal inventory still matters. A self-hosted application can be reachable only through a VPN or a private load balancer and never appear in ZoomEye. The external count is a complement to configuration management, not a replacement.
Top comments (0)