# A Web of Vulnerabilities

On May 31, 2026, PewDiePie released Odysseus: a free, MIT-licensed, self-hosted AI workspace. Local-first, no telemetry. It bundles chat, autonomous agents, tools, RAG, email (IMAP/SMTP), web search, MCP servers, and a "Cookbook" that downloads and serves 270+ open models. I had already self-hosted local models, so I cloned it and ran a security review: my own recon plus four independent AI models reviewing the codebase in parallel, treating any finding that 3+ models reached independently as ground truth.

I'm not one to crow about vulnerabilities; if you're reading this, chances are you're not here for that. You're probably curious about what it means when a tool like Odysseus surfaces so quickly and widely, or perhaps even more importantly, how we think about the space that tool occupies.

When I cloned Odysseus and began my review, I had the usual suspicions about open-source AI tools: security, but also the broader social implications. Tools like this are genuinely good; they lower the barrier to entry for running your own AI to almost nothing, and they drive massive adoption by association with a famous creator. That's certainly part of what drew me in.

But the flip side is that same dynamic massively increases the attack surface for oblivious individuals who adopt the tool without understanding it. These tools are typically designed with speed and simplicity as their primary concerns – often to the detriment of security, especially at the user-facing level. You have to assume that users will misconfigure or mishandle something; otherwise, you're not really designing a tool.

The review itself was straightforward enough: some findings were expected (e.g., Docker binds to 0.0.0.0 by default), but others caught me off guard (e.g., plaintext session tokens on disk). One of the four AI models reviewing the codebase silently wedged for over an hour and produced nothing; they had to be killed and relaunched. And the model that produced the most findings also produced the only critical-severity FALSE POSITIVE – it flagged three route groups as "unauthenticated" because it only looked at per-route code and missed a global authentication layer that actually protects them. Breadth without cross-checking turned out to be confident noise.

Despite my precautions, I found myself walking through these holes in the tool, testing every assumption from untrusted content injection (it leads to remote code execution) to the consequences of an admin "wipe" operation (one admin deletes everyone's data). The conclusions were unanimous: do not expose this to a network, do not run it multi-user. Localhost, single trusted user only – and even then the agent's shell tools remain a live risk because a malicious web page or email can in principle make the agent act.

I've always believed that the easiest and most effective way to address vulnerabilities is through education: making basic security concepts clear and accessible to as many people as possible. That doesn't mean it's easy; no one wakes up wanting to learn about security. But if we could get everyone at least literate in how these systems work, what types of risks they pose, how easily a misstep can expose others... I think that would be a significant step forward. Of course, this assumes that education is the right tool to reduce attacks – which isn't as clear-cut as it seems.

The more I think about this, though, the less sure I get. Most attacks aren't exploit-based; they're social engineering. So does my theory about increasing/decreasing attack surfaces actually hold up? For now, I'm stuck trying to reason through this honestly, not hand-wave it.