How to gain code execution on hundreds of millions of people and popular apps
31 comments
·February 28, 2025davej
Dave here, founder of ToDesktop. I've shared a write-up: https://www.todesktop.com/blog/posts/security-incident-at-to...
This vulnerability was genuinely embarrassing, and I'm sorry we let it happen. After thorough internal and third-party audits, we've fundamentally restructured our security practices to ensure this scenario can't recur. Full details are covered in the linked write-up. Special thanks to Eva for responsibly reporting this.
spudlyo
> cannot happen again.
Hubris. Does not inspire confidence.
> We resolved the vulnerability within 26 hours of its initial report, and additional security audits were completed by February 2025.
After reading the vulnerability report, I am impressed at how quickly you guys jumped on the fix, so kudos. Did the security audit lead to any significant remediation work? If you weren't following PoLP, I wonder what else may have been overlooked?
davej
Fair point. Perhaps better phrased as "to ensure this scenario can't recur.". I'll edit my post.
Yes, we re-architected our build container as part of remediation efforts, it was quite significant.
abhiaagarwal
Based on the claims on the blog, it feels reasonable to say that this "cannot" occur again.
hakaneskici
How can -let's say- Cursor users be sure they were not compromised?
> No malicious usage was detected
Curious to hear about methods used if OK to share, something like STRIDE maybe?
edm0nd
how much of a bounty was paid to Eva for this finding?
richardboegli
> they were nice enough to compensate me for my efforts and were very nice in general.
They were compensated, but doesn't elaborate.
jsheard
Sounds like it was handled better than the authors last article where the Arc browser company initially didn't offer any bounty for a similar RCE, then awarded a paltry $2k after getting roasted, and only bumped it up to $20k after getting roasted even more.
mcoliver
"i wanted to get on the machine where the application gets built and the easiest way to do this would be a postinstall script in package.json, so i did that with a simple reverse shell payload"
Just want to make sure I understand this. They made a hello world app and submitted it to todesktop with a post install script that opened a reverse shell on the todesktop build machine? Maybe I missed it but that shouldn't be possible. Build machine shouldn't have outbound open internet access right?? Didn't see that explained clearly but maybe I'm missing something or misunderstanding.
TheDong
In what world do you have a machine which downloads source code to build it, but doesn't have outbound internet access so it can't download source code or build dependencies?
Like, effectively the "build machine" here is a locked down docker container that runs "git clone && npm build", right? How do you do either of those activities without outbound network access?
And outbound network access is enough on its own to create a reverse shell, even without any open inbound ports.
trallnag
Isn't it really common for build machines to have outbound internet access? Millions of developers use GitHub Actions for building artifacts and the public runners definitely have outbound internet access
vekatimest
The cat is cute but I'd rather not have it running in front of the text while I'm trying to read and use my cursor.
asciii
> i wanted to get on the machine where the application gets built and the easiest way to do this would be a postinstall script in package.json, so i did that with a simple reverse shell payload
From ToDesktop incident report,
> This leak occurred because the build container had broader permissions than necessary, allowing a postinstall script in an application's package.json to retrieve Firebase credentials. We have since changed our architecture so that this can not happen again, see the "Infrastructure and tooling" and "Access control and authentication" sections above for more information about our fixes.
I'm curious to know what the trial/error here was to get their machine to spit out the build or if it was in one-shot
giantg2
With rhe number of dependencies and dependency trees going multiple levels deep? Third party risk is the largely unaddressed elephant in the room that companies don't care about.
GuestFAUniverse
" please do not harass these companies or make it seem like it's their fault, it's not. it's todesktop's fault if anything) "
I don't get it. Why would it be "todesktop's fault", when all the mentioned companies allowed to push updates?
I had these kind of discussions with naive developers giving _full access_ to GitHub orgs to various 3rd party apps -- that's never right!
rvz
My goodness. So much third-party risk upon risk and lots of external services opening up this massive attack surface and introducing this RCE vulnerability.
From an Electron bundler service, to sourcemap extraction and now an exposed package.json with the container keys to deploy any app update to anyone's machine.
This isn't the only one, the other day Claude CLI got a full source code leak via the same method from its sourcemaps being exposed.
But once again, I now know why the entire Javascript / TypeScript ecosystem is beyond saving given you can pull the source code out of the sourcemap and the full credentials out of a deployed package.json.
XorNot
> But once again, I now know why the entire Javascript / TypeScript ecosystem is beyond saving given you can pull the source code out of the sourcemap and the full credentials out of a deployed package.json.
You've always been able to do the first thing though: the only thing you can do is obfuscate the source map, but it's not like that's a substantial slowdown when you're hunting for authentication points (identify API URLs, work backwards).
And things like credentials in package.json is just a sickness which is global to computing right now: we have so many ways you can deploy credentials, basically 0 common APIs which aren't globals (files or API keys) and even fewer security tools which acknowledge the real danger (protecting me from my computers system files is far less valuable then protecting me from code pretending to be me as my own user - where all the real valuable data already is).
Basically I'm not convinced our security model has ever truly evolved beyond the 1970s where the danger was "you damage the expensive computer" rather then "the data on the computer is worth orders of magnitude more then the computer".
oguz-ismail
Why is this article in all lowercase?
spudlyo
Why does it use Neko the cursor chasing cat? Why the goth color scheme? These are stylistic choices, there is no explaining them.
nkrisc
Thankfully there is reader mode. That dumb cat is so obnoxious on mobile.
nickthegreek
woah, the cat chases your taps on mobile!
nickthegreek
it’s a blog. people regularly use their personal sites to write in a tone and format that they are fond of. i only normally feel like i see this style from people who were on the internet in the 90s. i’d imagine we would see it even more if phones and auto correct didn’t enforce a specific style. imagine being a slave to the shift key. it can’t even fight back! i’m more upset the urls aren’t actually clickable links.
QuadmasterXLII
Finding an RCE for every computer running cursor is cool, and typing in all lowercase isn’t that cool. Finding an RCE on millions of computers has much much higher thermal mass than typing quirks, so the blog post makes typing in all lowercase cool.
AndrewStephens
why do the stars shine? why does rain fall from the sky? using upper case is just a social convention - throw off your chains.
null
ge96
the cat chase cursor thing is great
jpbastyr
just the style of their blog
edm0nd
its cool. not everything has to be typed in a "normal" way.
As an Electron maintainer, I'll re-iterate a warning I've told many people before: Your auto-updater and the underlying code-signing and notarization mechanisms are sacred. The recovery mechanisms for the entire system are extremely painful and often require embarrassing emails to customers. A compromised code-sign certificate is close to the top of my personal nightmares.
Dave and toDesktop have build a product that serves many people really well, but I'd encourage everyone building desktop software (no matter how, with or without toDesktop!) to really understand everything involved in compiling, signing, and releasing your builds. In my projects, I often make an argument against too much abstraction and long dependency chain in those processes.
If you're an Electron developer (like the apps mentioned), I recommend: - Build with Electron Forge, which is maintained by Electron and uses @electron/windows-sign and @electron/osx-sign directly. No magic. - For Windows signing, use Azure Trusted Signing, which signs just-in-time. That's relatively new and offers some additional recovery mechanisms in the worst case.
Lastly, you should probably be the only one with the keys to your update server.