# What I learned auditing an open-source AI-memory SDK (and the bug I found in it)

> Source: <https://dev.to/walgo/what-i-learned-auditing-an-open-source-ai-memory-sdk-and-the-bug-i-found-in-it-13hc>
> Published: 2026-09-24 02:05:46+00:00

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.