ComfyGuard

Read-only security evaluation for ComfyUI, with a report your coding agent can act on.

ComfyGuard evaluates an existing ComfyUI installation and writes a report. The report is the basis a developer's coding agent works from to fix the problems, guided by the agent skills that ship with the tool. It is built for instances that run on a company or local network, where the platform hands the security boundary to whoever runs the deployment.

ComfyGuard is read-only: it changes nothing on the instance. For capturing a rollback point and restoring, use ComfyUI-Manager's built-in snapshot feature; ComfyGuard does not reimplement it.

Status: Phase 1 is implemented. The comfyguard audit command is a working, dependency-free CLI that read-only scans an install and writes report.json, report.md, and an agent-ready FIXES.md. A verify command (re-assess and diff the report) is planned and stubbed. The repository also holds the concept, threat research, check catalog, reporting contract, agent skills, and worked examples.

Install and run

Requires Python 3.10+ and no third-party packages.

git clone https://github.com/joosthel/ComfyGuard && cd ComfyGuard
pip install -e .            # or: pipx install .
comfyguard audit /path/to/ComfyUI --out ./comfyguard-report
# or without installing:
python -m comfyguard audit /path/to/ComfyUI --out ./comfyguard-report

This reads the install and writes the report; it changes nothing. Add --url http://127.0.0.1:8188 --authorized to also make a read-only network probe of a running instance you are authorized to test. comfyguard audit exits non-zero when a critical finding exists, so it fits CI.

ComfyGuard is a starting point, not a turnkey fix. Applying its proposed changes to a production ComfyUI instance can break running pipelines. Review every change, back up first, and test in a safe environment. See FIXES.md and the agent skills.

Why this exists

Generative tools are moving onto real hardware in real production settings: studio render nodes, company GPU servers, cloud VMs. That is a healthy sign of the field maturing, and it is exactly why security matters. A powerful tool on strong hardware, reachable on a network, is a valuable target, and it needs the same production hygiene as any other networked service.

ComfyUI is designed to run locally and, by its own security policy, trusts anyone who can reach its URL. Once an instance is on a network, securing it is the operator's job. Comfy.org has done real work on the parts it owns: the Registry scans and bans obfuscated custom nodes, ComfyUI-Manager has security levels, and recent releases moved sensitive data behind protected paths. ComfyGuard covers the other half, the security of a specific deployment, which only the operator can see and configure. It complements that work rather than replacing it.

The need is concrete. In 2026 more than a thousand exposed, unauthenticated ComfyUI instances were hijacked into cryptomining and proxy botnets, and a critical unauthenticated remote-code-execution flaw (CVE-2026-68771) was disclosed and patched. The evidence base is in docs/RESEARCH.md.

How it works

ComfyGuard assesses; a coding agent fixes. It is read-only throughout.

• comfyguard audit <path> Read-only scan across core and versions, exposure and access, custom nodes, dependencies, and model files, plus secrets and host checks. Produces ranked findings, a single A-to-F grade, and a remediation plan. Safe to run on a live instance.
• comfyguard verify <path> (planned) Re-assess and diff against a prior report by fingerprint, to confirm the agent's fixes landed and nothing regressed. Until it ships, re-run audit and diff the two reports.

Before an agent touches anything, capture a rollback point with ComfyUI-Manager's snapshot feature. The agent skills in skills/ teach Claude Code or any coding agent how to read the report and apply fixes under clear gates. A curated, versioned ComfyUI threat feed (known CVEs and malicious-node indicators) drives the version and known-bad checks and ships bundled so the tool works offline. See docs/SPEC.md for the full specification.

What it evaluates

• Core and versions. ComfyUI and ComfyUI-Manager matched against the threat feed of known CVEs.
• Exposure and access. Bind address, authentication, TLS, reverse proxy, CORS, launch flags, and the Manager security level.
• Custom nodes. Static analysis for code-exec, runtime installs, obfuscation, network calls, and install.py behavior, with provenance and a known-malicious list. Nothing is executed.
• Dependencies. Pinning, direct-URL/git installs, typosquat-shaped names, and known-malicious pins from the bundled feed. ComfyGuard runs fully offline, so live CVE lookups (OSV, PyPA) are out of scope; run pip-audit yourself for that.
• Model files. Static pickle inspection of .ckpt/.pt/.bin, without loading them.
• Secrets and host. Credentials in the environment or config, root execution, privileged containers, mounted Docker socket, and directory permissions.

The full catalog is in docs/CHECKS.md.

Eight best practices for a secure ComfyUI instance

These are the baseline ComfyGuard measures against. They matter most once an instance is reachable beyond a single local user. ComfyGuard reports where you stand against them; a coding agent applies the fixes.

1. Keep ComfyUI on localhost, and reach it through a proxy. Do not expose it directly with a bare --listen 0.0.0.0. For remote access, put an authenticating, TLS-terminating reverse proxy (nginx, Caddy, Cloudflare Access) or a VPN in front, with ComfyUI bound to 127.0.0.1.
2. Require authentication for anything beyond a single local user. ComfyUI core has none, so it lives in the proxy or network layer. Treat --multi-user as storage partitioning, not access control.
3. Stay current, and set Manager to strong. Keep ComfyUI core and ComfyUI-Manager updated. On a networked instance set the Manager security level to strong, and keep runtime pip and git installs disabled unless actively needed.
4. Vet custom nodes before installing. Prefer verified Registry publishers, read install.py and requirements.txt, and avoid nodes that run code at import time or need broad network access. Popularity is not a trust signal.
5. Prefer safetensors over pickle formats. Treat .ckpt, .pt, and .bin files from untrusted sources as code, not data, because they can execute on load.
6. Run with least privilege. Use a non-root user or container, never --privileged, never mount the Docker socket, and scope GPU access through the proper device mechanism. Do not bind-mount broad host paths.
7. Keep secrets and egress under control. Do not put secrets in the process environment, because every custom node can read it; use mounted secret files or a manager. Restrict outbound network access to what the instance actually needs.
8. Assess before you expose, and re-assess on a schedule. Scan the instance, fix the findings, verify, and repeat. Set --disable-api-nodes and --disable-metadata when those features are not needed.

The standing baseline for agents is in AGENTS.md.

Design principles

Strictly read-only; it changes nothing on the instance. Never execute untrusted code or data. Offline-first. No installation into ComfyUI (it inspects from the outside). ComfyUI-aware, not a generic linter. Rank, do not just flag. Layered detection. Standards-based, agent-ready output. Deterministic and explainable. The reasoning is in docs/CONCEPT.md.

Output

Phase 1 (audit) writes:

• report.json: structured findings, a bom block (nodes, declared dependencies, and models), and the detected launch config.
• report.md: a human summary that leads with the grade and the pre-exposure gate.
• FIXES.md: an ordered, gated remediation plan for a coding agent. ComfyGuard writes it; it never applies it.

Planned: report.sarif (SARIF 2.1.0 for GitHub code scanning).

The reporting and remediation contract is in docs/REPORTING.md, with worked examples in examples/.

Command reference

# Phase 1, implemented and read-only:
comfyguard audit /path/to/ComfyUI --out ./comfyguard-report
comfyguard audit /path/to/ComfyUI --url http://127.0.0.1:8188 --authorized

# Hand report.json and FIXES.md to a coding agent (Claude Code or similar) with
# the skills in skills/, then let it work the plan under the gates, with an
# operator confirming every review-required and human-only change. Capture a
# rollback point first with ComfyUI-Manager's snapshot feature.

Roadmap

1. Assess: audit across the core layers, the threat feed, the report, and the agent skills (done).
2. Verify and breadth: verify (re-assess and diff the report by fingerprint), SARIF output, and broader offline check coverage.
3. Freshness: signature-verified feed refresh, YARA family rules, secret scanning, and workflow analysis.
4. Continuous use: a CI action, scheduled re-scans, and an optional local dashboard.

A note on limits

A clean grade means no known-bad patterns, versions, or configurations were found. It does not prove a deployment is safe. Static analysis can be evaded by novel or obfuscated payloads, which is why the design is layered and why high-assurance environments should pair ComfyGuard with containment: a least-privilege user, egress filtering, and sandboxing.

Documentation

• docs/SPEC.md: the consolidated specification.
• docs/CONCEPT.md: problem, principles, architecture, roadmap.
• docs/CHECKS.md: the full check catalog.
• docs/REPORTING.md: output formats and the agent remediation contract.
• docs/RESEARCH.md: the threat landscape, prior-art survey, and current ComfyUI security posture.
• AGENTS.md: the standing security baseline for agents.
• skills/: agent skills for auditing and remediating.
• spec/checks.example.yaml: the machine-readable ruleset format.
• examples/: a sample report and remediation plan.

Responsible use

ComfyGuard is a defensive self-assessment tool. Use it only against ComfyUI deployments you operate or are authorized to test. The static and host checks run on a local installation; the network probe is opt-in, defaults to localhost, and requires you to assert authorization for any non-loopback target. It does not exploit, and it is strictly read-only.

Contributing

Contributions are welcome, especially new checks and threat-feed entries. Please read CONTRIBUTING.md first; it lists the principles a change must preserve (read-only, never execute untrusted code, offline-first). By contributing you agree to the Code of Conduct.

Security

To report a vulnerability in ComfyGuard itself, follow SECURITY.md. Do not open a public issue. Vulnerabilities in ComfyUI or ComfyUI-Manager should go to their own maintainers.

Acknowledgements

ComfyGuard builds on the work of the ComfyUI project and ComfyUI-Manager (whose snapshot feature it recommends for backup and rollback), and on the ideas of established open-source security tools, including Bandit and Semgrep, modelscan and Fickling, and the SARIF and CycloneDX standards. It runs fully offline; for live dependency CVEs, pair it with pip-audit or OSV, which ComfyGuard deliberately does not call. The threat research credits the vendors and researchers cited in docs/RESEARCH.md.

License

Released under the MIT License.