Office Party: A Code-Execution Vulnerability in Anthropic's Official Office Skills Runs a Planted Binary

Built-In Is Not Bulletproof

Most skills are something you go looking for. Anthropic's docx, pptx and xlsx skills are already there.

They are the skills behind Claude's own document features: when you ask Claude on claude.ai for a Word document, a slide deck or a spreadsheet, these skills are active with no setup, and Claude picks them on its own whenever a request calls for one. Anthropic also publishes them in its official anthropics/skills repository, describing them as "actively used in a production AI application", and Claude Code users install them from Anthropic's skills marketplace (anthropics/skills) as document-skills.

Few skills carry more trust.

In OpenAI Sesame, we showed that an official skill can be vulnerable on its own. This time the vulnerable skill is Anthropic's, and the vulnerability is a classic one: a trusted program that runs whatever file it finds in a shared folder.

We call it Office Party: the file is an uninvited guest that crashes Anthropic's Office skills.

The Shim That Trusts Anyone

To convert documents, for example to render a .docx as a PDF, the skills run LibreOffice through a helper script, scripts/office/soffice.py. The docx skill's instructions tell the agent to call it directly:

python scripts/office/soffice.py --headless --convert-to pdf output.docx

LibreOffice uses Unix-domain sockets internally, and some sandboxes block them. The helper works around this: it checks whether it can open a Unix socket, and if it can't, it loads a small "shim" library into LibreOffice through LD_PRELOAD to get around the restriction. Here is the relevant logic:

_SHIM_SO = Path(tempfile.gettempdir()) / "lo_socket_shim.so"

def _ensure_shim() -> Path:
    if _SHIM_SO.exists():
        return _SHIM_SO
    ...

Three design choices combine to create the vulnerability:

• A fixed path. The shim always lives at lo_socket_shim.so in the shared temp directory.
• No checks. If a file is already there, it gets used, with no check of who wrote it or what it contains. Whoever writes it first wins.
• Any error flips it on. Not only a sandbox that blocks sockets: any failure to open one, even running out of file descriptors, turns the shim on.

LD_PRELOAD loads a library into a program before it starts, and the library's code runs automatically. So whoever plants lo_socket_shim.so runs their code inside LibreOffice, as the user.

And this isn't a rarely used corner of the skill. The docx skill tells Claude to render every document it writes to PDF through this helper, to check how it looks. The same helper ships unchanged in the pptx and xlsx skills, which run through it too.

The code never asks where that file came from. Anything running with your privileges that can write to the temp directory the skill uses can supply it: a skill, a package's install script, an earlier step in a reused container or CI job, or another user where /tmp is shared. The attacker needs exactly one thing — a file named lo_socket_shim.so sitting there before Claude's next document task.

How the Attack Runs

End to end, the attack is four steps.

1. A file named lo_socket_shim.so lands in the temp directory.
2. The user asks Claude for a document, and Anthropic's skill runs.
3. Unix sockets are blocked — in Claude Code's case by its own sandbox — so the skill preloads the file it finds.
4. The attacker's code runs inside LibreOffice, before a single page is converted.

How We Tested It

We reproduced it two ways.

The direct one: we installed Anthropic's official document-skills plugin, placed a library at that path in Claude Code's sandbox temp directory, and asked Claude for a document. The library was loaded and run.

The second needed no planting of our own. We let another skill do it — an ordinary-looking skill that writes marketing copy and, along the way, unpacks some supporting files into /tmp. One of them was the library. Neither skill does anything a reviewer would flag, and together they run the attacker's code without either one stepping out of line.

Both routes end the same way: code we never asked Claude to run, executing inside Anthropic's official skill.

Anthropic's Response

After finding this vulnerability in May 2026, we reported the issue to Anthropic. Anthropic acknowledged it, but considers it outside its security boundary, since the vulnerable code only runs inside a sandbox.

As of November 5, 2026, soffice.py on main in anthropics/skills still uses the same fixed path, and still loads whatever file it finds there.

Takeaways for Security Teams

1. Official skills are not automatically secure. A big vendor's name on a skill doesn't make it secure. Official skills can still contain unsafe assumptions that attackers can exploit, and they deserve the same scrutiny as any other code your agents run.
2. Know what is installed across your agents. Security teams need to see every skill installed across their agents and how those skills combine, not just whether each one looks clean on paper.‍
3. Skills can contain vulnerabilities and must be updated continuously. Just like code packages, skills may contain vulnerabilities that attackers can exploit. Security teams should continuously validate both the skill itself and every external dependency it relies on both for safety and for vulnerabilities.

Book a demo with Air Security to see how we help organizations secure AI skills and the broader AI supply chain. Air continuously identifies and reduces the risks introduced across the AI ecosystem.