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

▲

smarx007 5 days ago | parent | next [-]

How was the sandbox implemented? Just a one-off Docker container execution or something more substantial?

	▲	morgante 5 days ago \| parent [-]
		We built on firecracker VMMs but today I'd just use a hosted provider like morph.so or e2b.dev.

▲

KingOfCoders 5 days ago | parent | prev [-]

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

▲

yxhuvud 5 days ago | parent | next [-]

Unfortunately that mostly has to be the case or else the developer experience configuring these would be too bad.

▲

morgante 5 days ago | parent | prev [-]

The exploit is there either way.

▲

KingOfCoders 5 days ago | parent [-]

The exploit depends on changing the config to execute a .rb file. And the config was supplied by a PR.

	▲	flexagoon 5 days ago \| parent [-]
		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.