审计开源 AI 记忆 SDK 的收获，以及我发现的一个漏洞

Most chatbots forget everything the moment a conversation ends. I spent a few days digging into an open-source project (MemWal / Walrus Memory) that tries to fix that — persistent, cross-session memory for AI agents — and ended up doing a full security review of the codebase along the way. Here's what actually stood out. ## The interesting part wasn't the AI Everyone talks about embeddings and semantic recall when they talk about "AI memory." The part that actually breaks in production is much more boring: ownership checks. Any system where User A's data must never leak into User B's session lives or dies on a handful of WHERE user_id = ? clauses. Get one of them wrong, and no amount of good embedding quality saves you. ## The bug While reviewing a sample chatbot app built on this SDK, I found a vote endpoint with a subtle but real bug: The "does a vote already exist?" check only looked up rows by messageId. The actual UPDATE was scoped by messageId AND chatId. Any user who could see a message in a public chat (message IDs are rendered right in the UI) could submit a vote using their own chat ID but a stranger's message ID. Since no vote existed yet for that message, it silently inserted a mismatched row. The nasty part: the next time the actual message owner tried to vote on their own message, the lookup found the attacker's row (again, scoped only by messageId), the UPDATE matched zero rows because the chatId didn't match, and the API returned 200 "Message voted" — while silently doing nothing. The real owner could never vote on that message again, and had no way of knowing why. Zero errors thrown. Zero logs. Just a permanently broken feature for one specific user, triggered by any other logged-in user. I filed it, the maintainers confirmed and shipped a fix within days: scope the existence check the same way as the update. ## The bigger lesson The core SDK, the auth layer, the on-chain contract — all of it was extremely well hardened. Constant-time comparisons, quarantine states, counter-based replay protection, the works. The bug wasn't in any of that. It was in a sample app that gets far less scrutiny than the "real" infrastructure around it. If you're reviewing (or building) a system like this, the example apps and demos are usually where the actual bugs hide — not the core library everyone stares at. ## A second, quieter finding ** I also found a spot where one sibling app (a login flow) had an on-chain verification step that its near-identical twin app was missing entirely — same function available in the codebase, just never called on one specific path. Lower severity (the affected app is explicitly demo-only and the riskiest downstream action was already disabled), but the same underlying lesson: **when you fix a security issue in one place, check every place that duplicates that logic. Copy-pasted auth code doesn't get security fixes for free. If you're building anything with persistent memory/state across sessions for an AI agent, happy to talk through what to watch for. This was part of a hackathon bug-bounty track, but the lessons apply to basically any multi-tenant app. This was part of Walrus Sessions 8 If any of this sounds interesting, Walrus Sessions 8: "Chatbots That Remember" is a live hackathon session running Sept 18 – Oct 9, 2026, with $2,500 in WAL prizes. The challenge: build (or retrofit) a chatbot that uses Walrus Memory to remember context across sessions, users, and devices — any use case counts (support, onboarding, tutoring, game NPCs, community bots). There's also a standalone Bug Bounty track (5 × $100) if finding bugs like the one above is more your thing than building a full chatbot — no chatbot required, just a reproducible bug filed on GitHub. Full details & rules: [link] MemWal repo: https://github.com/MystenLabs/MemWal