No-Code App Builder 'Adalo' Flaw CVE-2026-10706 Exposes User Data Across 1M+ Apps — No Patch Yet, Avoid Storing Sensitive Data
A flaw in the popular no-code app builder Adalo (CVE-2026-10706) lets any authenticated user pull the full sign-up data—emails and more—of other people's apps. Over one million apps are affected, and because it is a platform-level flaw, users cannot fix it themselves. With no patch yet, avoid storing sensitive data. We explain the scope, the mechanism, and what to do now.
Table of contents
A flaw in the popular no-code app builder Adalo (CVE-2026-10706) lets any authenticated user pull the full sign-up data—emails and more—of other people's apps. Over one million apps are affected, and because it is a platform-level flaw, users cannot fix it themselves. With no patch yet, avoid storing sensitive data. We explain the scope, the mechanism, and what to do now.
A flaw in the popular no-code app builder Adalo—which lets people build mobile and web apps without writing code—allows the sign-up data of any app to be pulled out wholesale by a complete stranger. Carnegie Mellon University's coordination center, CERT/CC, disclosed it on July 8, 2026 (VU#849433), and the next day Japan's JVN, run by JPCERT/CC and IPA, issued a domestic advisory as JVNVU#99220646.
The problem is tracked as two identifiers (CVE-2026-10706 and CVE-2026-10708). What makes it serious is that the weakness lives in Adalo's own foundation, so every one of the more than one million apps built on Adalo is affected. Worse, at the time of writing no fix has been released yet. Neither the people who built the apps nor the people using them can stop this through their own settings.
What Adalo actually is
Adalo is a "no-code" service: you build an app by dragging and dropping screen parts instead of writing code. No-code means people with no programming background can assemble apps and web services like snapping building blocks together. It is widely used by anyone who wants to launch a service without hiring an engineer—booking apps for a small shop, internal inventory tools, membership apps for a community, and so on.
Adalo's convenience comes not only from the look of the app but from the fact that it also provides the "database" that stores the email addresses and names of people who sign up. In other words, whoever builds an app is entrusting their users' personal data to Adalo's servers. What went wrong this time is exactly the back-end gateway (the database API) that reads and writes that entrusted data.
Platforms that let you build business tools with little or no code have run into trouble before, such as the low-code platform Appsmith flaw that let attackers hijack its communication gateway. The trade-off for that ease of use—that users cannot easily verify the safety of the foundation themselves—is a challenge common to this whole category of service.
What leaks, and how big is it
According to CERT/CC, the data at risk of being pulled out includes the email addresses, internal record numbers (UUIDs), and any custom fields of users who signed up in an Adalo-built app. Custom fields can hold whatever the app asks members to enter—phone numbers, addresses, dates of birth, and more.
The scale is what stands out. Both the old version (V1) and the new version (V2) of Adalo are affected, and more than one million apps built to date fall within scope. Because this stems from Adalo's platform design rather than one app's misconfiguration, no matter how carefully a builder set things up, this particular issue is not something they can patch themselves. CERT/CC put it bluntly: developers and their end users face "a risk of data exposure that they cannot prevent or remediate."
Two factors make it worse. CERT/CC notes that stored text data is kept in plaintext rather than encrypted, and that there is evidence records once deleted may still be accessible. In other words, even information from users who left long ago may remain reachable.
Who targets this hole, and what happens
The people put at risk first are ordinary users who signed up in an app built with Adalo. The likely attackers are list brokers who buy and sell harvested email addresses and personal data, and groups running impersonation and fraud schemes. For them, a bulk set of real, working contacts is an easy product to cash in.
The way in is surprisingly simple. An attacker only has to create one harmless account in some Adalo app, then use it as a foothold to scoop up the sign-up data of a completely unrelated app run by someone else. No per-app secret or special privilege is required.
As a result, users of the app can become targets of phishing emails and impersonation they never invited. Meanwhile, the individual or business running the app has effectively leaked the customer data they were entrusted with, facing loss of trust, a flood of inquiries, and in some cases legal accountability under data protection law. Breaches where customer data is stolen from a supplier's system keep happening as cases of exploiting a development-platform flaw—this time the "platform" simply happened to be a no-code service.
A closer technical look
This trouble is made up of two different weaknesses stacked on top of each other, each with its own identifier.
CVE-2026-10706: returning everything, including fields you never asked for
Adalo apps have components that display a list of users or a ranking (a leaderboard). These components should ask the server only for the fields they actually need to show. But the database API returned the user's entire record no matter which fields the screen was set to display. Even when a screen showed only a nickname, an email address and more were quietly delivered alongside it. This is a classic design mistake known as "over-fetching."
More serious is that there was no ownership check to confirm whether the requester was allowed to see the data. Adalo apps are supposed to be independent, but their databases and tables carry sequential internal identifiers (dbId). An authenticated user could simply increment that number and query it, and pull out data belonging to entirely unrelated apps. The U.S. National Institute of Standards and Technology classifies this as exposure of information to an unauthorized actor (CWE-200).
CVE-2026-10708: a pass that stays usable for 20 days gets out
The second weakness involves the electronic pass that proves a logged-in state (a JWT token). This token sat in a place retrievable just by watching the browser's traffic, and it stayed valid and reusable for roughly 20 days. There was also no mechanism to revoke a token mid-way.
On top of that comes a loose setting that accepts requests from any site (wildcard CORS). CORS is the browser safeguard that decides whether one site's data may be read from another site, but Adalo had it set to effectively "anyone allowed." So an attacker could paste a captured token into a completely unrelated external site or script and siphon large volumes of user data automatically through the back door, without ever opening the Adalo app. Per CERT/CC, a single request to a minimal leaderboard component returned records containing emails, UUIDs, and custom fields.
Combined, these two produce the worst-case mix: pulling "unrelated strangers' app data," "without opening the app," "in bulk and automatically."
How events unfolded
← swipe to move
Researcher Saud Darwish reported the issue to Adalo through CERT/CC in April 2026, and after roughly three months of coordination it was published on July 8. It was also added to vulnerability aggregation databases, and Japan's JVN picked it up the following day.
What is confirmed, and what is still unknown
✓ Confirmed facts
- ✓Both old and new versions (V1 and V2) are affected; over one million apps are in scope (CERT/CC)
- ✓Adalo is aware of the issue, but no fix is available as of publication (CERT/CC)
- ✓Email addresses, internal record numbers, and custom fields can be extracted (CVE-2026-10708)
? Not yet confirmed
- ?No official report of the flaw actually being exploited or causing harm has been confirmed so far
- ?It is not listed on CISA's catalog of vulnerabilities confirmed to be under active attack (KEV) as of publication
- ?Adalo has not stated when a fix will be delivered
What you can do now
Because the root cause lies in Adalo's foundation, a true fix has to wait for Adalo. That said, there are things each party can do now.
If you build and run apps on Adalo, the immediate defense—following CERT/CC's advice—is to stop storing highly sensitive data such as credit card details, addresses, or health information in Adalo's database. Treat data already stored there as "assume it has leaked," and consider moving it to a safer location outside Adalo if needed. Think ahead about whether you need to notify your users, depending on the nature of what you hold.
If you are an ordinary user of an Adalo-built app, your options are limited, but watch for suspicious emails to the address you registered and avoid opening links you don't recognize. If you reuse the same password on other services, this is a good moment to change it.
Incidents where data entrusted to development tools or outside services leaks through a flaw in the foundation are relentless. Taking stock of what information you hand to which services is worthwhile for other cases too, such as the hijacking flaw in a developer assistant tool.
| Who | What to do now | Self-fixable? |
|---|---|---|
| App operators | Stop storing sensitive data Treat existing data as leaked | No (platform issue) |
| App users | Watch for suspicious email Stop reusing passwords | Partly (self-defense) |
| Adalo | Add authorization checks Revisit token and CORS settings | Yes (fix pending) |
Frequently asked questions
Q. How can I tell whether an app I use was built with Adalo?
A. There is no simple, reliable way to tell from the user side. It is often used for apps or membership sites launched quickly by individuals or small businesses, so the practical approach is to watch for suspicious messages to the email you registered with such services. Asking the operator directly is another option.
Q. Do passwords leak?
A. What CERT/CC lists as exposable are email addresses, internal record numbers, and per-app custom fields. It does not explicitly state that passwords themselves are enumerated, but if your email leaks, it can lead to secondary harm where password reuse on other services is exploited. Avoiding reuse is the safe move.
Q. Is it already being exploited?
A. As of publication, no official report of real-world exploitation or harm has been confirmed, and it is not on CISA's KEV catalog of attacks confirmed in the wild. Still, the technique itself is simple, and while the hole remains in the foundation, future exploitation cannot be ruled out.
Q. When will a fix be released?
A. As of this article, Adalo has not announced a timeline for a fix. Adalo is aware and said to be working on it, but until then, not entrusting sensitive data is the best defense. The latest information is available in CERT/CC's advisory.
Summary
This is not a story about one company being attacked, but about a hole in the very foundation supporting more than a million apps. No-code and low-code services offer the convenience of building apps without expertise, but in return you hand the assurance of safety entirely to the provider. When something goes wrong at that provider, neither the person who built the app nor the person using it can act on their own.
For now, not entrusting sensitive data to Adalo, and reviewing which services you routinely hand personal data to, is the realistic preparation. We will follow up as soon as a fix is released.
References
Makoto Horikawa
Backend Engineer / AWS / Django