The 'Continue' to Nowhere: Breaking NocoDB's Login Flow

NocoDB markets itself as an open-source Airtable alternative—a spreadsheet that talks like a database. It's a fantastic tool for developers and low-code enthusiasts alike, often sitting behind corporate firewalls or VPNs, guarding sensitive internal data. Because of this sensitivity, the authentication flow is sacred. Users are trained to trust the domain they see in the address bar: nocodb.internal.corp. If the lock icon is green and the domain is right, they type their password.

But here’s the kicker: authentication flows almost always need a way to remember where you were going. If you click a link to a specific spreadsheet but aren't logged in, the app saves that destination, sends you to the login page, and then—helpfully—bounces you back to your work once you've authenticated. In NocoDB, this mechanic is handled by the continueAfterSignIn parameter.

To a hacker, this parameter is like a back door left slightly ajar. It represents a bridge between the trusted authentication state and the user's next destination. If we can control that bridge, we can control the user's reality immediately after they've lowered their defenses. CVE-2026-24768 is exactly that: a bridge built without guardrails.

The root cause of this vulnerability is a classic case of "identifying the object" versus "validating the intent." The developers needed to know if the URL provided in continueAfterSignIn was an external link or an internal route. Why? Because the underlying framework (Nuxt/Vue) handles internal routing differently than full page loads to external sites. To solve this, they implemented a helper function called isFullUrl.

This helper relied on a Regular Expression to make its decision: /^(https?:)?\/\//. Translated from Regex-speak to English, this says: "Does the string start with http:, https:, or just //? If yes, it's a full URL." If the check passed, NocoDB passed external: true to the navigateTo function. And that is where the logic falls off a cliff.

The code correctly identified that the URL was external, but it never stopped to ask if an external URL should be allowed. It’s like a bouncer at a club checking if you have an ID, seeing that you do, and letting you in—without checking if the ID actually belongs to you or if you're on the banned list. The application explicitly told the browser, "Yes, this is an external link, please navigate there," without verifying if the destination was nocodb.com or phishing-site.ru.

Let's look at the logic that enabled this. The vulnerability lived deep within the redirect plugin logic where the application decides where to send the user next. The developers likely assumed that continueAfterSignIn would be generated by the application itself, not tampered with by a malicious user.

Here is the essence of the vulnerable logic:

// The Helper
const isFullUrl = (url: string) => /^(https?:)?\/\//.test(url);
 
// The Redirection Logic
if (route.value.query.continueAfterSignIn) {
    navigateTo(route.value.query.continueAfterSignIn as string, {
        // If it looks like a URL, treat it as an external navigation
        external: isFullUrl(route.value.query.continueAfterSignIn)
    });
}

This is a textbook Open Redirect. The external: true flag in Nuxt's navigateTo disables internal routing protections and forces a window.location change. By providing a URL like https://attacker.com, the isFullUrl check returns true, and the application obediently executes the browser redirect.

The Fix: In version 0.301.0, the remediation (likely) involves one of two standard approaches: either stripping the domain entirely to force a relative path (making https://google.com become just /google.com, which 404s on the local server) or checking the URL.origin against window.location.origin. The most robust fix is to simply reject any continueAfterSignIn value that does not start with a / or that attempts protocol manipulation.

Exploiting this is trivially easy but socially devastating. The goal isn't to crash the server; it's to steal credentials. Because the redirect happens after a successful login, the victim is in a state of high trust. They have just proven who they are to the legitimate system, and the system is about to betray them.

The Attack Chain:

1. The Setup: I spin up a clone of the NocoDB login page at https://evil-db.com. It looks identical. I configure it to capture credentials and then error out.
2. The Lure: I craft a URL for your company's real NocoDB instance: https://nocodb.company.com/#/signin?continueAfterSignIn=https://evil-db.com/session-expired
3. The Catch: I send this link to an employee via Slack or Email: "Hey, can you check this row in the Q3 budget?"

When the victim clicks, they see nocodb.company.com. Safe. Valid SSL. They enter their real credentials. The NocoDB server authenticates them successfully, sets the session cookie, and then immediately executes the vulnerability. The browser redirects to evil-db.com. The victim sees a "Session Expired, please login again" message on my site. Annoyed, they type their password again. Game over. I have their credentials, and they have a valid session on the real site.

While the CVSS score is a moderate 5.7 (due to the requirement of user interaction and lack of direct system compromise), the business impact is severe. Open Redirects are the force multipliers of phishing campaigns. They neutralize the primary advice security training gives to users: "Check the URL."

In this scenario, the URL is correct. The certificate is valid. The initial interaction is with the legitimate server. This bypasses many email security gateways that might flag evil-db.com but will happily let nocodb.company.com through. For an organization using NocoDB to store customer data, PII, or financial records, a stolen credential often leads to total data exfiltration. Furthermore, because the redirect happens client-side via JavaScript, it may not even leave a distinct footprint in the server's access logs that clearly distinguishes it from legitimate traffic, making post-mortem analysis difficult.

The remediation is straightforward: Don't trust user input. Specifically, do not trust the continueAfterSignIn parameter to dictate the destination origin. NocoDB fixed this in version 0.301.0. If you are running an older version, update immediately.

If you cannot update, you can mitigate this at the network layer (WAF) by inspecting query parameters. Block requests to /signin where continueAfterSignIn contains :// or starts with //. However, WAF rules are brittle and often bypassable with URL encoding. The only true fix is the code patch.

For developers reading this: If you need to redirect users, use a whitelist approach. Or better yet, ensure that the redirect target is always a relative path using an API like Java's URI or the browser's new URL(), and explicitly verifying that target.origin === current.origin.