Independent reportPublished Oct 3, 2026All times UTC

NoCodeBackend: until Sept 25, 2026, anyone with an account could get another user's database keys — just by knowing their email address

Written by miyan, an AppSumo buyer of NoCodeBackend who found the flaw and reported it privately. I am not affiliated with NoCodeBackend or with any competitor. I tested only my own account and never accessed anyone else's data.

1. The short version

• NoCodeBackend's dashboard had a web address that returns a user's list of databases. You gave it an email address, and it answered — without checking that the email belonged to you.
• The answer included each database's secret key (sk_live_…). That key alone lets anyone read, change or delete everything in that database through NoCodeBackend's public API. No password and no login are needed to use it.
• So an attacker needed only two things: any NoCodeBackend account (signing up is free) and the victim's email address.
• Separately, the database server shared by all customers had its port 3306 open to the whole internet.
• I reported it privately on Sept 25 at 09:36. At 11:10 the vendor told me in writing: "We don't see a any issues for the critical vulnerabilities you reported. The architecture works as expected." Later that day the address was blocked (my saved responses show 403 by 11:49, and my logged re-check at 14:11 confirms it), and the port was closed. The vendor later wrote that it had sent "we don't see any issues" "while our engineering team was actively deploying the fixes".
• The vendor has since said publicly that it was fixed "in less than 15 minutes", that it was a "minor" issue, and that logs show "zero unauthorized access". It has not said how far back those logs go, has not reset anyone's keys, and has not warned users directly.

2. Why I am publishing this

I did not want to write this page. If NoCodeBackend had simply told its users what happened — "we had a bug, it is fixed, please regenerate your keys" — my private report and their quick fix would have been the end of it, and this page would not exist.

Instead, the vendor first told me in writing that there was no issue, fixed it the same day without saying so, questioned my motives in private, offered me a $250 store coupon, and then described the problem publicly as a "minor" "edge case" while pointing readers to my refund request. Meanwhile, every key issued before Sept 25 still works, and users have not been told.

Most people who buy a no-code backend are not security specialists. They cannot judge this risk from a forum thread, and many of them store their own customers' data in it. The risk is serious enough that they deserve to know — and to be able to check the facts themselves. That is why this report includes the technical details and the evidence.

About the disclosure window: my original report gave the vendor 90 days to fix the issue before I published anything, and said I would hold publication if the vendor acknowledged the report and gave me an expected fix date. No fix date was ever given. The window existed so the issue could be fixed; the vendor has now confirmed publicly that it is fixed, so there is no longer any reason to wait. I re-checked on Oct 3, 2026 at 02:02 UTC that the fix is still in place.

3. What happened, in plain words

Imagine a hotel where any guest can walk up to the front desk and say: "I'm the guest registered as alice@example.com — may I have my room keys?" The clerk checks that you are a guest of the hotel, but never checks that you are Alice. Then the clerk hands over Alice's keys.

That is the flaw. NoCodeBackend checked that the request came from some logged-in account, but not that the email in the request belonged to that account. Because anyone can create an account for free, "being a guest" was no barrier at all.

And the "keys" were not a view of the dashboard. They were the secret API keys of each database — the same keys your app uses to read and write its data. With one of those, a stranger does not need your password or your dashboard. They can talk to your database directly.

4. Technical details

This section is for readers who want to check the claims. The flaw is fixed, so none of this can be used against users today. It contains no real keys, no real database names, and nothing that identifies any other customer. Every test below was made with my own account and my own token only.

4.1 The endpoint

GET https://app.nocodebackend.com/api/databases/list?email={email}
Authorization: Bearer {a valid dashboard token}

The server required a valid token (a request without one returned 401 Unauthorized), and it required the email parameter (without it: 400 "Missing email"). But it looked up databases by the email parameter alone. It did not compare that email with the owner of the token.

4.2 What I measured (Sept 23–24, 2026)

A correct server answers the second request with a refusal (403): "this token does not belong to that email". This one answered 200 and simply returned whatever that email owned — an empty list, because no databases were found under that address. The request was never refused and never questioned; it was just searched. For an address that does own databases, that same response contains each database's live secret_key (section 4.3). Whether the same request would return another customer's databases is the point taken up below.

What I did not test is whether the same request would have returned a third party's list: for the other address in the table no databases were found, so its list came back empty, and I saw no one else's data. That the same request returns another customer's databases — with their live keys — is therefore an inference, not a demonstration. It is, however, the inference the vendor itself acted on when it fixed the endpoint: the fix, in the vendor's words, "added strict caller-to-token ownership validation on the database listing endpoint so no account can ever query another user's databases" (reply to my review, Sept 28). A validation like that exists to remove exactly one thing — the missing check between the caller and the email.

4.3 What the response contained

These are the real field names. All values below are made up.

{"list":[{
  "database_name": "example_shop",
  "api_url": "00000_example_shop",
  "values": "0123456789abcdef0123456789abcdef…",
  "secret_key": "sk_live_EXAMPLEEXAMPLE00",
  "region": "us",
  "host": "203.0.113.10",
  "created_on": "2026-01-01T00:00:00.000Z",
  "created_at": "2026-01-01T12:00:00.000Z",
  "created_by": "someone@example.com",
  "owner": null,
  "total_records": 42,
  "max_records": 10000,
  "max_records_formatted": "10K",
  "is_grandfathered": false,
  "purchased_extra_rows": 0
}]}

4.4 Why "it needs a session, so it can't be exploited" does not hold

In private, the vendor told me: "it's not possible to do perform any actions over those databases because that requires either clerk active session or better-auth session cookie" and "your findings, though good can't exploit a single database practically" (email, Sept 25, 16:44). Three facts answer this:

1. A session was the only thing the endpoint checked, and anyone can get one. Signing up is free. So "you need a session" means "you need an account". It does not mean "you need to be the owner". (Row 2 of the table in 4.2: my session + an email address that is not mine — accepted, 200.)
2. The key does not need a session at all. The secret_key is used with NoCodeBackend's Data API. NoCodeBackend's own documentation says: "The secret key is passed as a bearer token in the Authorization header." The key is all the request needs: no login, no browser, no cookie.
3. Protecting the dashboard is not the same as protecting the data. The session protects the dashboard. The key opens the data. The flaw handed out the key.

The vendor's public answer calls the endpoint a "dashboard metadata helper route" that "did not expose underlying database storage, raw database rows". That is true of the list itself: it contains no rows. But it contained the key that reads the rows.

4.5 The open database port (3306)

The server that hosts customer databases had port 3306 (the standard MariaDB/MySQL port) reachable from the whole internet. Before any login, it answered with its version: MariaDB 10.6.7.

This is not only my observation. Shodan, a public internet scanner run by a third party, recorded it on 2026-09-23 04:33:49 UTC (scan ID 390657919), two days before my report. Archived copies of that record are linked in section 9.

An open port is not a break-in by itself: the database still asks for a password. But a database that the whole internet can reach is exposed to password guessing and to any future MariaDB flaw. Common practice is to allow only the vendor's own servers. The vendor now says it has "restricted raw database port access at the network firewall level". That is the right fix.

4.6 No rate limit (at the time)

When I tested in September 2026, and as I wrote in my report to the vendor at the time, this endpoint had no rate limit: 30 requests sent at the same time all went through, with no 429 Too Many Requests. That matters because nothing stood in the way of trying many email addresses quickly. I have not tested this again, and I do not describe how to do it.

4.7 How I confirmed the fix (Sept 25)

NoCodeBackend's MCP gateway has its own list_databases tool. As I noted in my report to the vendor, in my tests it returned only the caller's own databases. So the right check already existed elsewhere in the product.

4.8 What I did not do

• I did not access, read or change anyone else's data or keys.
• I did not see any other customer's databases or keys. The other address in my test returned an empty list.
• I have not published any real key, database name, or other customer's details.

The vendor's own audit agrees on this point: it found nothing "beyond your own isolated verification on your own account".

5. Timeline

All times are UTC. Email times are taken from the message headers.

6. What the vendor said vs. the record

This section puts the vendor's own words next to the record from the same period. I do not add labels. Each row gives the quote, where it came from, and what the record shows.

One point first, in fairness. The vendor's Q&A answer objects to my wording that the flaw let anyone "open any other user's account". That objection is fair. The flaw handed out database keys, not dashboard logins. The accurate description is in sections 3 and 4.

Every row above is the vendor's own words next to a dated record. I leave the judgment to the reader.

7. About my refund request

The vendor has made my refund request part of the public discussion, so here it is in full. Readers can weigh my motives for themselves.

• What I asked for: a refund of two add-ons I had bought directly from NoCodeBackend's own checkout, $1,597 in total. This request did not include my AppSumo purchases.
• When: Sept 25 at 11:07 UTC, in a separate email. That was 91 minutes after my security report, after the vendor's acknowledgment, and before any reply on the substance.
• Why: the add-ons were prepaid and never reached production use. I had never put production data on the platform, only small test databases created while evaluating it, including its MCP features. After finding a flaw that handed out database keys, I was no longer willing to put production data there, so the add-ons could not serve their purpose.
• The answer: declined at 11:10, in the same email that said there were no issues. Later that day the vendor offered a $250 coupon for NoCodeBackend add-ons. I did not accept it.

8. What I am asking the vendor to do

Three things. None of them is about me.

1. Tell every user directly, by email: free, paid, AppSumo and direct-purchase accounts alike. Say that the flaw existed, what it exposed, and that keys created before Sept 25, 2026 keep working until they are regenerated.
2. Publish what the audit covered: the time period, the log sources, and the method. For example: over the whole time the endpoint behaved this way, how many requests were made in which the email did not belong to the token's owner?
3. Reset, or strongly urge users to regenerate, every key created before Sept 25, 2026. One-click regeneration already exists. What is missing is telling people to use it.

9. Evidence

Public, anyone can check

• Shodan InternetDB record for the database server, archived Sept 25, 14:16 UTC (Wayback Machine):
  web.archive.org/web/20260925141604/https://internetdb.shodan.io/129.146.189.183
• Shodan host page for the same server, with the 3306 scan date, archived Sept 25, 14:16 UTC (Wayback Machine):
  web.archive.org/web/20260925141624/https://www.shodan.io/host/129.146.189.183
• A second archive of the Shodan record (archive.today): archive.ph/WDwSR
• My Q&A question on AppSumo, with the vendor's answer and comment:
  appsumo.com/products/nocodebackend/questions/until-sept-25-a-users-email-alone-let-1551709/
• My review on AppSumo, with the vendor's reply:
  appsumo.com/products/nocodebackend/reviews/until-sept-24-2026-any-registered-noco-395425/

Kept privately

• The original emails exchanged with the vendor, with their DKIM signatures (these show who sent each email and when, and that it was not altered).
• The raw API responses from my own account, before and after the fix.
• The records of the re-check on Sept 25.

These contain my personal details, so I do not publish them. I will provide them to AppSumo or to a public authority on request.

10. What this report does not claim

• It does not claim that anyone's data was actually stolen. I do not know, and I have no way to know. It shows that the keys were exposed, not that they were used.
• It does not claim to know the vendor's intentions. It shows the vendor's own statements next to dated records, and where they do not match.
• All my measurements used my own account. I did not query any other customer's email. That the same request would have returned any other customer's list is the one point that remains an inference (4.2), and the vendor's description of its fix supports it.
• It describes the state at the times given. I last checked that the fix is still in place on Oct 3, 2026 at 02:02 UTC: the endpoint returned 403, and port 3306 timed out from three locations.