Claude Office Party Enables Linux Code Execution

A fixed temporary-file path in Claude’s official document-processing skills can cause LibreOffice to load and execute an attacker-supplied shared library on Linux. The code runs with the privileges of the user operating the AI agent.

AIR Security found the flaw, named Office Party, in Anthropic’s DOCX, PPTX, and XLSX skills. These skills let Claude create, read, edit, and process Word documents, PowerPoint presentations, and Excel spreadsheets. Anthropic acknowledged the issue after AIR reported it in May but considers it outside its security boundary because the affected code runs inside a sandbox. The helper script remains unchanged, according to the researchers.

A predictable library becomes executable input

The vulnerable component is soffice.py, a helper script that starts LibreOffice for document conversion, including rendering Word documents as PDFs. In environments where LibreOffice cannot open Unix-domain sockets, the script falls back to a workaround based on Linux’s LD_PRELOAD mechanism.

LD_PRELOAD instructs the dynamic linker to load a specified shared library before other libraries required by a process. It is useful for interposition and compatibility work, but any library selected through it becomes executable code inside the new process.

Claude’s helper checks a shared temporary directory for a library named lo_socket_shim.so. If the file exists, the script uses it without verifying its origin or contents. An attacker who places a malicious library at that path can wait for the next document-processing operation. When Claude starts LibreOffice, the attacker’s library is loaded automatically.

The trigger can therefore be an ordinary request to generate or convert a document. The user does not have to execute the planted file directly. The trusted document skill supplies the execution path.

Skill composition creates the attack chain

AIR demonstrated the behavior in two ways. In the first, the researchers manually placed a malicious library in the temporary directory and then asked Claude Code to generate a document. In the second, a separate, apparently legitimate AI skill unpacked a supporting file into that directory. The document skill later found the file and loaded it.

The second case matters for assessing agent deployments. A malicious or compromised skill does not need to invoke the vulnerable helper or exploit LibreOffice directly. It only needs permission to write the expected filename into a directory shared with the official skill. A later operation completes the chain.

This is a dependency and composition problem. Reviewing each skill separately can miss the interaction between a component that writes files and another that treats an existing file as trusted executable code. Shared writable directories make that interaction easier to arrange.

The issue affects Linux environments where Unix sockets are blocked, including some container security configurations and Claude Code’s sandbox. AIR reports that macOS is unaffected because the workaround does not load the library through LD_PRELOAD there.

What defenders should check

Start by identifying Linux Claude deployments that use the official DOCX, PPTX, or XLSX skills. Determine whether their execution environments block Unix-domain sockets, since that condition selects the vulnerable fallback. Inspect how the shared temporary directory is mounted, which processes and skills can write to it, and whether it persists across otherwise separate tasks.

Monitoring should cover creation or replacement of lo_socket_shim.so in the relevant temporary location, followed by LibreOffice execution with LD_PRELOAD set. A file appearing before document conversion is more useful telemetry than document content alone. Defenders should also examine whether untrusted skills can extract arbitrary supporting files into shared temporary storage.

AIR recommends maintaining a live inventory of AI skills and add-ons installed across employee agents. Official skills belong in that inventory alongside third-party components. Their scripts, update state, filesystem access, and interactions with other skills should be reviewed as software dependencies.

Sandboxing still limits the environment available to the malicious library, but AIR disputes Anthropic’s treatment of that boundary as sufficient. The researchers point out that code inside the sandbox runs with the user’s permissions where the user’s files and work are already available. Defensive prioritization should therefore depend on what the sandbox can access, not merely on whether one exists.

---

Contains a referral link.