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."
How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
181–190 of 244 posts
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#182Earlier 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.
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#183Earlier 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…
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
#184Earlier 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…
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#185Earlier 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…
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
#186From 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…
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#187From 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.
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#188Or did I read the article wrong?
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#189Yikes, 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…
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#190I 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...