Live data from Hacker News

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

research.kudelskisecurity.com

181–190 of 244 posts

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

#181

Earlier quoted context omitted.

The chuzpe to use this as PR.

Off topic, but: chutzpah is the conventional English spelling :-) Edit: I'm this old when I learned that Germans spell it "chuzpe."

I'm this old to learn that the Yiddish spelling is chutzpe with a `T` (thought it would be Chuzpe).

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

#182

Earlier quoted context omitted.

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.

I’m sure an “intern” did it.

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.

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

#183
post #167

Earlier quoted context omitted.

Hmm, is it normal practice to rotate secrets before fixing the vulnerability?

They first disabled rubocop to prevent further exploit, then rotated keys. If they awaited deploying the fix that would mean letting compromised keys remain valid for 9 more hours. According to their response all other tools were already sandboxed. However their response doesn't remediate putting secrets into environment variables in the first place - that is apparently acceptable to them and sets off a red flag for…

> putting secrets into environment variables in the first place - that is apparently acceptable to them and sets off a red flag for me

Isn't that standard? The other options I've seen are .env files (amazing dev experience but not as secure), and AWS Secrets Manager and similar competition like Infisical. Even in the latter, you need keys to authenticate with the secrets manager and I believe it's recommended to store those as env vars.

Edit: Formatting

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

#184

Earlier quoted context omitted.

They first disabled rubocop to prevent further exploit, then rotated keys. If they awaited deploying the fix that would mean letting compromised keys remain valid for 9 more hours. According to their response all other tools were already sandboxed. However their response doesn't remediate putting secrets into environment variables in the first place - that is apparently acceptable to them and sets off a red flag for…

> putting secrets into environment variables in the first place - that is apparently acceptable to them and sets off a red flag for me Isn't that standard? The other options I've seen are .env files (amazing dev experience but not as secure), and AWS Secrets Manager and similar competition like Infisical. Even in the latter, you need keys to authenticate with the secrets manager and I believe it's recommended to stor…

You can use native authentication methods with Infisical that don't require you to use keys to authenticate with your secrets manager: - https://infisical.com/docs/documentation/platform/identities... - https://infisical.com/docs/documentation/platform/identities...

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

#185
post #167

Earlier quoted context omitted.

Hmm, is it normal practice to rotate secrets before fixing the vulnerability?

They first disabled rubocop to prevent further exploit, then rotated keys. If they awaited deploying the fix that would mean letting compromised keys remain valid for 9 more hours. According to their response all other tools were already sandboxed. However their response doesn't remediate putting secrets into environment variables in the first place - that is apparently acceptable to them and sets off a red flag for…

"According to their response all other tools were already sandboxed."

Everything else was fine, just this one tool chosen by the security researcher out of a dozen of tools was not sandboxed.

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

#186
post #130

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…

Yes, all the tools are fine and secure and sandoxed, just this one tool that was kind of randomly chosen by the security researcher because it is a tool that can execute Ruby code inside the environment - one could argue an especially dangerous tool to run - was not safe.

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

#187
post #130

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…

because researchers from Kudelski Security most likely tried different static analysis tools and they didn't work the way Rubocop did. They don't write the details of how they got to this particular tool - you could also see from the article they tried a different approach first.

I've read it differently, they chose Rubocop not because it worked, but because it allows to execute Ruby code.

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

#189

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…

Did I misread the article, or did they take the tool config from the PR not the repo?

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

#190

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.

https://www.coderabbit.ai/blog/our-response-to-the-january-2...

That post happened after the HN post?
Post reply on HN