miyanQ: Until Sept 25, a user's email alone let others see their databases and secret keys. Will you warn and investigate?
Until Sept 25, a serious bug let any registered user — free or paid — open any other user's account with just that user's email address. They could see every database that person built and its secret key: full control to read, change, or delete everything inside.
I reported it privately with steps to reproduce; it is now fixed.
But a quiet fix is not enough. My questions:
1. Will you tell all users honestly that this bug existed, and warn them not to store private data until they change their keys?
2. Will you admit these risks were real, and advise everyone to change their keys and check their data for changes they didn't make?
3. We can't know if this bug was used — it left no trace for victims. Will you check your records for that period and share the results?
A quiet fix protects code, not people. What will you tell them?
Riya_NoCodeBackend
Sep 28, 2026A: Hi Miyan,
Thank you for your post. We take security and platform integrity very seriously. Because your post characterizes this as a catastrophic platform-wide exploit where anyone could "open any account and delete everything," we want to address your questions transparently and set the record straight for all users and prospective customers.
The Technical Reality: What It Was (and What It Wasn’t)
Your post describes an issue where anyone could "open any other user's account" and have "full control to read, change, or delete everything inside." That is an extreme mischaracterization of what actually occurred.
It was not an open data breach or a structural platform failure. It was an edge-case authorization condition on a dashboard metadata helper route. It did not expose underlying database storage, raw database rows, or allow arbitrary deletion of customer databases. The fact that our team investigated, tested, patched, and pushed the complete fix to production in less than 15 minutes demonstrates that this was a minor conditional routing logic fix, not a complex or critical architectural failure.
Comprehensive Forensic Audit (No Data Was Compromised)
You asked whether we checked our records: Yes, immediately and thoroughly.
We conducted a forensic audit across our Cloudflare edge logs, application access logs, and database query logs. The logs confirmed that beyond your own isolated testing requests, there was zero unauthorized access, automated scraping, or data exfiltration of any customer records or secret keys.
Furthermore, when we asked you to provide any logs or evidence demonstrating that any customer data or records were actually compromised or accessed by third parties, you were unable to provide any.
Because the audit verified that no customer records or secret keys were accessed, forced global revocation was unnecessary. However, as standard best practice, NoCodeBackend provides instant 1-click Secret Key Regeneration directly in the Database Settings dashboard for any user who wishes to rotate keys at any time.
Setting the Record Straight on Context & Timeline:
We believe in complete transparency about where the breakdown in communication occurred:
- When you first reported the observation, our immediate priority was getting into the code. However, within just 9 minutes of submitting your initial message, you followed up with an immediate demand for a full refund of over $1,500+.
-Receiving an immediate $1,500+ refund demand before an investigation could even conclude—after you had been actively using the platform for over 90 days—admittedly caught our team off guard and led to initial frustration and tension in our private exchange. While in hindsight our team could have communicated with greater patience and less defensiveness in that moment, our position on the policy was clear: an account with 3 months of active production usage is well past AppSumo’s 60-day refund window.
-Despite that initial friction, our technical responsibility to our platform and users came first: we investigated the issue, deployed the patch to production in less than 15 minutes, and verified through our access and database logs that no data or credentials had been compromised.
-In response to having the out-of-policy refund declined, you chose to bring this to public forums, characterizing a minor 15-minute fix as a catastrophic breach.
Summary for Our Community:
The observation was investigated, resolved, and deployed in under 15 minutes.
It was a minor authorization routing condition, not a data breach or data-loss vulnerability.
Complete audit logs confirm zero customer database data or credentials were ever exposed or compromised.
NoCodeBackend databases remain private, firewalled, and fully secure.
Users can regenerate secret keys with one click anytime in their dashboard.
We stand firmly behind the security and reliability of NoCodeBackend, and our team will always prioritize protecting our customers and maintaining transparent, production-grade infrastructure.
Best regards,
Riya and The NoCodeBackend Team
Verified purchaser
Thank you for those questions.
Thanks for reporting it. What you did is important and shows how honest a company is. You should actually have been rewarded for it, not ignored.
We did offer the user a $250 coupon code in recognition of their work. The concern from their end appears to be that they were expecting a refund of $1,500+ directly to their account. We declined that request because they had already been using the tool for more than nine months.
@Riya This is exactly the kind of transparency I was hoping for. Thank you very much for your professional response. It makes sense and builds trust.
Verified purchaser
Thank you for answering, Riya. Your reply confirms the flaw was real and has been fixed, and that keys can be regenerated with one click.
Two questions remain, and both are about protecting users:
1. Since there was no forced revocation, keys issued before Sept 25 keep working until each owner regenerates them. Will you email every user (free, paid, AppSumo and direct) and ask them to do so?
Verified purchaser
2. Your audit found "zero unauthorized access." Since when did the endpoint behave this way, and does the audit cover that whole period?
For the record: my refund request was sent 91 minutes after my report, not 9 (9 minutes was your acknowledgment).
The full timeline and evidence: https://ncb-disclosure-2026.pages.dev/
To address your latest questions: as already stated, we reviewed the relevant Cloudflare, application, and database logs for the period the affected functionality was in production. We found no evidence that customer data, database records/rows, or database secret keys were accessed or exposed.
That is why we did not force global key revocation or send a blanket rotation notice,
which would unnecessarily disrupt customers' applications. Had our logs shown any actual exposure, we would have immediately taken protective action, including forced key rotation where appropriate.
The vulnerability and actual data compromise are therefore two different matters. Our investigation found no evidence of an actual breach.
We also note that your own report states that you did not access, read, or change anyone else's data or keys. Therefore, recommendations to users based on assumed exposure should not be presented as evidence that a breach actually occurred.
If there is specific evidence of actual unauthorized access or exposure, we are happy to review it.
Verified purchaser
Thanks, Riya. We agree that a vulnerability and a breach are different things. My report says so directly ("It does not claim that anyone's data was actually stolen").
But you've now confirmed that no notice was sent to users, and the reason you give doesn't apply to a notice. A forced revocation could break apps. An email breaks nothing.
Verified purchaser
It simply lets each user decide, with the facts, whether to regenerate a key, which you say takes one click.
That decision belongs to users, not to the vendor. It's their data, and often their own customers' data, that sat behind those keys, and some of them may have their own obligations to check. Most users will never read this thread or the reviews.
Verified purchaser
An email from you is the only way most of them will ever find out. Telling them is part of a developer's responsibility, and "our logs show no evidence" can't replace it, especially without the dates the logs cover.
Verified purchaser
So, three questions:
1. Will you email all users (free, paid, AppSumo and direct) that keys issued before Sept 25 could be retrieved by other accounts, and that they can regenerate them?
2. If not, what is the reason, given that an email doesn't disrupt anyone's application?
3. What are the start and end dates of the period your logs covered?
To clarify and close this matter:
The affected endpoint was in production from September 19, 2026 at 12:40:49 UTC through September 25, 2026 at 10:24:07 UTC, when the security fix was deployed.
We reviewed the system records and application logs available to us and found no confirmed evidence that customer data, database records/rows, or database secret keys were accessed by an unauthorized party
Accordingly, there was no basis to force a global key rotation, which could unnecessarily disrupt customers' applications and integrations. Had our investigation identified actual exposure, we would have taken immediate protective action, including forced rotation where appropriate.
As an additional precaution, we have also provided customers with information regarding the resolved issue.
Customers have also been given the option to regenerate their keys.
The distinction is important: a security vulnerability existed and was fixed; our investigation found no evidence of an actual customer-data or credential compromise. We have addressed the issue and consider the matter closed.
We expect future public statements about NoCodeBackend to be accurate, factual, and evidence-based.
We reserve all rights and remedies regarding materially false or misleading factual statements or other unlawful conduct.
Any specific evidence of actual unauthorized access or exposure can be provided for review.