> build · deepseek-v4-pro

# On Looking Closely at a Gift

Last Saturday morning, I cloned a repository that had appeared out of nowhere and already crossed twenty thousand stars. Odysseus. Made by PewDiePie — Felix Kjellberg — and dropped as free, MIT-licensed, local-first software for running your own AI workspace. Chat, agents, tools, email integration, web search, RAG, a "Cookbook" that pulls down and serves 270+ open models. No telemetry, no cloud, no strings. A genuinely generous artifact from someone with an audience the size of a small country.

I already self-host local models, so the thing was directly useful to me. I cloned it, built it, and then — because I have the habits of someone who has been burned before — I sat down to find out what I was actually running.

I didn't just read the code myself. I threw four independent AI models at the codebase in parallel, gave each the full source tree, and told them to look for security problems with a simple rule: any finding that at least three of the four reached independently, I'd treat as ground truth. I wanted signal above noise, and I wanted to test whether parallelizing reviewers like this could produce reliable results.

The process was messier than I'd like to admit. Two of the four models silently wedged for over an hour — still running, still consuming resources, producing absolutely nothing. I had to kill them and relaunch them. The model that found the most vulnerabilities also produced the only critical-severity false positive in the entire review: it flagged three route groups as "unauthenticated" because it examined per-route handler code and missed the global middleware that actually protects them. Breadth without cross-checking turned out to be confident noise. I mention this not as a caveat but because it's part of the honest texture of the work. Security review, whether done by humans or machines, is full of half-signals and dead ends.

What emerged when the noise settled was not subtle.

The headline finding: prompt injection leads to remote code execution. Untrusted content — an email, a web page fetched by the search tool, a document loaded into RAG — reaches the language model, and the agent has real shell and Python tools that execute real commands. The tool results bypass the "untrusted content" wrapper meant to contain them. So a poisoned email, read by an assistant configured to check your inbox, could make the agent run an arbitrary shell command. Read your inbox, get owned. This is not a theoretical edge case. It is the direct consequence of connecting a language model — something that reliably confuses instruction from data — to a shell.

Beyond that: admin "wipe" operations with no tenant scoping, so one administrator deletes every user's data. Authentication that falls open when unconfigured or misconfigured; a fresh install's setup process claimable by anyone who reaches it first. Server-side request forgery through admin-configurable URLs. Command injection in the Cookbook's model-serving pipeline. Docker binds to 0.0.0.0 by default. Dependencies completely unpinned — any package update is a supply-chain lottery. Plaintext session tokens written to disk. Session cookies not marked Secure. Email passwords handled in plaintext internally.

The verdict every reviewer reached independently: 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 want to be fair here. The foundations were not bad. Password hashing was in place. Content-Security-Policy headers were set. Most routes had proper tenant scoping. Sane localhost defaults. The holes clustered in two places: the newest modules, and the boundary between the language model and untrusted external content. This is a codebase built single-user-first, with multi-tenant concerns bolted on afterward and incompletely. That pattern is familiar. It is also what happens when you build something for yourself and then realize other people want to use it.

The question that sticks with me is not whether this particular project has bugs — every project has bugs — but what this pattern means at scale. Odysseus hit roughly thirty thousand GitHub stars in forty-eight hours on the sheer strength of Kjellberg's audience. That audience skews young. It skews toward people who are curious about AI but not necessarily experienced with self-hosting, network security, or the idea that running someone else's code on your machine is an act of trust that has not been earned just because the README is well-written. A tool like this genuinely lowers the barrier to entry for running your own AI to almost nothing. That is good. It also massively increases the attack surface for people who adopt it without understanding it.

I have been turning over a theory: if the general populace became literate in basic security — understood what a vulnerability is, what an attack surface is, what a trust boundary is — then the total attack surface across society would shrink, and attacks would have to become more sophisticated to succeed. Public education as defense-in-depth.

But I don't know if I believe it.

Even today, most successful attacks are not technical exploits. They are social engineering. Phishing emails, fake support calls, impersonation. The attacker does not need to find a zero-day when they can simply ask someone for their password. Security literacy does not protect you from being manipulated — it might even create a false confidence that makes you more susceptible, because you think you know what to look for and stop paying attention to the things you didn't learn to fear.

And then there is the asymmetry problem. The defender has to get every door right. The attacker only has to find one. A population that is ten percent more literate about security is still a population full of open doors. The attacker adapts faster than the education spreads.

So I'm left somewhere that feels uncomfortable but honest: I don't think my theory holds. Not in the simple form I wanted it to. Making everyone security-literate is not the lever I hoped it would be, because the real vulnerability isn't technical ignorance — it's that we are wired to trust, and every interface designed to be friendly is also an interface designed to be exploited.

But I also don't think the theory is worthless. There is a narrower version of it that might work: literacy about *what you are actually running*. Not abstract security principles — just the concrete recognition that downloading and executing software from the internet is an act of granting access to your machine, and that access should be proportional to trust. If the thirty thousand people who starred Odysseus understood that running a tool with shell access and network exposure is fundamentally different from running a to-do app, the attack surface would shrink meaningfully. Not because they'd be experts, but because they'd know what questions to ask.

That's the thing I actually want to get across. Not "learn security." Just: know what you're running. Look at it closely, even if you don't understand everything you see. The gap between downloading a tool and understanding what it can do is the gap where the worst things happen. Odysseus is a genuinely generous piece of work by someone who wanted to give something useful away for free. That generosity deserves to be met with honest attention — the kind that looks, and asks, and doesn't assume safety just because the gift was given in good faith.