CVE-2026-47379: NocoDB Information Disclosure Flaw

CVE-2026-47379 Overview

CVE-2026-47379 is a timing side-channel vulnerability in NocoDB, an open-source platform that turns databases into spreadsheet-style applications. Versions prior to 2026.05.1 compare legacy plaintext shared-view passwords using JavaScript strict-equality (===). String comparison with === short-circuits at the first mismatched character, producing measurable timing differences between requests. An unauthenticated network attacker can observe response latency to infer the password length and recover it one character at a time. The issue is tracked as CWE-200: Exposure of Sensitive Information and is resolved in NocoDB 2026.05.1.

Critical Impact
Remote attackers can recover shared-view passwords character-by-character through response timing analysis, gaining unauthorized access to protected NocoDB views.

Affected Products

NocoDB versions prior to 2026.05.1
NocoDB shared-view feature using legacy plaintext password storage
Self-hosted and containerized NocoDB deployments exposed over the network

Discovery Timeline

2026-06-23 - CVE-2026-47379 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-47379

Vulnerability Analysis

NocoDB allows users to share database views protected by a password. Prior to version 2026.05.1, the server-side password verification path included a fallback branch for legacy passwords stored in plaintext. That fallback used JavaScript's strict-equality operator (===) to compare the submitted password against the stored value.

Strict-equality on strings in V8 and similar engines is not constant-time. The comparison exits as soon as a character mismatch is detected, and the length check itself returns early when lengths differ. An attacker measuring HTTP response time can therefore distinguish between a wrong-length password, a right-length password with a wrong first character, a right first character with a wrong second, and so on.

The vulnerability is reachable without authentication over the network, since the shared-view password endpoint is exposed to anyone holding the share link.

Root Cause

The root cause is the use of a non-constant-time comparison (===) for a secret value. Secure password validation requires either hashed comparison using a slow KDF such as bcrypt, argon2, or scrypt, or a constant-time byte-wise comparison such as crypto.timingSafeEqual. The legacy plaintext code path bypassed both, leaking both length and per-character prefix information through observable latency.

Attack Vector

An attacker who knows a shared-view URL repeatedly submits candidate passwords and measures server response times. By averaging many requests per candidate to suppress network jitter, the attacker first determines the password length, then iterates character positions and tests each printable character. Each correctly guessed character increases the comparison loop length and the measured latency, allowing recovery in linear time relative to password length and alphabet size. No authentication, user interaction, or special privileges are required. See the NocoDB GitHub Security Advisory GHSA-qhxg-623c-cfjm for vendor details.

Detection Methods for CVE-2026-47379

Indicators of Compromise

High-volume POST requests to NocoDB shared-view password verification endpoints originating from a single source IP or small IP cluster
Repeated authentication attempts against the same share link with incrementally varying password values
Successful access to a shared view immediately following a burst of failed password submissions from the same client
Anomalous request timing patterns where clients issue thousands of password attempts within short windows

Detection Strategies

Enable verbose access logging on the NocoDB instance and front-end reverse proxy to capture per-request timestamps and source IPs for shared-view endpoints
Build rate-based detection rules that alert when password verification requests against a single share token exceed a normal user baseline
Correlate failed-password telemetry with subsequent authenticated activity from the same client to identify successful brute-force recovery

Monitoring Recommendations

Forward NocoDB application logs and reverse-proxy logs to a centralized SIEM for retention and correlation
Monitor for outbound database queries from shared-view sessions that follow immediately after high request volumes against the password endpoint
Track the NocoDB application version in asset inventories to confirm all instances are upgraded to 2026.05.1 or later

How to Mitigate CVE-2026-47379

Immediate Actions Required

Upgrade all NocoDB instances to version 2026.05.1 or later, which replaces the vulnerable comparison with a safe path
Rotate any shared-view passwords that were in use before patching, since prior values may have been recovered
Revoke and reissue shared-view links that protect sensitive datasets to invalidate cached share tokens
Place internet-facing NocoDB deployments behind a reverse proxy or WAF that enforces rate limiting on share endpoints

Patch Information

The fix is included in NocoDB 2026.05.1. The maintainers replaced the legacy strict-equality comparison so that password verification no longer leaks length or prefix information through timing. Full remediation details are documented in the GitHub Security Advisory GHSA-qhxg-623c-cfjm.

Workarounds

Disable shared-view password protection and instead require full NocoDB authentication for sensitive views until the patch is applied
Restrict access to NocoDB share endpoints by IP allowlist or VPN where feasible
Apply aggressive rate limiting at the reverse proxy on password verification routes to slow timing-oracle exploitation
Rebuild any shared views with strong, high-entropy passwords to increase the cost of character-by-character recovery

bash

# Example: nginx rate limiting for NocoDB shared-view password endpoint
limit_req_zone $binary_remote_addr zone=nocodb_share:10m rate=5r/m;

server {
    location ~* /api/v[12]/.*/shared/.*/password {
        limit_req zone=nocodb_share burst=3 nodelay;
        limit_req_status 429;
        proxy_pass http://nocodb_upstream;
    }
}