{"slug": "dosu-security-incident-post-mortem", "title": "Dosu Security Incident Post-Mortem", "summary": "An attacker exploited an incorrect RLS policy check on org invitations to take over Dosu's internal organization and reached the company's CI pipeline, database and cloud project during an intrusion that ran from 04:11 to 07:59 UTC on November 2, 2026, CEO and founder Devin Stein disclosed in a post-mortem. Dosu's database provider Supabase detected the activity and alerted Dosu at 08:17 UTC; Dosu removed the attacker's accounts and sessions, rotated every production secret and fixed the invitation authorization check. Exposed data was limited to user names, email addresses, sign-in providers and sign-in times, while source code, messages, billing information, integration credentials and API keys were not exposed, and Dosu said the attacker's query patterns indicated a hunt for OpenAI and Anthropic API keys.", "body_md": "Nov 2, 2026 Security Incident Post-Mortem\nNovember 8, 2026 · Devin Stein, CEO & Founder\nSummary\nOn November 2, 2026, an attacker got into Dosu's production systems. They started with a free Dosu account, then exploited an RLS policy on org invitations to make themselves an owner of Dosu's own internal org.\nFrom there they redirected the Dosu internal org's integrations to a server they controlled, taking the integrations' credentials. With those credentials they reached our CI pipeline, our DB, and our cloud project. The main intrusion ran from 04:11 to 07:59 UTC on November 2. Earlier scanning started on October 31, and the last probes of our public endpoints came on November 4.\nOur database provider, Supabase, alerted us to the malicious activity. We cut off the attacker's access, rotated every production secret, and fixed the flaws they used.\nBased on the attacker's query patterns, we believe their goal was to find OpenAI and Anthropic API keys and other credentials. Their searches repeatedly targeted strings in those providers' key formats. And once they accessed our own, they immediately started to use them.\nExposed\nAccount details for Dosu users: names, email addresses, sign-in providers and sign-in times. No passwords.\nFor a small percentage of customers, pages Dosu indexed were impacted. We have contacted each of them directly.\nNot exposed\nSource code, messages and billing information.\nIntegration credentials and API keys. The attacker reached the tables that hold them, but credentials are encrypted and API keys are hashed.\nNo customer data was mutated.\nIf you have not already been contacted directly, you don't need to take any action.\nHow the attacker got in\nThe attacker went from a new account to our cloud project in under two hours. Each step used access gained in the step before it.\nReconnaissance (Oct 31 to Nov 2).\n From two IP addresses, the attacker scanned our public APIs and tried forged tokens. Every forged token was rejected.\nSign-up (05:59 UTC).\n They created a free Dosu account with Slack sign-in.\nOrg takeover (06:21 to 07:00).\n An incorrect RLS policy check let the attacker create an invitation to any org. The attacker invited themselves as owner of Dosu's internal org and of one open-source community org.\nIntegration credentials (06:42).\n As an owner, they changed the server URL of our internal org's integrations to a Cloudflare Quick Tunnel they controlled. Dosu then sent those integrations' credentials to the tunnel. These included a read-only database token and a GitHub token for our bot account.\nDatabase credentials (06:51 to 07:57).\n Using that database access, they collected further database credentials and used them to read tables and run commands in our database.\nCI credentials (07:50).\n With the bot's GitHub token, they opened a pull request to our internal repository. Our CI ran an infrastructure preview on pull requests with access to production cloud credentials. The pull request's code sent those credentials to the attacker.\nCloud project (07:52 to 07:59).\n With the cloud credentials, they deployed a small backdoor service and ran a few reconnaissance commands in it. Our org policy blocked every attempt to make it public. Their last action in our cloud project was at 07:59.\nAlong the way, they also tried to turn Dosu's own AI agent against us. They planted prompt-injection pages and asked the agent for secrets, environment variables and cloud metadata. The agent refused every request for credentials.\nHow we detected and contained it\nSupabase\n, our database provider, detected the malicious activity and alerted us at 08:17 UTC on November 2. We started our response straight away and treated every credential the attacker could have reached as exposed.\nWhat we did:\nRemoved the attacker's accounts, org memberships, pending invitations and OAuth apps, revoked their sessions, and reverted all changes they made to the DB and environment.\nFixed the invitation authorization check.\nRotated every production secret by 16:53 UTC: database credentials and signing keys, cloud service account keys, CI and deployment tokens, GitHub tokens and app keys, and keys for the third-party services we use.\nSigned out every session that could have been affected.\nLocked down our CI pipeline. Pull requests can no longer reach production credentials, and deployments now use short-lived credentials instead of stored keys.\nWhat this means for your data\nThe attacker had database-level access for about an hour on November 2. We reviewed all access logs. Here is what we found for each kind of data.\nData\nImpacted\nWhat we found\nAccount details\nYes\nThe attacker downloaded the list of Dosu user accounts: names, email addresses, sign-in providers and sign-in times. The list holds no passwords or password hashes.\nPages\nPartial\nFor some customers, the attacker read content Dosu had indexed from connected sources. We have contacted each of those customers directly.\nSource code\nNo\nNot affected. We rotated the Dosu GitHub App's keys, and its logs show no malicious activity in your repositories during the incident.\nMessages\nNo\nNot affected. We rotated the credentials Dosu uses to read your messages, and logs show no sign of malicious activity during the incident.\nIntegration credentials and API keys\nNo\nAttacker tried to access, but integration credentials are encrypted and API keys are hashed.\nBilling information\nNo\nNot affected.\nYour content in Dosu\nNo\nNo changes. The only content the attacker changed was two org avatars: Dosu's own and one public open-source org's. Both changes were cosmetic.\nIf we learn anything that changes this picture, we will contact affected customers directly.\nWhat you need to do\nNothing. We rotated every key and token Dosu holds on your behalf. You don't need to reconnect integrations or create new API keys.\nAs a precaution, we recommend you search your own logs for the indicators of compromise below. If you find a match, or have any questions, contact us at \nsecurity@dosu.dev\n.\nIndicators of compromise\nTwo IP addresses carried out the attack. We tie them to one operator through a shared TLS fingerprint. All times are UTC.\nIndicator\nType\nSeen (UTC)\nNotes\n185.209.178.153\nIPv4 (Latitude.sh)\nNov 2, 04:11–07:59\nMain attack address\n56.10.188.158\nIPv4 (AWS ap-southeast-1)\nOct 31 06:45 – Nov 4 04:35\nScanning and probing\nplains-roof-anybody-seasons.trycloudflare.com\nDomain\nNov 2, from 06:09\nTunnel the attacker pointed integrations at\nwebhook.site/42ecb092-44f0-4a9c-9b62-696d1405d911\nURL\nNov 2, 07:51\nWhere stolen CI credentials were sent\nfldubai.com\nEmail domain\nNov 2\nDomain of the attacker's accounts\nt13d3112h2_e8f1e7e78f70_b26ce05bbdd6\nTLS JA4\nOct 31 – Nov 4\nThe attacker's curl client, seen from both IPs\nt13d1813h1_85036bcba153_d339722ba4af\nTLS JA4\nOct 31 – Nov 2\nThe attacker's Python client\nARTEX-17785/1.0\nUser agent\nOct 31\nCustom; seen only from the attacker\nThe attacker's names for apps, branches and services used the prefixes\n \npentest\n, \nprobe\n and \nmq-probe-\n.\nTimeline (UTC)\nTime\nEvent\nOct 31, 06:45\nFirst scanning of Dosu's public APIs, from \n56.10.188.158\nNov 2, 04:11\nScanning starts from a second address, \n185.209.178.153\nNov 2, 05:59\nAttacker signs up for a Dosu account\nNov 2, 06:21–07:00\nAttacker makes themselves owner of Dosu's internal org and one open-source org\nNov 2, 06:42\nAttacker points our internal org's integrations at their tunnel and captures their credentials\nNov 2, 06:51\nAttacker starts querying our database\nNov 2, 07:27\nAttacker downloads the list of user accounts\nNov 2, 07:50\nAttacker opens a pull request with our bot's GitHub token; CI sends them production cloud credentials\nNov 2, 07:52\nAttacker deploys a backdoor service in our cloud project\nNov 2, 07:59\nAttacker's last action in our cloud project\nNov 2, 08:17\nSupabase alerts us to malicious activity; Dosu is unavailable until 11:28\nNov 2, 15:35\nInvitation authorization fix ships\nNov 2, 15:36\nStolen cloud key deleted\nNov 2, 16:53\nAll production secrets rotated\nNov 3, 05:29–05:34\n56.10.188.158\n probes our API; every request is rejected or gets only public data\nNov 3 – Nov 4\nCustomers notified\nNov 4, 04:35\nLast probe from \n56.10.188.158\n, against publicly readable data\nWhat we learned\nAll code that a frontier model hasn't reviewed is at risk. It has become irresponsible to write and review code without AI.\nThe flaw that let the attacker in was one missing check in one access policy written years ago by humans with minimal AI assistance. The vulnerability wasn't detected in multiple penetration tests at various points in time, including one the week prior to the incident.\nThe attacker used the ARTEX penetration testing framework. It sent more than 80,000 requests in 90 minutes and found the flaw within hours. Agents can do more sophisticated attacks, chain together series of vulnerabilities, and act faster than any human or even teams of humans could have prior.\nAnd unfortunately, this is only the beginning for attacks like this, and it's likely going to get much worse. The attacking model was intelligent, but limited in its malicious intent. The logs indicate the agent “believed” it was running a penetration test. If it had more malicious goals and training, the results could have been much worse.\nWe now assume that any code written by people or by older models has bugs like this, and that attackers' models will find them.\nWe are completely overhauling our security review process and going to conduct regular agent-based penetration tests of all externally exposed surface areas.\nOur commitment\nWe're sorry. You trust Dosu with access to your code and your team's knowledge.\nWe've published the details above so you can check your own systems, and so other teams can learn from our mistakes. If you have questions, contact \nsecurity@dosu.dev\n or email me directly at devin at dosu.dev.\nDevin Stein, CEO & Founder", "url": "https://wpnews.pro/news/dosu-security-incident-post-mortem", "canonical_source": "https://dosu.dev/security/incident-2026-11-02", "published_at": "2026-11-12 04:25:12+00:00", "updated_at": "2026-11-12 04:51:54.512336+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-startups"], "entities": ["Dosu", "Devin Stein", "Supabase", "OpenAI", "Anthropic", "GitHub", "Cloudflare"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/dosu-security-incident-post-mortem", "markdown": "https://wpnews.pro/news/dosu-security-incident-post-mortem.md", "text": "https://wpnews.pro/news/dosu-security-incident-post-mortem.txt", "jsonld": "https://wpnews.pro/news/dosu-security-incident-post-mortem.jsonld"}}