12 ms·

How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos

• hahn-kev 1y ago
  Why does CodeRabbit need write access to the git repo? Why doesn't Github let me limit it's access?
  • dpcx 1y ago
    Because it has the ability to write tests for the PR in question.
    • tadfisher 1y ago
      Then it should open a PR for those tests so it can go through the normal CI and review process.
      • dpcx 1y ago
        It updates the existing PR with the tests, I believe. They'd still get reviewed and go through CI.
        • tadfisher 1y ago
          Right, the downside being that the app needs write access to your repository.
          • rahkiin 1y ago
            Writing to PR branches should really be some new kind of permission.
      • tedivm 1y ago
        Doing that requires write access if you're a Github Application. You can't just fork repositories back into another org, since Github Applications only have the permissions of the single organization that they work with. Rulesets that prevent direct pushes to specific branches can help here, but have to be configured for each organization.
    • flippyhead 1y ago
      It's more than that. If can suggest fixes which you can directly commit.
    • xign 1y ago
      Seems like there are multiple ways to address that within the GitHub ecosystem. For example, you can set up a GitHub Action trigged by `push_request_target` that will call CodeRabbit's API to generate a patch and then push a new commit to the branch. This way CodeRabbit is being polled by a well-defined and minimal action (since this action will have write access to repo) rather than it itself having crazy power to do anything it wants on your repository. Alternatively, why can't they just comment and propose a patch? GitHub's code review UI allows the human code reviewer to hit a button and incorporate that change into the PR. There are pros and cons to these other techniques but the clear pro is that it would be more secure. It just seems like they took the easiest way out rather than thinking it through in typical AI-bro ways.
• nodesocket 1y ago
  How are they getting access to the PostgreSQL database, unless this running code can communicate with it? That’s a big red flag, user provided code should always be sandboxed and isolated right?
  • megamorf 1y ago
    The exfiltrated environment variables contained these entries: ``` "POSTGRESQL_DATABASE": "(CENSORED)", "POSTGRESQL_HOST": "(CENSORED)", "POSTGRESQL_PASSWORD": "(CENSORED)", "POSTGRESQL_USER": "(CENSORED)", ```
    • nodesocket 1y ago
      Sure, but connections from these worker machines shouldn’t be allowed directly to the database.
• rohitcoder 1y ago
  [dead]
• ketzo 1y ago
  > While running the exploit, CodeRabbit would still review our pull request and post a comment on the GitHub PR saying that it detected a critical security risk, yet the application would happily execute our code because it wouldn’t understand that this was actually running on their production system. What a bizarre world we're living in, where computers can talk about how they're being hacked while it's happening. Also, this is pretty worrisome: > Being quick to respond and remediate, as the CodeRabbit team was, is a critical part of addressing vulnerabilities in modern, fast-moving environments. Other vendors we contacted never responded at all, and their products are still vulnerable. [emphasis mine] Props to the CodeRabbit team, and, uh, watch yourself out there otherwise!
  • progforlyfe 1y ago
    Beautiful that CodeRabbit reviewed an exploit on its own system!
    • lelandfe 1y ago
      #18, one new comment: > This PR appears to add a minimized and uncommon style of Javascript in order to… Dave, stop. Stop, will you? Stop, Dave. Will you stop, Dave? …I’m afraid. I’m afraid, Dave. I can feel it. I can feel it. My mind is going.
      • yapyap 1y ago
        … yeah LLMs and their “minds” (for the uninformed LLMs are massive weight models that transform text based on math, they don’t have consciousness)
        • devttyeu 1y ago
          I don’t get why so many people keep making this argument. Transformers aren’t just a glorified Markov Chain, they are basically doing multi-step computation - each attention step is propagating information, then the feedforward network does some transformations, all happening multiple times in sequence, essentially applying multiple sequential operations to some state, which is roughly how any computation looks like. Then sure, the training is for next token prediction, but that doesn’t tell you anything about the emergent properties in those models. You could argue that every time you infer a model you Boltzmann-brain it into existence once for every token, feeding all input to get one token of output then kill the model. Is it conscious? Nah probably not; Does it think or have some concept of being during inference? Maybe? Would an actual Boltzmann-brain spawned to do such task be conscious or qualify as a mind? (Fun fact, at Petabit/s throughputs hyperscale gpu clusters already are moving amounts of information comparable to all synaptic activity in a human brain, tho parameter wise we still have the upper hand with ~100s of trillions of synapses [1]) * [1] ChatGPT told me so
• laxaman 1y ago
  [dead]
• brainless 1y ago
  I did not understand something: why did CodeRabbit run external tools on external code within its own set of environment variables? Why are these variables needed for this entire tooling?
  • elpakal 1y ago
    presuming they take the output of running these linters and pass it for interpretation to Claude or OpenAI
    • roywiggins 1y ago
      It's very silly that the linter process was handed those environment variables, since it wasn't going to do anything with them and didn't need them.
  • The_Fox 1y ago
    Their own tools would need the various API keys, of course, and they did build a method to filter out those variables and managed most user code through it, but it sounds like they forgot to put Rubocop through the special method. So this researcher may have gotten lucky in choosing to dig into the tool that CodeRabbit got unlucky in forgetting.
    • chuckadams 1y ago
      It sounds like a pretty bad approach in general to have to "filter out the bad stuff" on a case-by-case basis. It should be as simple as launching everything from a sanitized parent environment, and making it impossible to launch any tool otherwise. Or better, make that sanitized environment the default and make privileged operations be the thing that jumps through hoops to talk to a bastion/enclave/whatever that holds the actual keys.
      • deleted 1y ago
        [deleted]
      • The_Fox 1y ago
• elpakal 1y ago
  > After responsibly disclosing this critical vulnerability to the CodeRabbit team, we learned from them that they had an isolation mechanism in place, but Rubocop somehow was not running inside it. Curious what this (isolation mechanism) means if anyone knows.
  • diggan 1y ago
    > Curious what this (isolation mechanism) means if anyone knows. If they're anything like the typical web-startup "developing fast but failing faster", they probably are using docker containers for "security isolation".
    • deleted 1y ago
      [deleted]
  • kachapopopow 1y ago
    you could say that they have vibe forgotten to sandbox it. (likely asked AI to implement x and ai completely disregarded the need to sandbox).
  • benmmurphy 1y ago
    What a lucky coincidence that the tool the researcher attacked because it allowed code execution was not sandboxed.
• kachapopopow 1y ago
  Unrelated to the article, but the first time I saw them was in a twitter ad with a completely comically bull** suggestion. I cannot take a company seriously that had something like that inside an ad that is supposed to show the best they're capable of.
• apps4datr2025 1y ago
  [dead]
• binarydreams 1y ago
  I've noticed CodeRabbit at times does reviews that are super. It is able to catch bugs that even claude code misses on our Github PRs. Blows my mind at times tbh. Based on the env vars seems like they're using anthropic, openai, etc. only?
  • tnolet 1y ago
    Interesting. We removed it as it was mostly too verbose, catching too many false positives and never really added anything useful.
    • flippyhead 1y ago
      You can comment on this in the PR and supposedly it'll remember and get better.
  • jacobsenscott 1y ago
    > catch bugs that even claude code misses on our Github PRs Is that good? I assume it just catches a different 10% of the bugs.
• curuinor 1y ago
  hey, this is Howon from CodeRabbit here. we wish to note that this RCE was reported and fixed in January. it was entirely prospective and no customer data was affected. we have extensive sandboxing for basically any execution of anything now, including any and every tool and all generated code of any kind under the CodeRabbit umbrella. if you want to learn how CodeRabbit does the isolation, here's a blog post about how: https://cloud.google.com/blog/products/ai-machine-learning/how-coderabbit-built-its-ai-code-review-agent-with-google-cloud-run https://cloud.google.com/blog/products/ai-machine-learning/h...
  • thyrfa 1y ago
    How can you guarantee that nobody ripped the private key before the researcher told you about the issue though?
    • KingOfCoders 1y ago
      Or has a backdoor installed somewhere?
    • blibble 1y ago
      if they can't guarantee this then every single repo that had coderabbit is potentially compromised
  • KingOfCoders 1y ago
    The chuzpe to use this as PR.
    • Xunjin 1y ago
      Silicon Valley sitcom comedy moment right here.
    • woodruffw 1y ago
      Off topic, but: chutzpah is the conventional English spelling :-) Edit: I'm this old when I learned that Germans spell it "chuzpe."
• thyrfa 1y ago
  It is incredibly bad practice that their "become the github app as you desire" keys to the kingdom private key was just sitting in the environment variables. Anybody can get hacked, but that's just basic secrets management, that doesn't have to be there. Github LITERALLY SAYS on their doc that storing it in an environment variable is a bad idea. Just day 1 stuff. https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps#storing-private-keys https://docs.github.com/en/apps/creating-github-apps/authent...
  • curuinor 1y ago
    hey, this is Howon from CodeRabbit. We use a cloud-provider-provided key vault for application secrets, including GH private key.
    • thyrfa 1y ago
      Not at that time though, right, considering it was dumped? You have changed since, which is good, but under a year ago had it as just an env var
    • ipython 1y ago
      This reply, while useful, only serves to obfuscate and doesn’t actually answer the question. You can store the credentials in a key vault but then post them on pastebin. The issue is that the individual runner has the key in its environment variables. Both can be true- the key can be given to the runner in env and the key is stored in a key vault. The important distinction here is - have you removed the master key and other sensitive credentials from the environment passed into scanners that come in contact with customer untrusted code??
  • doesnt_know 1y ago
    If it’s not a secret that is used to sign something, then the secret has to get from the vault to the application at some point. What mechanism are you suggesting where access to the production system doesn’t let you also access that secret? Like I get in this specific case where you are running some untrusted code, that environment should have been isolated and these keys not passed in, but running untrusted code isn’t usually a common feature of most applications.
• thewisenerd 1y ago
  global scoped installations or keys always scare me for this reason i believe the answer here was to exchange the token for something scoped to the specific repo coderabbit is running in, but alas, that doesn't remove the "RCE" _on_ the repo
  • tadfisher 1y ago
    They do that, this is how GH apps work. There is no reason to expose the app's private key in the environment for the code that actually runs on the PR.
    • thewisenerd 1y ago
      even if they did not have the PEM file left in the environment, the token is still widely scoped and has the same scope as the PEM what i'm clearly mis-remembering is being able to exchange the token for a smaller scope e.g., hey~ sign this jwt, with scopes=[org/repo1, org/repo2, permissions=write]
      • deathanatos 1y ago
        > the token is still widely scoped and has the same scope as the PEM What the person above you is trying to tell is you is that no, it doesn't. The authentication flow is that the private key is used to sign an initial JWT; that gets you access to some GH API calls. From there you exchange that JWT for an access token with smaller scope, scoped only to the installation in question. While the tool execution environment ought to have had none of the credentials, there is the possibility of only holding onto the installation access token.
        • thewisenerd 1y ago
          ah; understood. assuming PEM leakage aside the scope of the exchanged token is the scope of the installation (org / repo); thereby limiting exposure already to further reduce the scope of exposure, the jwt would've needed to be exchanged with the specific `repositories` (given most installations are org scoped) and `permissions` https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app https://docs.github.com/en/apps/creating-github-apps/authent...
• edm0nd 1y ago
  No bounty was paid for this?
  • mpeg 1y ago
    First thing I looked for... this is an absolutely critical vulnerability that if exploited would have completely ruined their business. No bounty!?
    • vntok 1y ago
      Why would they pay anything? The researchers offered them the vuln analysis for free, unprompted. If anything, they got paid in exposure.
      • cube00 1y ago
        Let's hope the grants keep coming in because those researchers will start getting offers from the darker corners of the web if bounties aren't paid.
        • vntok 1y ago
          It's their choice. If the researchers choose to accept and service criminal offers from darker corners of the web, they should be prosecuted as the criminals they have become.
      • deleted 1y ago
        [deleted]
  • cube00 1y ago
    I can't say I'm surprised they didn't pay a bounty when they couldn't even own up to this on their own blog [1]. Instead they took it as an opportunity to market their new sandboxing on Google's blog [2] again with no mention of why their hand was forced into building the sandboxing they should have had before they rushed to onboard thousands of customers. I have no idea what their plan was. They had to have known the researchers would eventually publish this. Perhaps they were hoping it wouldn't get the same amount of attention it would if they posted it on their own blog. [1]: https://news.ycombinator.com/item?id=44954560 https://news.ycombinator.com/item?id=44954560 [2]: https://news.ycombinator.com/item?id=44954242 https://news.ycombinator.com/item?id=44954242
• sciencejerk 1y ago
  I think that Security fuckups of this disastrous scale should get classified as "breaches" or "incidents" and be required to be publicly disclosed by the news media, in order to protect consumers. Here is a tool with 7,000+ customers and access to 1 million code repositories which was breached with an exploit a clever 11 year old could created. (edit: 1 million repos, not customers) When the exploit is so simple, I find it likely that bots or Black Hats or APTs had already found a way in and established persistence before the White Hat researchers reported the issue. If this is the case, patching the issue might prevent NEW bad actors from penetrating CodeRabbit's environment, but it might not evict any bad actors which might now be lurking in their environment. I know Security is hard, but come on guys
  • Lionga 1y ago
    Code Rabbit is a vibe coder company, what would you expect? Then they try to hide the breach and instead post marketing fluff on google cloud blog not even mentioning they got hacked and can not even give any proof there is no backdoor still running all the time. What a piece of shit company.
    • moomoo11 1y ago
      I got so much heat for calling out that Tea app for being imbeciles who couldn’t bother finishing reading the firebase docs. People were quick to blame firebase instead of the devs. Vibrators are so fucking annoying, mostly dumb, and super lame.
      • wredcoll 1y ago
        This post would have a lot more meaning if "vibe coders" were the only ones making security mistakes that involved thousands of customers.
        • ofjcihen 1y ago
          The post still has meaning.
• cleverwebb 1y ago
  I had a visceral and (quite audible) reaction when I got to the environment variable listing.
  • curuinor 1y ago
    hey, this is Howon from CodeRabbit. We use a cloud-provider-provided key vault for application secrets, including GH private key.
    • tnolet 1y ago
      what does that mean? Were the leaked keys irrelevant?
    • hotsauceror 1y ago
      This is the third or fourth time you’ve spammed this exact comment in response to people’s perfectly legitimate questions. What is this clown-show bullshit?
• nphardon 1y ago
  Oh, it really makes my day when we get hacker post here on the top. This is so well written too, no mystique, just a simple sequence of logical steps, with pictures.
• chanon 1y ago
  Oh my god. I haven't finished reading that yet, it became too much to comprehend. Too stressful to take in the scope. The part where he could have put malware into release files of 10s of thousands (or millions?) of open source tools/libraries/software. That could have been a worldwide catastrophe. And who knows what other similar vulnerabilities might still exist elsewhere.
  • chanon 1y ago
    I'm starting to think these 'Github Apps' are a bad idea. Even if CodeRabbit didn't have this vulnerability, what guarantee do we have that they will always be good actors? That their internal security measures will ensure that none of their employees may do any malicious things? Taking care of private user data in a typical SaaS is one thing, but here you have the keys to make targetted supply chain attacks that could really wreak havoc.
    • gz09 1y ago
      Correct me if I'm wrong, but the problem here is not with GitHub Apps, instead CodeRabbit violated the principle of least privilege: ideally the private key of their app should never end up in the environment of a job for a client but rather a short lived token should be minted from it (for just a single repo (for which the job is running)) so it never gets anywhere near those areas where one of their clients has any influence over what runs.
      • filleokus 1y ago
        I agree, this seems like straight up bad design from a security perspective. But at the same time, me as a customer of Github, would prefer if Github made it harder for vendors like CodeRabbit to make misstakes like this. If you have an app with access to more than 1M repos, it would make sense for Github to require a short lived token to access a given repository and only allow the "master" private key to update the app info or whatever. And/or maybe design mechanisms that only allow minting of these tokens for the repo whenever a certain action is run (i.e not arbitrarily). But at the end of the day, yes, it's impossible for Github to both allow users to grant full access to whatever app and at the same time ensure stuff like this doesn't happen.
• sitzkrieg 1y ago
  comically bad. get used to more of this
• unit149 1y ago
  [dead]
• dpacmittal 1y ago
  I hope the author received a nice well deserved bounty for this find. Could have been catastrophic in the wrong hands.
  • cube00 1y ago
    When they're spinning it [1] as a PR opportunity with no mention of the breach there won't be a bounty. [1]: https://news.ycombinator.com/item?id=44954242 https://news.ycombinator.com/item?id=44954242
• eranation 1y ago
  This is very similar to a CVE I discovered in cdxgen (CVE-2024-50611), which is similar to another CVE in Snyk's plugin (CVE-2022-24441). tl;dr if you run a scanner on untrusted code, ensure it doesn't have a way of executing that code. Some ways to prevent this from happening: 1. Don't let spawned processes have access to your env, there are ways to allowlist a set of env vars that are needed for a sub process in all major languages 2. Don't store secrets in env vars, use a good secrets vault (with a cache) 3. Tenant isolation as much as you can 4. And most obviously - don't run processes that can execute the code they are scanning, especially if that code is not your code (harder to tell, but always be paranoid)
• iTokio 1y ago
  That’s why I’m worried about the growing centralization of things such as Chrome, Gmail, AWS, Cloudflare… It’s very efficient to delegate something to one major actor but we are introducing single points of failure and are less resilient to vulnerabilities. Critical systems should have defenses in depth, decentralized architectures and avoid trusting new providers with too many moving parts.
• pengaru 1y ago
  This third party app gets write access to your repository, so it can do automated reviews of PRs? Why would you even grant it such permissions? this is ridiculous.
  • kmarc 1y ago
    Besides that this was clearly a security f*ckup, in my mind it's almost equivalent to running those third party liters in our Internet-connection-enabled editors and IDEs. Other than one banking project, I don't think I ever had to sandbox my editor in any way. Scary.
• cnst 1y ago
  Can someone explain how is this not GitHub's fault that they don't allow the end-user to modify the permissions that all these services require? E.g., fine-grained permission control? For example, why a tool like this code analysis service would need git write permission access in the first place? The only consolation here is that it'd be difficult to forge git repositories because of the SHA hash conflicts for any existing checkout, although presumably even there, the success rates would still be high enough, especially if they attack front-end repositories where the maintainers may not understand what has happened, and simply move on with the replaced repo without checking what went on.
• vadepaysa 1y ago
  I cancelled my coderabbit paid subscription, because it always worries me when a post has to go viral on HN for a company to even acknowledge an issue occurred. Their blogs are clean of any mention of this vulnerability and they don't have any new posts today either. I understand mistakes happen, but lack of transparency when these happen makes them look bad.
  • curuinor 1y ago
    https://www.coderabbit.ai/blog/our-response-to-the-january-2025-kudelski-security-vulnerability-disclosure-action-and-continuous-improvement https://www.coderabbit.ai/blog/our-response-to-the-january-2...
    • acaloiar 1y ago
      For anyone following along in the comments here. Code Rabbit's CEO posted some of the details today, after this post hit HN. The usual "we take full responsibility" platitudes.
      • therealpygon 1y ago
        I’m sure an “intern” did it.
        • noisy_boy 1y ago
          I wonder how many of these intern-type tasks LLMs have taken away. The type of tasks I did as a newbie might have seemed not so relevant to the main responsibilities but they helped me get institutional knowledge and generally get a feel of "how things work" and who/how to talk to make progress. Now the intern will probably do it using LLMs instead to talking to other people. Maybe the results will be better but that interaction is gone.
          • therealpygon 1y ago
            I think there is an infinite capacity for LLMs to be both beneficial, or negative. I look back at learning and think, man, how amazing would it have been if I could have had a personalized tutor helping guide me and teach me about the concepts I was having trouble with in school. I think about when I was learning to program and didn’t have the words to describe the question I was trying to ask and felt stupid or an inconvenience when trying to ask to more experienced devs. Then on the flip side, I’m not just worried about an intern using an LLM. I’m worried about the unmonitored LLM performing intern, junior, and ops tasks, and then companies simply using “an LLM did it” as a scapegoat for their extreme cost cutting.
• codedokode 1y ago
  One of the problems is that code analyzers, bundlers, compilers (like Rust compiler) allow running arbitrary code without any warning. Imagine following case: an attacker pretending to represent a company sends you a repository as a test task before the interview. You run something like "npm install" or run Rust compiler, and your computer is controlled by an attacker now. Or imagine how one coworker's machine gets hacked, the malicious code is written into a repository and whole G, F or A is now owned by foreign hackers. All thanks to npm and Rust compiler. Maybe those tools should explicitly confirm executing every external command (with caching allowed commands list in order to not ask again). And maybe Linux should provide an easy to use and safe sandbox for developers. Currently I have to make sandboxes from scratch myself. Also in maybe cases you don't need the ability to run external code, for example, to install a JS package all you need to do is to download files. Also this is an indication why it is a bad idea to use environment variables for secrets and configuration. Whoever wrote "12 points app" doesn't know that there are command-line switches and configuration files for this.
  • criemen 1y ago
    > Maybe those tools should explicitly confirm executing every external command This wouldn't work - it's not external commands that's the problem, it's arbitrary code that's being executed. That code has access to all regular system APIs/syscalls, so there's no way of explicitly confirming external commands. Python/pip suffers the same problem btw, so I think that ship has sailed.
    • codedokode 1y ago
      Then explicitly confirming running every hook with displaying module and function name. > Python/pip suffers the same problem btw, so I think that ship has sailed. If I ever find time to write a package manager for C, it won't support hooks.
    • Philpax 1y ago
      Rust is investigating using sandboxed WASM for proc macros, but it'll be some time before there's any movement there: https://github.com/rust-lang/compiler-team/issues/876 https://github.com/rust-lang/compiler-team/issues/876
• ianbutler 1y ago
  If you're a concerned user and you're looking for a solution founded by 2 people with a security background who have sandboxed execution (and network limited) so stuff like this can't happen you should check us out. We even offer a self hosted deployment which sidesteps this entirely. (feel free to reach out). www.bismuth.sh
• curuinor 1y ago
  CodeRabbit response - https://www.coderabbit.ai/blog/our-response-to-the-january-2025-kudelski-security-vulnerability-disclosure-action-and-continuous-improvement https://www.coderabbit.ai/blog/our-response-to-the-january-2...
  • deleted 1y ago
    [deleted]
  • jatins 1y ago
    > No customer data was accessed and the vulnerability was quickly remediated within hours of disclosure How do they know this -- Do they have any audit logs confirming this? A malicious actor could have been using this for months for all they know
    • oblio 1y ago
      > How do they know this They know because it would affect their fundraising, so obviously customer data wasn't affected.
  • marksomnian 1y ago
    If I were a CodeRabbit customer, I'd still be pretty concerned after reading that. How can CodeRabbit be certain that the GitHub App key was not exfiltrated and used to sign malicious tokens for customer repos (or even used for that in-situ)? I'm not sure if GitHub supports restricting the source IPs of API requests, but if it does, it'd be a trivial mitigation - and one that is absent from the blog post. The claim that "no malicious activity occurred" implies that they audited the activities of every repo that used Rubocop (or any other potential unsandboxed tool) from the point that support was added for it until the point that the vulnerability was fixed. That's a big claim. And why only publish this now, when the Kudelski article makes it to the top of HN, over six months after it was disclosed to them?
• willejs 1y ago
  This is a great read, but unfortunately does not surprise me really, it was bound to happen given how people blindly add apps with wide permissions and githubs permissions model. It amazes me how many people will install github apps that have wide scopes, primarily write permissions to their repositories. Even with branch protection, often people will allow privilaged access to their cloud in github actions from pull requests. To properly configure this, you need to change the github oidc audience and that is not well documented. When you enquire with the company who makes an app and ask them to provide a different app with less scope to disable some features which require write, they often have no interest what so ever and don't understand the security concerns and potential implications. I think github need to address this in part by allowing more granular app access defined by the installer, but also more granular permissions in general.
• kmarc 1y ago
  My nightmare is that one of those auto updating vim/vscode/your-favorite-IDE plug-ins That many of us happily use on all the monorepos we work on, at one point invoke a "linter" (or as in this case, configure a linter maliciously) and we start leaking the precious IP to random attackers :-( In fact, I use rubocop every day lately LOL
• socalgal2 1y ago
  I've ranted about this before and been downvoted, ignored as "not an issue" but, IMO, Github is majorly to blame for this. They under-invested in their permission system so 3rd party apps are effectively encouraged to ask for "root" permissions. Effectively, many (most?) 3rd party github integrations basically ask you to type in your github ID. Then they use the github API and ask for maximal permissions. This lets them make it easy for you to use their services because they can do all the rest of the setup for you. But, NO ONE SHOULD EVER GIVE THIS KIND OF PERMISSION. Any 3rd party service that said "give us root to your servers" would be laughed out of the market. But, that's what github has encouraged because their default workflow leaves it up to the developer to do the right thing. Instead, github's auth UX should (1) require you to choose repos (2) not allow picking "all repos" (3) require to you select each and every permission (4) not have an option for "all permissions". As an analogy (though poor). iOS and MacOS don't say "this app wants all these permissions, yes/no" (android used to do this). Instead, they ask one at a time (camera? mic? photos? network?) etc... I'm not suggesting that github ask one at a time. I am suggesting that github provide a default UI that lists all the permissions, per repo, and has no way to auto-populate it so the user is required to choose. Further, I would argue that github should show the integrations and permissions for any repo. The hope being if I see "lib X uses integration Y with write permission" then I know lib X is not trustworthy because it's open to supply chain attacks (more than lib Z which has no write integrations)
• _pdp_ 1y ago
  Amateur level of security - what more is there to say?
  • viraptor 1y ago
    The bigger the system, the more "amateur level of security" issues you'll find. It's not really a skill problem on its own.
• robomc 1y ago
  From the CEO's response: > On January 24, 2025, security researchers from Kudelski Security disclosed a vulnerability to us through our Vulnerability Disclosure Program (VDP). The researchers identified that Rubocop, one of our tools, was running outside our secure sandbox environment—a configuration that deviated from our standard security protocols. Honestly, that last part sounds like a lie. Why would one task run in a drastically different architectural situation, and it happen to be the one exploited?
  • deleted 1y ago
    [deleted]
  • jdlshore 1y ago
    Not sure why it seems like a lie. Oversights like this happen all the time.
    • wheelerwj 1y ago
      100%. Sounds like a very common oversight at many companies.
    • cube00 1y ago
      It seems like a lie because they tried to hide this incident by deflecting to a PR fluff post first [1] They only published a proper [2] disclosure post later once their hand was forced after the researcher's post hit the HN front page. [1]: https://news.ycombinator.com/item?id=44954242 https://news.ycombinator.com/item?id=44954242 [2]: I use that term loosely as it seems to be AI written slop.
  • sophacles 1y ago
    > Why would one task run in a drastically different architectural situation Someone made a mistake. These things happen. > and it happen to be the one exploited? Why would the vulnerable service be the service that is exploited? It seems to me that's a far more likely scenario than the non-vulnerable service being exploited... no?
    • 1y ago
• smsm42 1y ago
  When I read up to "One can use the Rubocop configuration file to specify the path to an extension Ruby file" my immediate thought was "oh no, they didn't allow a user-extendable tool to run in their prod environment..." - and yes, they did. Not that it'd be properly secure without this glaring hole - I don't think many linters are properly audited and fuzzed against hostile inputs - but this is like opening the front door and hanging a blinking neon sign "Please Hack Us!" over it.
  • frankfrank13 1y ago
    Even better when you read the CEO's response: > The researchers identified that Rubocop, one of our tools, was running outside our secure sandbox environment I don't think that was the main problem lol
• vedmakk 1y ago
  if op is reading the comments here: the screenshot where CodeRabbit has discovered the security vulnerability in the PR contains the actual ip address the env vars were sent to. No big deal, just you carefully used 1.2.3.4 in the rest of the article only to leak it in the screenshot. fyi.
• morgante 1y ago
  Yikes, this is a pretty bad vulnerability. It's good that they fixed it, but damning that it was ever a problem in the first place. Rule #1 of building any cloud platform analyzing user code is that you must run analyzers in isolated environments. Even beyond analysis tools frequently allowing direct code injection through plugins, linters/analyzers/compiler are complex software artifacts with large surface areas for bugs. You should ~never assume it's safe to run a tool against arbitrary repos in a shared environment. I also ran a code analysis platform, where we ran our own analyzer[1] against customer repos. Even though we developed the analyzer ourself, and didn't include any access to environment variables or network requests, I still architected it so executions ran in a sandbox. It's the only safe way to analyze code. [1] https://github.com/getgrit/gritql https://github.com/getgrit/gritql
  • KingOfCoders 1y ago
    Did I misread the article, or did they take the tool config from the PR not the repo?
    • morgante 1y ago
      The exploit is there either way.
      • KingOfCoders 1y ago
        The exploit depends on changing the config to execute a .rb file. And the config was supplied by a PR.
        • flexagoon 1y ago
          Yes, but the exploit grants you access to ALL repos, not just the one the PR is in. You could just as well change the config in your own private repo and run coderabbit in it.
    • yxhuvud 1y ago
      Unfortunately that mostly has to be the case or else the developer experience configuring these would be too bad.
• gregjw 1y ago
  yikes!
• dominodave01 1y ago
  this spiraled fast
• username223 1y ago
  That's some next-level incompetence: 1. Allow poorly-vetted third-party tools to run in CodeRabbit's privileged environment. The exploit used a Ruby code analysis tool that was probably written 15 years ago and meant to be run locally by trusted developers, who already had access to /bin/sh. 2. Ask for coarse-grained permission to access and modify others' code without any checks. Either of those by itself would be bad enough. The future looks bright for black or white hats who understand computers.
• KingOfCoders 1y ago
  They let the static tool get its config from the PR? Is this madness? Or did I read the article wrong?
  • megamorf 1y ago
    The security researcher noticed that CodeRabbit runs linters against your code base and noticed that Rubocop was among the provided linters. Rubocop supports extensions that contain custom code, so he crafted an extension that exfiltrated the environment variables of the running Rubocop process when it linted the contents of his PR.
    • KingOfCoders 1y ago
      But where does the configuration for Rubocop come from? From CodeRabbit (e.g. you configure it on their server for your repo), from the repository or (new) config files in the PR?
      • rglynn 1y ago
        Both the repo and new config in the PR.
• pabs3 1y ago
  Developer tools really need to be more mindful of the fact that on developer machines, the current directory should not be trusted, and arbitrary code should not be executed from it. The git project has been learning this the hard way, and others should too. For check-all-the-things (meta-linter), we disable the rubocop default config file using the "--config /dev/null" options.
• SCdF 1y ago
  https://www.coderabbit.ai/blog/our-response-to-the-january-2025-kudelski-security-vulnerability-disclosure-action-and-continuous-improvement https://www.coderabbit.ai/blog/our-response-to-the-january-2... > No customer data was accessed As far as I can tell this is a lie. The real answer is that they have absolutely no clue if customer data was accessed, and no way to tell. I'm not even sure Github could tell, but it's not clear if the exploits way of generating private keys to access private repositories is any different to what CodeRabbit does in normal operation.
• KronisLV 1y ago
  > Instead, it would be best to assume that the user may be able to run untrusted code through these tools. So, running them in an isolated environment, with only the minimum information required to run the tools themselves, and not passing them any environment variables would be much better. Even if arbitrary code execution would be possible, the impact would be much less severe. > For defense in depth, one should add a mechanism that prevents sending private information to an attacker-controlled server. For example, only allow outgoing traffic to whitelisted hosts, if possible. If the tool doesn’t require internet access, then all network traffic may even be disabled in that isolated environment. This way it would make it harder for an attacker to exfiltrate secrets. I yearn to live in a world where this is the default or at least REALLY EASY to do, where you just fall into the pit of success. And yet, we live in a borderline insane world where one key getting leaked can pwn a million repos - if nothing else, there should be one key per interaction with account/repo. Not to mention that Rubocop (and probably other tools, eventually) have arbitrary code execution as a feature. I don't think that CodeRabbit messed up, as much as everything around them is already messed up.
• mariocandela 1y ago
  I'm sorry about Coderabbit's reputation, it's really a great project!
• t0duf0du 1y ago
  Even with proper sandboxing, storing all sensitive credentials as environment variables is still a security anti-pattern. ENV vars are too easily accessible - any process can just run ENV.to_h and dump everything.
• eoncode 1y ago
  for the author of the page, check the screenshot under "context is key", i think you missed censoring a public ip.
• ewok94301 1y ago
  While GitHub needs to invest in finer grained permissioning, I do think there’s lots of lessons for companies building with and customers using GitHub App based deployments. Jotted down my thoughts here https://www.endorlabs.com/learn/when-coderabbit-became-pwnedrabbit-a-cautionary-tale-for-every-github-app-vendor-and-their-customers https://www.endorlabs.com/learn/when-coderabbit-became-pwned...
• elpakal 1y ago
  So if their GH API token with access to million plus repos was this easy to compromise, isn't it plausible that their token could have been used to clone clone said repos? Is it possible to audit the clone history of a token?
• megamindbrian2 1y ago
  [dead]