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:
messageId. 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.
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.
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.