141–150 of 244 posts
Earlier quoted context omitted.
https://www.coderabbit.ai/blog/our-response-to-the-january-2...
The LLM tics are strong in this writeup: "No manual overrides, no exceptions." "Our VDP isn't just a bug bounty—it's a security partnership"
Another:
> Security isn't just a checkbox for us; it's fundamental to our mission.
Earlier quoted context omitted.
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…
There's also no reason why they needed to have write access to post code review comments. But for some reason they ask for it and you can't deny that part when hooking up their thing.
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.
When the security researchers praise the response, it's a good sign tbh.
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 h…
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...
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…
> 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
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…
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?
Earlier quoted context omitted.
The LLM tics are strong in this writeup: "No manual overrides, no exceptions." "Our VDP isn't just a bug bounty—it's a security partnership"
Wow, you hit a nerve with that one. There have been some quick edits on the page. Another: > Security isn't just a checkbox for us; it's fundamental to our mission.
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…
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.