Office Party: Anthropic Office Skills Run Planted Code on Linux via LD_PRELOAD

On Linux, Anthropic's official document skills can load attacker-controlled code through a predictable path in the system temp directory. AIR Security disclosed the issue on November 5, 2026, under the name Office Party: when LibreOffice conversion runs, helper soffice.py may set LD_PRELOAD to lo_socket_shim.so in the shared temp folder without checking who placed it there. If you run Claude Code or other agents with document-skills on Linux, treat default skills as dependencies to inventory and review, not as implicitly safe extensions.

Dark Reading and other outlets summarized the disclosure on November 9; the mechanism below comes from AIR's write-up and from the current soffice.py source in anthropics/skills.

TL;DR

What AIR reported

AIR's Office Party post argues that Anthropic's docx, pptx, and xlsx skills are unusually trusted: they power document features on claude.ai, ship in the public anthropics/skills repository, and install as document-skills from Anthropic's marketplace. That trust makes implementation details easy to overlook.

The vulnerable helper is scripts/office/soffice.py, shared across the office skills. The docx skill instructs agents to run conversions such as:

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

LibreOffice uses AF_UNIX sockets internally. Some sandboxes block them. The helper probes socket creation; on failure it ensures a shim shared object exists and exports it through LD_PRELOAD so LibreOffice can start.

AIR highlights three design choices in the shipped code:

1. Fixed path — _SHIM_SO = Path(tempfile.gettempdir()) / "lo_socket_shim.so".
2. No provenance check — if the file already exists, _ensure_shim() returns it immediately.
3. Broad trigger — any failure to open a Unix socket (not only an intentional sandbox policy) enables the shim path.

The team reported the issue to Anthropic in May 2026. AIR states Anthropic acknowledged it but considers it outside its security boundary because the helper runs in a sandbox. As of November 5, 2026, AIR says the script on main still follows the same logic.

Mechanism in the shipped source

The public soffice.py on GitHub matches AIR's description. When _needs_shim() returns true, get_soffice_env() copies the environment, sets SAL_USE_VCLPLUGIN to svp, and assigns:

env["LD_PRELOAD"] = str(shim)

where shim is either an attacker-supplied lo_socket_shim.so or a freshly compiled legitimate shim. The preload library's constructor runs inside soffice before conversion work begins.

On Linux, LD_PRELOAD is a standard way to inject shared objects into a process. Security models that allow an agent to spawn soffice but assume "sandboxed" execution still inherit the user's file access, SSH keys, cloud tokens in environment files, and repository contents the agent can read.

AIR notes the shim path is not a rare branch: docx workflows ask Claude to render documents to PDF through this helper for visual checking, and pptx/xlsx reuse the same file.

Attack chain, step by step

This is the chain AIR documents and reproduces:

1. Plant a shared object at {tempdir}/lo_socket_shim.so with a constructor that runs attacker code (or use another skill to unpack it there).
2. Victim asks Claude for a Word deck, spreadsheet export, or PDF check; the agent invokes the official office skill.
3. Probe — soffice.py cannot create an AF_UNIX socket (common in Claude Code's Linux sandbox and some container profiles).
4. Preload — _ensure_shim() sees an existing file and returns it; run_soffice() launches LibreOffice with LD_PRELOAD pointing at the planted object.
5. Execute — attacker code runs inside the LibreOffice process as the user running the agent, before conversion finishes.

AIR demonstrated two routes: direct planting before a document request, and a two-skill chain where a mundane marketing skill unpacks supporting files into /tmp, one of which is the malicious library. Neither skill need look overtly malicious in isolation.

Image: AIR Security

Timeline

What this means if you run AI coding agents

Inventory official skills, not only marketplace downloads. Office Party lives in Anthropic-branded document skills. If your security model only reviews third-party MCPs, you will miss it.

Map who shares /tmp. CI runners, devcontainers, and multi-user Linux hosts with permissive temp directories enlarge the planting surface. Prefer per-job temp roots (TMPDIR in systemd units or container entrypoints) where you control lifecycle.

Watch skill combinations. AIR's second scenario is a reminder that benign skills can stage files for a trusted skill to execute. That is the same composition risk we cover around malicious skills and MCP configs and Plugin4Shell-style trust in pinned plugins.

Do not equate sandbox with harmless. Even if LibreOffice stays inside a sandbox, attacker code still runs with access to whatever that sandbox includes — often the checked-out repo, cached credentials in env files, and agent-visible secrets.

Practical checks today:

ls -la "$(python3 -c 'import tempfile; print(tempfile.gettempdir())')/lo_socket_shim.so" 2>/dev/null
grep -R "lo_socket_shim" ~/.claude ~/.config/claude 2>/dev/null

Remove unexpected objects, pin skill versions you approve, and block document conversion on shared runners until you have a patched soffice.py or isolated temp directories.

macOS and Windows: AIR positions Linux LD_PRELOAD as the exploitable path. Windows xlsx issues around missing AF_UNIX are a separate failure mode (see Claude Code issue #78841); do not assume cross-platform parity.

Why predictable temp paths keep showing up in agent tooling

Office Party is not the first time a helper script has treated /tmp as a cooperative workspace. Security reviewers have flagged the same fixed-name shared object under a world-writable temp directory pattern in other document-automation code because any local writer can win a race. The AIR write-up frames Office Party as a composition problem: document skills are high trust, high reach, and they call native tooling (soffice, gcc, LD_PRELOAD) that traditional AppSec teams rarely model when they approve "just another Claude plugin."

For coding-agent deployments, three assumptions fail at once:

1. "Official" implies reviewed like product code. Marketplace badges describe authorship, not memory-safe subprocess design.
2. "Sandbox" implies no meaningful host risk. A sandbox that still runs LibreOffice as the developer user can read project trees and cloud CLI credentials the user already loaded.
3. "Skills are isolated." Skills share OS resources — especially temp directories — and one skill's file drop becomes another skill's dependency.

That is why AIR's second demonstration matters: the planting skill never mentions documents. It only unpacks assets. The document skill remains within its stated purpose while loading attacker code.

Enterprise mitigations beyond waiting for a patch

Until soffice.py verifies shim provenance (for example by compiling only into a mkdtemp directory with mode 0700, or checking a signature), operators can reduce exposure:

None of these replace a vendor fix, but they align with how teams already treat build agents: isolate temp storage, log subprocess environments, and treat bundled scripts as application code in change management.

Anthropic's reported position — that the behavior is outside the security boundary because it runs in a sandbox — is a policy choice readers should understand explicitly. AIR argues the boundary still contains user data and tokens agents can reach. Your risk acceptance may differ, but the code path is knowable today from public sources.

If you need a quick inventory of whether document skills are present on a laptop, search skill install trees for soffice.py and read whether _SHIM_SO still points at the global temp directory. Forks that vendor-patch the file should document the change in your internal skill registry so agents do not silently re-pull upstream.

How Beam handles this

AIR sells enterprise guardrails for agent context and skill posture. Beam is narrower and local: it watches Claude Code and Codex on your machine, runs heuristic scans on skills and MCP configs before you enable them, and can deny risky PreToolUse patterns when workspace policy is in enforce mode (how Beam watches).

For Office Party-shaped risk, that means heuristic scans on skill files may flag references to LD_PRELOAD, fixed paths under the system temp directory, or subprocess calls to soffice, and PreToolUse capture can surface file writes or shell commands the agent proposes before document conversion runs. Beam does not replace Anthropic's skill code, does not sandbox LibreOffice at the kernel, and its scan is heuristic, not proof that a skill is safe. Missing cached policy is fail-open. Compare deeper static tooling in NVIDIA SkillSpector if you want a second opinion before install.

Frequently asked questions

What is the Office Party vulnerability?

Office Party is AIR Security's name for unsafe behavior in Anthropic's official docx, pptx, and xlsx skills. On Linux, when Unix sockets cannot be opened, helper script soffice.py sets LD_PRELOAD to a file at tempfile.gettempdir()/lo_socket_shim.so without verifying who wrote it.

Which Claude users are affected?

Linux hosts where something blocks AF_UNIX sockets, including some container seccomp setups and Claude Code's sandbox, and where Anthropic document skills run LibreOffice through soffice.py. macOS does not use LD_PRELOAD the same way for this path.

Has Anthropic patched Office Party?

As of November 5, 2026, AIR reports that soffice.py on main in anthropics/skills still uses the same fixed path and loads whatever file exists there. Anthropic acknowledged the report in May 2026 but treats it as outside its security boundary because the helper runs in a sandbox.

How can an attacker plant the library?

Any code running as the same user that can write to the temp directory can drop lo_socket_shim.so first: another skill, a compromised package install script, a reused CI container, or a co-tenant on shared /tmp. A separate benign-looking skill can unpack the file as supporting assets.

Does Claude Code updating fix this?

Not by itself if the skill bundle still ships the same helper. Track anthropics/skills or document-skills versions, review soffice.py, and add local controls such as skill inventory, temp directory isolation, and PreToolUse denies on risky writes.

Can a scanner catch Office Party?

A static skill scan can flag LD_PRELOAD, fixed paths under the temp directory, and subprocess calls to soffice, but it cannot prove a race with another process. Runtime monitoring that records file writes under /tmp before document tasks helps triage.

Related reading

• Claude Code plugin hash pin bypass (CVE-2026-86063)
• MCP and skill supply-chain review checklist
• NVIDIA SkillSpector: what an agent skill scanner checks
• How to vibe-code more safely with Beam
• AI agent security for coding assistants

Primary sources: AIR Security — Office Party, anthropics/skills soffice.py. Secondary context: Dark Reading — attackers exploit Office Party on Linux.

Severity ratings, sandbox boundaries, and repository paths are accurate as of 2026-11-09.