DLL sideloading in Claude Cowork for Windows, closed as not an issue because it requires host compromise.
It’s true that DLL sideloading is not strictly Claude’s problem, but at the very least defenders should know this is a potential attack path.
A malicious DLL can gain full root permissions on the Claude Cowork sandbox VM used for local compute tasks by the harness.
Attack chain from the article here:
https://www.armadin.com/blog-posts/exploiting-root-execution-in-claude-coworks-sandbox
I am not surprised by the whole It is Local Code Execution so we don’t have to worry argument. Hasn’t Microsoft and others used that before?
Along those lines I know that I have rallied against high CVSS scores for Local Code Execution since it implies the machine has worse things to think about, even with what the LCE can accomplish. What I am curious about with it is how it affects AI and can it be used to create hallucinations or false information in the AI itself, perhaps even training model issues. I didn’t really see anything on that in there.
In the end it is another case of a company saying, we don’t have the resources to deal with this so we won’t.
For those who are interested, here’s a database of known DLL sideloading/hijacking targets.
As far as severity, with the amount of applications that are now installed under the local user (%LOCALAPPDATA%) context, I do think this remains an issue. Same goes for ASAR integrity in Electron apps. It’s not a big lift; it’s just hygiene.
If you go to the trouble of signing your binary, you can sign your DLL. But yes, any time a company can avoid claiming responsibility for a CVE, they will.
