AppFlowy Authenticated SQL Injection

AppFlowy is an open source alternative to Notion which offers two deployment options:

• AppFlowy Managed Cloud: AWS-hosted instances fully deployed and managed by the AppFlowy team
• AppFlowy Self-hosted Cloud: Configurable services you can deploy on your own infrastructure

Notably, both the cloud offering and the self-hosted version likely share large portions of the same source code meaning the vulnerability we found might've affected both.

The codebase behind these two setups is a closed-source fork of this open-source codebase: https://github.com/AppFlowy-IO/AppFlowy-Cloud, combined with our proprietary code. The commercial fork is distributed solely under our commercial license.

We didn't attempt exploitation in their cloud offering because it seems that it's only OpenAI and Anthropic that are allowed to hack anyone they want.

The Vulnerability

The vulnerability itself is a classic case of SQL injection.

Authenticated users can include arbitrary SQL payloads via the search_term parameter in the following endpoint:

GET /api/workspace/{workspace-id}/quick-note?search_term={SQL payload}

Affected codes: libs/database/src/quick_note.rs: 53 - 56

• The search_term parameter is user-controlled
• search_term is embedded into a JSON path query string with no sanitisation (line 55).
• On line 56, query_builder.push() appends this string raw into the SQL query

The result is that any authenticated user can exploit the vulnerability to exfiltrate/modify/delete existing sensitive databases.

If the instance permits self-account signup, the risk of exploitation increases further.

Reproduction Steps

Authenticate to AppFlowy as an authenticated user and create a quick note.

Use the below payload in the search_term parameter to dump the database version:

URL encoded: ?search_term=%31%22%20%29%27%20%4f%52%20%28%53%45%4c%45%43%54%20%43%41%53%54%28%76%65%72%73%69%6f%6e%28%29%20%41%53%20%6e%75%6d%65%72%69%63%29%29%20%49%53%20%4e%4f%54%20%4e%55%4c%4c%2d%2d

Decoded: 1" )' OR (SELECT CAST(version() AS numeric)) IS NOT NULL--

Disclosure

Here's where it gets interesting.

After reaching out to them we eventually got this response back from the AppFlowy team.

Thank you for contacting us. After investigating, we confirmed that this issue no longer applies to our commercial AppFlowy Cloud codebase.

Read that line again - no longer applies to our commercial AppFlowy Cloud.

That means:

1. This issue affected their Cloud offering and they patched it. OR
2. They previously knew about it any only patched their Cloud offering. OR
3. The feature isn't available in their Cloud offering/was rewritten so it doesn't affect their Cloud offering anymore?

Notably there's no mention of the open source version at all.

We followed up to ask if there was any plan to patch the community codebase and were met with silence.

Disclosure Timeline

• 24 June 2026 - Vulnerability reported
• 8 July 2026 - Follow up as no response had been received
• 9 July 2026 - Response received - "we are investigating"
• 20 July 2026 - Follow up as no update had been received
• 20 July 2026 - "After investigating, we confirmed that this issue no longer applies to our commercial AppFlowy Cloud codebase."
• 28 July 2026 - Project Black asks is there any intention to patch the Opensource version - no response received
• 11 August 2026 - Notified AppFlowy of intention to proceed with public disclosure - no response received

Responsibility

Self-hosting AppFlowy isn't always free. Is the expectation that you need a "Support contract" to get security patches? We don't know... they stopped replying.

If the self-hosted version is abandonware, then AppFlowy at least have an obligation to mark it as such.

After not hearing anything back from AppFlowy about if they'd patch the OpenSource version on Github we decided to warn self-hosted users with a reddit post.

Suddenly, there is communication again, unfortunately in the form of denial.

It seems they don't think we actually deployed their code (which is absolutely absurd) so we recorded a quick video demonstrating the issue.

Our initial report had everything in this section so the video didn't actually include any new information.

Despite this, after a bit of time the AppFlowy team updated their post to confirm the vulnerability did exist! Amazing!

It would seem that our report wasn't properly investigated or it wasn't understood.

This is very close to the WORST vulnerability disclosure experience we've ever experienced.

Closing Thoughts

In the world of AI agents spamming the world with junk emails, it can be easy to ignore or dismiss emails from strangers.

However, if you do receive a security report, either be 99.99% confident you're right if you're going to ignore it OR ask for more clarification if you're not sure! Most security researchers are very willing to provide more information as required.

Project Black helps you find issues like this in your own stack before someone else does in our penetration testing services. Consider reaching out if you have security assurance requirements!