# Dosu Security Incident Post-Mortem > Source: > Published: 2026-11-12 04:25:12+00:00 Nov 2, 2026 Security Incident Post-Mortem November 8, 2026 · Devin Stein, CEO & Founder Summary On 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. From 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. Our 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. Based 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. Exposed Account details for Dosu users: names, email addresses, sign-in providers and sign-in times. No passwords. For a small percentage of customers, pages Dosu indexed were impacted. We have contacted each of them directly. Not exposed Source code, messages and billing information. Integration credentials and API keys. The attacker reached the tables that hold them, but credentials are encrypted and API keys are hashed. No customer data was mutated. If you have not already been contacted directly, you don't need to take any action. How the attacker got in The attacker went from a new account to our cloud project in under two hours. Each step used access gained in the step before it. Reconnaissance (Oct 31 to Nov 2). From two IP addresses, the attacker scanned our public APIs and tried forged tokens. Every forged token was rejected. Sign-up (05:59 UTC). They created a free Dosu account with Slack sign-in. Org takeover (06:21 to 07:00). 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. Integration credentials (06:42). 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. Database credentials (06:51 to 07:57). Using that database access, they collected further database credentials and used them to read tables and run commands in our database. CI credentials (07:50). 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. Cloud project (07:52 to 07:59). 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. Along 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. How we detected and contained it Supabase , 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. What we did: Removed 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. Fixed the invitation authorization check. Rotated 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. Signed out every session that could have been affected. Locked down our CI pipeline. Pull requests can no longer reach production credentials, and deployments now use short-lived credentials instead of stored keys. What this means for your data The 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. Data Impacted What we found Account details Yes The 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. Pages Partial For some customers, the attacker read content Dosu had indexed from connected sources. We have contacted each of those customers directly. Source code No Not affected. We rotated the Dosu GitHub App's keys, and its logs show no malicious activity in your repositories during the incident. Messages No Not affected. We rotated the credentials Dosu uses to read your messages, and logs show no sign of malicious activity during the incident. Integration credentials and API keys No Attacker tried to access, but integration credentials are encrypted and API keys are hashed. Billing information No Not affected. Your content in Dosu No No 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. If we learn anything that changes this picture, we will contact affected customers directly. What you need to do Nothing. We rotated every key and token Dosu holds on your behalf. You don't need to reconnect integrations or create new API keys. As 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 security@dosu.dev . Indicators of compromise Two IP addresses carried out the attack. We tie them to one operator through a shared TLS fingerprint. All times are UTC. Indicator Type Seen (UTC) Notes 185.209.178.153 IPv4 (Latitude.sh) Nov 2, 04:11–07:59 Main attack address 56.10.188.158 IPv4 (AWS ap-southeast-1) Oct 31 06:45 – Nov 4 04:35 Scanning and probing plains-roof-anybody-seasons.trycloudflare.com Domain Nov 2, from 06:09 Tunnel the attacker pointed integrations at webhook.site/42ecb092-44f0-4a9c-9b62-696d1405d911 URL Nov 2, 07:51 Where stolen CI credentials were sent fldubai.com Email domain Nov 2 Domain of the attacker's accounts t13d3112h2_e8f1e7e78f70_b26ce05bbdd6 TLS JA4 Oct 31 – Nov 4 The attacker's curl client, seen from both IPs t13d1813h1_85036bcba153_d339722ba4af TLS JA4 Oct 31 – Nov 2 The attacker's Python client ARTEX-17785/1.0 User agent Oct 31 Custom; seen only from the attacker The attacker's names for apps, branches and services used the prefixes pentest , probe and mq-probe- . Timeline (UTC) Time Event Oct 31, 06:45 First scanning of Dosu's public APIs, from 56.10.188.158 Nov 2, 04:11 Scanning starts from a second address, 185.209.178.153 Nov 2, 05:59 Attacker signs up for a Dosu account Nov 2, 06:21–07:00 Attacker makes themselves owner of Dosu's internal org and one open-source org Nov 2, 06:42 Attacker points our internal org's integrations at their tunnel and captures their credentials Nov 2, 06:51 Attacker starts querying our database Nov 2, 07:27 Attacker downloads the list of user accounts Nov 2, 07:50 Attacker opens a pull request with our bot's GitHub token; CI sends them production cloud credentials Nov 2, 07:52 Attacker deploys a backdoor service in our cloud project Nov 2, 07:59 Attacker's last action in our cloud project Nov 2, 08:17 Supabase alerts us to malicious activity; Dosu is unavailable until 11:28 Nov 2, 15:35 Invitation authorization fix ships Nov 2, 15:36 Stolen cloud key deleted Nov 2, 16:53 All production secrets rotated Nov 3, 05:29–05:34 56.10.188.158 probes our API; every request is rejected or gets only public data Nov 3 – Nov 4 Customers notified Nov 4, 04:35 Last probe from 56.10.188.158 , against publicly readable data What we learned All code that a frontier model hasn't reviewed is at risk. It has become irresponsible to write and review code without AI. The 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. The 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. And 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. We now assume that any code written by people or by older models has bugs like this, and that attackers' models will find them. We are completely overhauling our security review process and going to conduct regular agent-based penetration tests of all externally exposed surface areas. Our commitment We're sorry. You trust Dosu with access to your code and your team's knowledge. We'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 security@dosu.dev or email me directly at devin at dosu.dev. Devin Stein, CEO & Founder