How to use the offensive-toctou agent skill for TOCTOU testing

What the offensive-toctou skill makes the agent do

The skill is a SKILL.md file that covers TOCTOU race conditions across several layers: binaries, the kernel, filesystems, web APIs and containers. It describes how to identify a check-then-act pattern in code, how to build a swap that replaces the underlying object between the check and the use, and how to stretch that gap so the swap lands reliably.

The source covers filesystem cases such as symbolic-link races, file-descriptor races and /proc races, kernel double-fetch issues, container and Kubernetes escape primitives, web and JWT authorisation splits, and payment or idempotency races. It also covers amplification techniques such as FUSE-backed slow filesystems, cgroup freezing and single-packet HTTP/2 requests. The skill also explains the defensive fixes, such as operating on file descriptors and using O_NOFOLLOW.

How to install the offensive-toctou skill

Agent skills are folders of instructions that an agent loads when a task matches them. To install this one, download the ZIP from the item page on this site and unzip it into your personal skills folder, ~/.claude/skills/, or into a project's .claude/skills/ folder if you want the skill available only in that project.

You can also upload the ZIP in the Claude apps under Settings, then Capabilities, then Skills. Use whichever method suits your setup. The skill ships as a single file, SKILL.md.

• Download the ZIP from the offensive-toctou page on this site.
• Unzip it into ~/.claude/skills/ for all projects, or into .claude/skills/ inside one project.
• Alternatively, open the Claude apps, go to Settings, then Capabilities, then Skills, and upload the ZIP.
• Start a new session so the agent can see the newly added skill.

What you need before you start

The skill's examples assume a Linux system with a C compiler, strace and standard shell tools. The FUSE example needs Python with the fusepy package. Some mount and cgroup techniques need root privileges or user-namespace privileges.

Use a lab or an authorised test environment. The techniques are intrusive and can cause privilege escalation or data exposure if pointed at systems you do not own or have written permission to test.

• Linux with a C compiler, strace and standard shell tools
• Python with fusepy for the FUSE example
• Root or user-namespace privileges for some mount and cgroup techniques
• A lab or authorised test environment

How to trigger the skill with natural requests

You do not need a special command. Describe the task in plain language and mention race conditions, TOCTOU or the kind of code you are reviewing. The skill's description says it applies when you have found a check-then-act pattern in code, when you are fuzzing for race conditions, or when you are exploiting concurrency bugs in privileged binaries, kernels or orchestrators.

Include the context the agent needs: the language or binary, the privileged action, and the authorisation under which you are working. Vague requests are less useful than specific ones.

• I have a setuid binary that calls access() and then open() on a user-supplied path. Review it for a TOCTOU race in our authorised lab.
• Here is a privileged daemon that checks a file's owner before writing. Identify the check and the use, and explain whether they operate on the same kernel object.
• We are doing an authorised container escape assessment. Walk through the path-resolution races in this runtime's bind-mount setup.
• Our payment endpoint checks the balance and then debits it. Look for an idempotency or race window and suggest how to test it safely.

Safety notes: scripts and network access

The skill runs scripts, so the agent may execute commands on the machine it is running on. Run it only in a sandboxed or disposable environment that you control. The skill does not use the network, according to its listed requirements.

Because the content is offensive in nature, confirm written permission before testing any system. Keep test binaries, mounts and cgroups isolated, and remove them when you finish.

• Run in a lab or disposable VM, not on production or shared hosts.
• Confirm you have written authorisation for every target.
• Review any script the agent proposes before it runs, especially those that mount filesystems or change cgroups.

Tips for getting useful results

Give the agent a concrete code path or syscall trace rather than a general question. The skill's own workflow starts by identifying the check and the use, then asking whether they touch the same kernel object. Answering that question yourself first narrows the search.

If you are learning, ask the agent to explain the defensive fix alongside the attack, such as operating on a file descriptor instead of a path, or using O_NOFOLLOW. The skill covers both sides.

• Name the function calls involved, for example access, open or stat.
• Ask for the defensive fix as well as the exploit path.
• Keep one hypothesis per request so results are easy to verify.