Summary
We commissioned Cure53 to audit any-sync and they identified 17 security findings, 9 of which they classified as vulnerabilities. As of today: 8 are fixed in code, 3 are addressed by the new invitation flow and Local API changes, 1 was a false positive (confirmed by Cure53), and 1 works as designed, with a workaround described below. The other 4 are still open: dependency updates (partly done), two lower-severity hardening items, and the sync-node redesign described below. The table at the end of Key Findings lists the status of every finding.
Overview
Data security is foundational to Anytype, which is why we partnered with Cure53, a highly respected cybersecurity firm that has audited tools like 1Password, Proton Pass, and Obsidian. They conducted our audit in November and December of 2025. Their focus was on the any-sync protocol, which is the local-first, peer-to-peer, encryption technology that powers the Anytype application. Some snippets from the report:
- Primitives are correctly chosen and generally well-implemented: AES-256-GCM, Ed25519, X25519
- ACL design is “thoughtful” with security-conscious decisions (deep copies, structured permission enforcement)
- Overall verdict: “reasonably well thought-out, but its implementation is lacking in certain areas”
Key Findings
Cure53 identified 17 security-related discoveries. Of these findings, nine were classified as vulnerabilities, while the remaining eight were general weaknesses with a lower potential for exploitation. Below is a highlight of all issues marked with a level of medium and above. We recommend reading the full report for a clearer picture of all the findings.
Critical: System Stability [ANY-01-001]
Someone could send an invalid “public key” (a digital identifier) to crash a node or app that processed it. We fixed the crash during the audit, and in April 2026 added stricter validation so invalid keys are rejected as soon as they arrive.
Critical: Space Access Control [ANY-01-015]
A missing permission check let anyone, even someone with no role in the space, add a key change to it. This could make the space’s earlier content unreadable for its members. We fixed this during the audit, and Cure53 verified the fix.
High: Invite Link Security [ANY-01-010]:
Invite links carried a private key, and for auto-approval links that key was enough to read the space. The link was stored inside the space, where every member could see and copy it, and it could also end up on pages published to the web. A leaked auto-approval link kept working even after the owner removed members, and a Viewer could use an Editor link to upgrade themselves. We addressed this with the new invitation flow: links are now private to the owner by default, auto-approval is always an explicit choice, and revoking a link rotates the space key and deletes the invite file. While an auto-approval link is active it still works as a key to the space, so for anything sensitive we recommend request-to-join links. For more detailed information, please see this post.
Medium: Ineffective Invite Revocation [ANY-01-013]:
This is tied to the invite link issue above. Revoking an auto-approval link didn’t change the space key, so anyone who had already used the link could keep reading new content.
With the new invitation flow, revoking a link rotates the space key, so the old link can’t decrypt anything written afterwards. What the link holder could read before the revocation, including the space’s earlier history, can’t be taken back. That part is by design: each new key in Anytype also unlocks the older ones, which is how new members can read a space’s history. We accept this trade-off.
Medium: Ownership Transfers [ANY-01-002]:
Transferring ownership in our model does not remove the original owner from the space — they stay as a member with their previous keys, which is why their access to member metadata persists. Metadata-key rotation is triggered by removal from the space, not by role change.
A space owner who wants the cryptographic cutoff Cure53 describes can achieve it today with a two-step action: transfer ownership, and then remove the former owner from the space. That sequence works as expected. We’ll revisit how this could be implemented more elegantly — likely as a single atomic operation — in a future protocol update.
Medium: Local API Sessions [ANY-01-005]:
The session tokens used by the Local API had no expiration date, so a stolen token could be used for as long as its session stayed open.
The Local API lets apps on your own device, such as Raycast or AI tools, work with your Anytype data. It has to be set up explicitly: an app only gets access once you create a key for it in Settings → Local API or approve its pairing request, and its tokens only work with the Anytype app running on the same device. A session token stops working when Anytype restarts. Since the audit we’ve also made revocation complete: revoking an app’s key in Settings now immediately ends every session that app opened. With API v2, you can also give an app’s key an expiry date, limit it to specific spaces, and make it read-only.
Medium: Activity Privacy [ANY-01-011]:
Anyone who knows a space’s ID could download its encrypted updates from a sync node, even without access to the space. They can’t read the content, but they could see when updates happened and roughly how large they were, for example when a message was sent in a chat. Content stays protected by encryption, and we believe the risk in normal use is low.
Nonetheless, Cure53’s feedback has pushed us toward a new authorization tier, in line with their recommendation. Delivering that is a major protocol overhaul, not a point fix. Design work is in progress; the goal is to get the structure right once so this class of leak is precluded by construction rather than patched.
Status of all findings
| ID | Finding | Severity | Status |
|---|---|---|---|
| ANY-01-001 | Crash through invalid public keys | Critical | Fixed |
| ANY-01-002 | Metadata keys not rotated on ownership transfer | Medium | Works as designed; remove the former owner to rotate keys |
| ANY-01-003 | No integrity checks on network configurations | Low | False positive, confirmed by Cure53 |
| ANY-01-004 | Outdated dependencies | Low | Partly fixed; remaining updates in progress |
| ANY-01-005 | Local API tokens don’t expire | Medium | Addressed: full revocation, plus expiring and scoped API keys |
| ANY-01-006 | Unsafe panic calls | Low | Fixed |
| ANY-01-007 | Possible crash in calcMedian | Low | Fixed |
| ANY-01-008 | Unsafe GetRandomString helper | Info | Fixed (helper removed) |
| ANY-01-009 | Encryption decision relied on an implicit check | Info | Fixed |
| ANY-01-010 | Private key leakage through invites | High | Addressed by the new invitation flow |
| ANY-01-011 | Activity metadata visible on sync nodes | Medium | Open: protocol redesign in progress |
| ANY-01-012 | Deprecated CID constants | Info | Fixed |
| ANY-01-013 | Ineffective invite revocation | Medium | Addressed: revoking rotates the key; earlier history stays readable by design |
| ANY-01-014 | Sync node queues can be flooded before authentication | Low | Open: planned |
| ANY-01-015 | Missing permission check on key changes | Critical | Fixed during the audit, verified by Cure53 |
| ANY-01-016 | Large invite file can crash apps when joining | Info | Open: planned (file nodes already block the original crash) |
| ANY-01-017 | Accepted access-control records not checked against the consensus node | Low | Fixed |
Moving Forward
We are incredibly grateful to the Cure53 team for their thorough work, and to the Open Impact Foundation for coordinating the audit. Ultimately, the report noted that our core cryptographic choices are strong and our approach to permission management is thoughtful. Even with the issues found, Cure53’s overall verdict “leans positively”, with the caveat that a system this large leaves room for implementation mistakes.
Data security is a moving target that requires constant vigilance and upkeep. As our product and the industry evolve, new vulnerabilities can naturally arise. We hope our community has found this report on our first security audit helpful.
Full Report File
Cure53 Security Audit ANY-01-report.pdf (530.2 KB)
(and do it regardless)
I wonder if there are vulnerabilities for local-only, which presumably should be less open to external threats?