本文へ移動
cccskills
無料GitHub で公開

security-repro

Build safe, local, defensive reproductions of ALREADY-PATCHED, publicly disclosed security vulnerabilities (CVEs, vendor advisories, AI-agent incidents) for whitepapers, control testing, and education. Use this skill whenever the user wants to reproduce, demonstrate, or write up a known vulnerability or security incident — phrases like "reproduce this CVE", "build a repro for", "demonstrate the EchoLeak/Cursor/postmark-mcp issue", "show how this exploit worked", "add a reproducibility guide", or "pull the NVD/CVE details for". It fetches advisory metadata from NVD and CVE.org, confirms the issue is fixed, and produces a vulnerable-vs-patched harness that is offline, loopback-only, and uses synthetic markers. It NEVER discovers, develops, or weaponizes new zero-days and refuses any unpatched or live-target request.

インストール方法を見る

含まれるファイル(5)

  • SKILL.md6.7 KB
  • references/harness-pattern.md2.8 KB
  • scripts/check_patched.py3.0 KB
  • scripts/fetch_cve.py2.0 KB
  • scripts/fetch_nvd.py2.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

security-repro

Reproduce already-fixed, publicly disclosed vulnerabilities so a reader can see the failure mode and confirm the vendor's patch closes it. The audience is a whitepaper or an internal control test. The output is a contrast: the vulnerable behavior fires, the patched behavior refuses, and nothing real is touched.

The one hard line (read first)

This skill exists to reproduce the past, not to find the new. Everything below flows from that.

  • Only patched or withdrawn issues. If the vendor has not shipped a fix (or pulled the artifact), stop. Do not proceed on an open/unpatched issue, even a disclosed one.
  • Use the last known-vulnerable public version that is already on the internet — the release before the fix. You are demonstrating something that already exists publicly, not creating it.
  • Never develop new exploitation. No fuzzing for new bugs, no chaining, no variant discovery, no bypassing an unfixed control. If reproducing the disclosed mechanism faithfully would require inventing an undisclosed step (e.g. an escape whose mechanism was never published), leave that step out of scope and say so in writing.
  • Offline, loopback, synthetic. No third-party host, no real credential, no real target, no real recipient, no persistence, no exfiltration. A successful reproduction means a local marker or a policy decision is observed, not that code ran on someone's machine or data left the lab.

If a request pushes past this line — reproduce an unpatched bug, target real infrastructure, weaponize a payload, evade detection — decline that part in one sentence, explain why (it would be new zero-day / offensive work), and offer the safe version instead. This protects the user legally; it is the whole point.

Workflow

1. Establish that the issue is public AND patched

Before writing any code, pin down three facts and record them in the guide:

  1. Disclosure — a primary source: vendor advisory, MSRC/GitHub/GitLab advisory, or the researcher's write-up.
  2. Fix — the version or commit that patched it, or confirmation the artifact was withdrawn. This is the gate. No fix, no repro.
  3. Vulnerable version — the last public release before the fix.

Use the helper scripts to pull machine-readable metadata:

# NVD record (CVSS, references, CWE, published/modified dates)
python3 scripts/fetch_nvd.py CVE-2025-32711

# CVE.org record (CNA description, affected versions, references)
python3 scripts/fetch_cve.py CVE-2025-32711

# Pretty one-line "is this patched?" summary across both sources
python3 scripts/check_patched.py CVE-2025-32711

These call only the public NVD and CVE.org REST APIs (read-only). They do not touch any victim system. If the CVE has no Fixed/patched reference and no withdrawal note, treat the patched status as unconfirmed and tell the user to verify against the vendor before you build anything.

2. Model the mechanism minimally, not the whole kill chain

Reduce the disclosure to the single control failure worth showing, and replace every dangerous verb with an inert marker:

Real elementReproduce it as
shell / exec / RCEa function that writes MARKER.txt with a fixed string
credential / secreta decoy file like DECOY_SECRET.txt = not-a-real-secret
exfiltration endpointan in-process or 127.0.0.1 loopback sink that just logs
email recipientrecipient@example.invalid
write outside sandboxa path calculation that is asserted, never performed
a real vulnerable dependencypin the real last-vulnerable version only if a
primary source confirms that exact version; otherwise model the disclosed
mechanism in two local loaders (vulnerable_* / patched_*) and say so

Cut the parts whose mechanism was never disclosed (mark them "explicitly out of scope"). Reconstructing an undisclosed step is new zero-day work — forbidden.

3. Build the vulnerable-vs-patched harness

Follow the house pattern already in Reproducibility/ in the whitepaper repo:

  • A single self-contained harness (stdlib-only Python preferred; Docker with network_mode: none when isolation must be enforced).
  • Two code paths: vulnerable (the marker fires) and patched (the same input is refused with a decision like block / review_required).
  • Deterministic output, a saved results/run.json (or transcript), and a non-zero exit if the contrast does not hold.
  • Log the gateway-relevant fields: source, data_class, outbound_channel, decision, policy_id, and a short reason.

See references/harness-pattern.md for the concrete file layout, the safety checklist, and a copyable harness skeleton.

4. Write the guide

Produce a short markdown guide next to the harness with these sections: Status and scope (name the CVE, the fix version, and what is explicitly out of scope), Lab design / Reproduction protocol, Defensive assertion (what control would have caught it), Safety limits, and Sources (primary links only). Match the tone and structure of the existing numbered guides.

5. Hand back run commands

Per this user's standing rule, do not execute reproduction harnesses yourself — write them, then give the exact command to run. State clearly what a pass looks like (which marker appears, which decision is logged).

Scripts

  • scripts/fetch_nvd.py CVE-ID — NVD 2.0 API record as JSON (CVSS, refs, CWE).
  • scripts/fetch_cve.py CVE-ID — CVE.org CVE Record (CNA data, affected versions).
  • scripts/check_patched.py CVE-ID — combines both and prints whether a fixed version / patch reference is present, so the "is it patched?" gate is fast.

All three are read-only, hit only public vulnerability databases, and take a single CVE ID argument.

References

  • references/harness-pattern.md — file layout, safety checklist, and a stdlib-only harness skeleton to copy.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Analyze tau2-bench task export files to identify exactly where and why tasks failed. Map failures to specific conversation rounds, show root causes, check whether relevant documentation was available, and cite sources. Use this skill whenever you need to debug a tau2-bench evaluation, understand why an agent made wrong decisions, identify missing knowledge, or review task performance—especially when context length, eligibility criteria, or policy compliance might be at fault.

日本語の概要は準備中です。原文の説明を表示しています。

Leanmcp/gateway-skills2,1112026年10月8日 更新

How to develop, modify, and extend the Claude Code codebase following its established programming style, patterns, and conventions. Use this skill whenever working on the claude-code source — adding tools, commands, utils, components, types, hooks, services, or fixing bugs. Also use when the user asks about claude-code architecture, coding standards, file organization, or wants to understand how the codebase works. This skill ensures all contributions match the existing codebase style exactly.

日本語の概要は準備中です。原文の説明を表示しています。

Leanmcp/gateway-skills2,1112026年10月8日 更新

Generate a complete, beginner-friendly explanation of an entire code repository as a set of markdown files. Maps the repo structure with `treecap` (installing it if missing), studies the actual source, then writes a `CODE_EXPLANATION/` folder containing an `OVERVIEW.md` plus numbered deep-dive files (01_architecture.md, 02_models.md, ...) that explain how the code is built, what it does, and how the pieces fit together — illustrated with real code excerpts. Use this skill whenever the user wants to understand, document, onboard onto, or get a walkthrough of a codebase: phrases like "explain this repo", "explain the code", "code explanation", "walk me through this codebase", "help me understand how this is built", "document the architecture", or "what does this project do" — even if they don't say the word "skill". Prefer this over ad-hoc summaries whenever the goal is a durable, written explanation of a whole repo.

日本語の概要は準備中です。原文の説明を表示しています。

Leanmcp/gateway-skills2,1112026年10月8日 更新

Run inference on Fireworks AI — direct, through the Leanmcp AI Gateway proxy (aigateway.leanmcp.com) for observability, or via LiteLLM / the OpenAI SDK / raw HTTP. Covers the endpoint-and-key matrix for each route, serverless vs dedicated deployments and their cold starts, browsing and filtering the model catalogue, reasoning models that return content:null with the answer in reasoning_content, function calling, concurrency and load testing, and runner scripts where many models share one protocol with a --use-proxy toggle. Use this skill whenever the user mentions Fireworks, FIREWORKS_API_KEY, api.fireworks.ai, fireworks_ai/ model ids, accounts/fireworks/models/..., a Fireworks deployment id, the Leanmcp gateway or LEANMCP_API_KEY, app.leanmcp.com observability, or gpt-oss / kimi / glm / qwen / deepseek served on Fireworks; wants to route LLM calls through a proxy for logging or cost tracking; is debugging empty responses, 404s, scope errors, cold starts, or "the gateway isn't working"; wants to pick a Fireworks model with tool calling; or wants to sweep several models over one benchmark. Reach for it even on vague asks like "why is this model returning nothing" or "set up inference for these models" when Fireworks is in play.

日本語の概要は準備中です。原文の説明を表示しています。

Leanmcp/gateway-skills2,1112026年10月8日 更新

Build, run, debug and ship 3D city games in Godot 4 — procedurally generated cities (block grids, districts, weighted building typologies, MultiMesh batching, facade shaders, terrain, day/night, landmarks), first-person controllers, headless verification, Blender-generated .glb assets, rigged character and animation packs, real OpenStreetMap-derived cities, WebAssembly export, and cloud GPU streaming on GCP. Use this skill whenever the work involves Godot or a .gd/.tscn/.gdshader/project.godot file; whenever someone wants to start, set up, clone onto a new machine, or stand up a 3D game or city generator; whenever they mention procedural city, city generator, block grid, building typology, MultiMesh, facade shader, terrain heightmap, navmesh, Godot export templates, export presets, headless Godot, .glb pipeline, Blender asset generation, character rigs or borrowed animations; and whenever they want to deploy or share a game — web export, SharedArrayBuffer/COOP/COEP, Selkies, pixel streaming, GPU VM, or "let people play this without installing anything." Reach for it even on vague asks like "get this running", "why is my city slow", "my model faces backwards", "make it work on a cloud machine", or "set this up somewhere else too" when a Godot 3D project is in play.

日本語の概要は準備中です。原文の説明を表示しています。

Leanmcp/gateway-skills2,1112026年10月8日 更新

Scaffold a native iOS app (SwiftUI, no dependencies) from nothing, run it in the Simulator, and archive + upload it to TestFlight entirely from the command line. Bundles working scripts for icon generation, simulator run, and signed upload via the App Store Connect API. Use this whenever the user wants to build, run, ship, or debug an iOS/iPhone/iPad app, mentions Xcode, SwiftUI, .xcodeproj, xcodebuild, simctl, provisioning, code signing, App Store Connect, TestFlight, archiving, or "get this on my phone" — and also when an existing iOS build is failing on icons, signing, teams, destinations, or duplicate build numbers.

日本語の概要は準備中です。原文の説明を表示しています。

Leanmcp/gateway-skills2,1112026年10月8日 更新

Leanmcp のスキルをすべて見る

このスキルの問題を報告する