AppFlowy leaves its self-hosted edition exposed to an authenticated SQL injection
CVE-2026-16007 is an authenticated SQL injection in AppFlowy Cloud, the open-source Notion alternative: any logged-in user can read, modify, or drop the database. The fix exists only for the commercial tier — the self-hosted edition got no answer from the vendor.
June 24, 2026. Project Black reports a SQL injection in AppFlowy Cloud, the open-source Notion alternative. July 20, 2026. The vendor answers that the issue “no longer applies” to its commercial codebase. August 28, 2026. With no fix for the open-source edition, the researcher publicly warns self-hosters on Reddit — and the vendor finally confirms the flaw. In between, the self-hosted community sat exposed without an answer.
The story is not just the bug. It is what the bug reveals about how the edition you host yourself is treated.
A textbook SQL injection, in the wrong place
CVE-2026-16007 is an authenticated SQL injection. Any logged-in user can inject arbitrary SQL through the search_term parameter of this endpoint:
# The vulnerable endpoint: search_term is concatenated raw into the SQL query
curl -G 'https://appflowy.example/api/workspace/<workspace-id>/quick-note' \
--data-urlencode 'search_term=test'The faulty code sits in libs/database/src/quick_note.rs, lines 53 to 56: the user-controlled parameter is embedded into a JSON path query string with no sanitization, then pushed raw into the SQL query builder. The researchers’ proof payload is enough to confirm arbitrary execution:
1" )' OR (SELECT CAST(version() AS numeric)) IS NOT NULL--The consequences match the bug class: an authenticated user can exfiltrate, modify, or delete the instance’s sensitive databases. And if self-signup is open — the default on many installs — the attacker does not even need an existing account; they create one, then exploit.
The same code, two treatments
The most instructive part of the report is the vendor’s reply. Project Black notes that the AppFlowy Managed Cloud offering and the self-hosted edition share large portions of the same source code — the commercial tier being a closed fork of the open-source AppFlowy-Cloud repository, combined with proprietary code.
The reply received on July 20, 2026 is a masterclass in evasion:
After investigating, we confirmed that this issue no longer applies to our commercial AppFlowy Cloud codebase.
Translation: the flaw was handled — or no longer exists — on the commercial side, without a word about the open-source edition. The follow-ups on July 28 (“do you plan to patch the open-source version?”) and the disclosure notice on August 11 went unanswered.
That silence matters. It revives a question the self-hosted community has been asking since AppFlowy moved some features — notably SSO — into its paid tiers: is the community edition still maintained, or has it become a loss leader?
The disclosure timeline, or how not to handle a report
The full chronology reads as a case study — in reverse.
- June 24, 2026 — initial report to the vendor.
- July 8 — follow-up, no response received.
- July 9 — “we are investigating”.
- July 20 — “no longer applies to our commercial codebase”.
- July 28 — request for clarification on the open-source edition, no response.
- August 11 — notice of intent to disclose publicly, no response.
- August 28 — Project Black warns self-hosters on Reddit; the vendor disputes, then updates its post to confirm the vulnerability exists.
The researcher describes the experience as close to the worst vulnerability disclosure he has ever lived through. The lesson is not about technical difficulty — fixing a string concatenation is trivial — it is about governance: when a vendor goes quiet, the only deadline that moves things is publicity.
What this changes for self-hosters
For the self-hoster, the equation is simple and unpleasant. If you run the community AppFlowy Cloud, three facts stack up: the flaw is authenticated, so mostly invisible to external scanners; self-signup makes it exploitable by anyone; and no fix is announced for your edition at disclosure time.
The response is three moves, in order of urgency:
- Cut network exposure. Until a fix is published for the open-source edition, the instance must not be reachable from an untrusted network. That neutralizes exploitation regardless of the code’s state.
- Disable self-signup. The flaw requires an authenticated account. Turning off public registration shrinks the attacker pool to those who already hold a legitimate account.
- Watch for a patch. The risk is not theoretical: as long as the version you run contains the faulty concatenation, any account — even one compromised later — is a key to the database.
# Restrict access to the self-hosted instance (example with ufw)
ufw default deny incoming
ufw allow from <admin-subnet> to any port 443 proto tcp
ufw enableVerdict
If you self-host AppFlowy Cloud, treat the instance as what it is today: software whose patch pipeline is not guaranteed. Cut its network exposure now, disable self-signup, and put the release of a fix on your security watch — not your quarterly maintenance plan.
If you are still evaluating AppFlowy, the question is no longer “open source versus Notion”, but “an edition whose security fixes depend on a commercial contract, or not?”. Answer it before you deploy, because once the data is inside, migration costs more than a change of mind.