This interactive workshop distills 3.5 years of work at Root into a hands-on walkthrough: how to backport a CVE fix using AI-assisted workflows — no version upgrade required. Follow along at your own pace, or clone github.com/Root-IO-Labs/anyone-can-patch and run the Anyone Can Patch materials in examples/ using the filled prompts and skills described under WORKSHOP-DEMO-GUIDE.md.
Why "just upgrade" is broken and always was
Pinned versions, backporting, and why it matters
Research, apply, and validate with AI
Prerequisites and quick start
Your first backport, step by step
Automating everything you just learned
Clone it, run it, patch your own CVEs
The traditional security model is simple: detect vulnerabilities with scanners, upgrade to newer versions, re-scan, repeat. It's the Detect → Upgrade → Fix loop. And for a while, it kind of worked.
But every upgrade carries cost. Move from one major version to the next and you inherit breaking changes, dependency cascades, and regression risk.
Every upgrade introduces incompatible API changes that ripple through dependent services and codebases.
One forced upgrade triggers a cascade of downstream changes across the entire dependency graph.
New code ships new bugs. Every upgrade trades a known CVE for unknown regression risk.
Attackers weaponize CVEs in hours. The upgrade cycle takes weeks. The math doesn't work.
The threat model has changed. Attackers don't target your application directly anymore — they target the packages your application depends on. One compromised package means millions of downstream victims.
You can't upgrade your way to safety when the upgrade itself is the attack vector. The industry needs a different model.
Pinning your package versions gives you reproducible builds and a clear control point. But CVEs still accumulate against pinned versions. Maintainers generally don't patch old versions — they want you on the newest thing.
That's what backporting gives you. Take only the security fix from a newer version and apply it to the version you're actually running. Security benefit. Zero version bump. Debian, Red Hat, and Ubuntu have shipped backported patches for decades. Now it applies to npm, PyPI, and application-level packages too.
The situation: a CVE is fixed in v2.0, but your environment is locked to v1.8. Backporting extracts only the security fix from v2.0 and applies it directly to your pinned v1.8. No version bump. No surprises.
The commit that closes a CVE is rarely just the security delta. It usually sits in the same stream of work as refactors, new features, API moves, and dependency updates. Your task is to pull out only what remediates the finding.
Port that logic into your pinned version. Adapt function names, paths, and patterns.
Keep existing behavior intact. Remove only the vulnerability. Minimal diff. No surprises.
In the wild, the remediation is almost never the whole story. Maintainers ship it alongside refactors, new capabilities, renamed symbols, moved modules, and dependency evolution—all legitimate for them, much of it incidental for you. Drawing a defensible line between “closes the vulnerability” and “everything else in the same diff” is judgment-heavy and easy to get wrong. A patch that compiles but does not actually remove the exposure can be worse than no patch.
Notice that "upgrade" is gone. You are no longer forced to inherit every change the maintainer made just to get one security fix.
Identify the CVE in your pinned dependency. Know the version, the attack vector.
Backport the security fix directly into your pinned version. Minimal change. No upgrade.
Build, test, and verify. Confirm the vuln is closed and no regressions were introduced.
In the Anyone Can Patch repo, the facilitator guide states that participants paste prompts and @ skills; the agent runs git, edits, installs, and tests. Each phase uses one prompt file and one skill under anyone-can-patch/skills/, in order.
examples/CVE-2025-68675-apache-airflow-2.10.5/WORKSHOP-DEMO-GUIDE.md: “Follow the Step-by-step section: modify the prompt file named in that step … before you copy its fenced block.” “@ anyone-can-patch/skills/research-cve.md (then patch-cve.md, then validate-cve.md).” “Copy the fenced block from the saved prompt file into the chat.”
Each prompt file labels the block to paste as Copy-paste this prompt: (see 1-Research-Prompt.md, 2-Apply-Fix-Prompt.md, 3-Validate-Prompt.md in the example folder). A short user message is enough, e.g. to use that prompt together with the attached skill to run that phase.
README.md: Cursor / agents: read AGENTS.md at the repo root for “non-negotiable rules (two git checkouts for research, no API-only shortcuts for Phases 3–4).” The research prompt’s MANDATORY LOCAL CHECKOUTS (Phases 3–4) section requires directories named exactly fix-tree and target-tree under the example folder, matching AGENTS.md.Prompt / skill map (same guide, table under that heading): Research → 1-Research-Prompt.md + research-cve.md; Apply fix → 2-Apply-Fix-Prompt.md + patch-cve.md; Validate → 3-Validate-Prompt.md + validate-cve.md. Attach paths under anyone-can-patch/skills/ when you @ files in Cursor.
Before you start backporting, make sure you have these tools ready. After you clone the repo, open it in Cursor and follow examples/CVE-2025-68675-apache-airflow-2.10.5/WORKSHOP-DEMO-GUIDE.md — the guide’s quick-start path matches Root README.md: “Clone this repo, open it in your editor, then follow an example’s WORKSHOP-DEMO-GUIDE.md” (for instance that Airflow example folder).
anyone-can-patch/skills/ encode CVE validation, upstream fix discovery, and test commands. The guide adds: “Do not treat cloning as something participants do manually first—the agent performs it when the research prompt/skill calls for local trees after the fix location is known.”Work inside examples/CVE-2025-68675-apache-airflow-2.10.5/ using the pre-filled 1-Research-Prompt.md, 2-Apply-Fix-Prompt.md, and 3-Validate-Prompt.md. For each phase, copy only the fenced block under Copy-paste this prompt:, attach the matching skill from anyone-can-patch/skills/, and add a minimal instruction in chat. Target CVE and scope:
CVE-2025-68675 is an information exposure issue: proxy and proxies fields on an Airflow Connection can leak credentials in logs. Here's how to fix it:
1-Research-Prompt.md + anyone-can-patch/skills/research-cve.md. Save research.json next to the prompts (not under reference/), per the guide. Then read your JSON: the committed answer key includes "recommendation": "PROCEED" when backporting is advised (see reference/research.json). Confirm fix-tree/ and target-tree/ exist under the example folder; the prompt requires git rev-parse HEAD in each.2-Apply-Fix-Prompt.md + anyone-can-patch/skills/patch-cve.md. Deliverables from the prompt: branch patch-CVE-2025-68675; edits under target-tree/airflow/utils/log/secrets_masker.py; unified diff saved as CVE-2025-68675-target-tree.patch beside the prompt files. Artifact checklist (same guide): CVE-2025-68675-target-tree.patch at example root matches git diff of those edits.3-Validate-Prompt.md + anyone-can-patch/skills/validate-cve.md. The validate prompt lists pip install -e . and focused pytest tests/utils/log/test_secrets_masker.py. Compare your validation.json to reference/validation.json: that file records "passed": 58, "xfailed": 1, "verdict": "APPROVED"; regression_tests.notes states the xfail is pre-existing (see that file).PATCH.md next to the prompts; reference/PATCH.md is the committed example.#61906.You’ve walked through one CVE. For the next one, the repo’s README.md describes examples/ as holding CVE-specific filled prompts plus reference/ with completed research.json, patch, PATCH.md, and validation.json for comparison. It also says to treat anyone-can-patch/ (generic prompts/ and skills/) as read-only when running a workshop and to copy into per-CVE example folders as needed.
examples/<CVE-folder>/; copy 1-Research-Prompt.md, 2-Apply-Fix-Prompt.md, 3-Validate-Prompt.md from anyone-can-patch/prompts/ if you are bootstrapping a new CVE.@anyone-can-patch/skills/research-cve.md (then patch-cve.md, validate-cve.md). Write outputs next to the prompts, not inside reference/ (README.md).Everything in this guide — researching the upstream fix, assessing complexity, adapting the patch, validating it — Root does automatically. For every vulnerability. Across every version you run.
Root inventories every dependency across npm, PyPI, Maven, Go, and 8+ ecosystems. Every version. Every transitive dep.
When a CVE drops, Root identifies affected packages, locates the upstream fix, and maps the code divergence between your version and the patched version.
Root generates the backported patch, runs the full test suite, and confirms the vulnerability is gone — without changing your version.
The workshop materials live at github.com/Root-IO-Labs/anyone-can-patch. Clone it, open it in Cursor, and follow the guide below.
README.md: “Clone this repo, open it in your editor, then follow an example’s WORKSHOP-DEMO-GUIDE.md.”WORKSHOP-DEMO-GUIDE.md: “This repo’s example folder is already filled for CVE-2025-68675; still re-check paths if your workspace root differs.” New CVEs: copy templates from anyone-can-patch/prompts/ and replace placeholders.@ anyone-can-patch/skills/research-cve.md (then patch-cve.md, validate-cve.md), per the guide’s “How to use Cursor (prompts-only workflow)” section.README.md: your run’s outputs go next to the prompts, not inside reference/.README.md: “Cursor / agents: read AGENTS.md at the repo root for non-negotiable rules (two git checkouts for research, no API-only shortcuts for Phases 3–4).”examples/, the two clone directories must be named exactly fix-tree (upstream at the fixed ref) and target-tree (same remote at the vulnerable ref).” Those directories are gitignored; create them per WORKSHOP-DEMO-GUIDE.md (README.md layout).