ComfyUI 2025 Jan Security Update

Here's to a new beginning!

Hello, and happy new year to our dear ComfyUI community! 👋 As our platform keeps growing (thanks to all of you!), we've been developing some important new security features to keep everyone safe while maintaining the creative, open spirit that makes ComfyUI great.

History

We've already seen vulnerabilities discovered in ComfyUI custom nodes: ComfyUI_LLMVISION and ultralytics. We have added built-in security checks before to the ComfyUI Registry to allow us to ban nodes when vulnerabilities are discovered quickly. Along with the registry launch, we are rolling out a few security practices and open discussion for the next step to improve ComfyUI.

What’s New?

Preventive measures

We will start ramping up ComfyUI Registry restrictions on a few code practices.

• eval/exec calls

  • Reason:

    • Both functions can result in arbitrary code execution and, thus, when used to evaluate user inputs, are direct attack vectors for Remote Code Execution (RCE) attacks. Workflows containing nodes that pass user inputs into eval or exec can, at this very moment, be used to perform any cyberattack you can imagine on the hardware running ComfyUI – keylogging, ransomware, etc.

  • Timeline:

    • We will be first sending warning messages for existing custom nodes that use eval

    • In 1 month, we will block incremental changes that add “eval” and “exec” calls to your custom nodes.

    • In 3 months, or if we finish the migration of existing custom nodes code early, we will block all public nodes.

• subprocess runs for pip install

  • Reason:

    • Historically, when there wasn’t a mechanism for users to easily install custom nodes, some node authors took the challenge to their hands-built ways to install packages and reload them during runtime for convenience.

    • The ComfyUI manager is the default part of the ComfyUI desktop experience. There is no reason for custom nodes to install packages at runtime.

    • Having requirements in a single place allows us to easily detect dependencies for any node pack and detect and fix potential supply chain attacks.

    • It’s also a bad user experience to sometimes reload ComfyUI twice to get a node to work.

  • Timeline:

    • We will first block the incremental addition of pip installation for the registry at runtime.

    • In 6 months, or if we finish migration of existing custom nodes code early, we will block all publish nodes from calling pip install

• Code obfuscation

  • Reason:

    • Code obfuscation makes it harder to review the code

  • Timeline:

    • We will be first sending warning messages for existing custom nodes that have code patterns (multiple statements, undefined variables, etc) of obfuscation.

    • We will block any verified custom node that obfuscates their code.

What can I do as a custom node developer?

• Download the latest version of comfy-cli and run comfy node validate in your custom node directory

• If you did, you should migrate away from using either call.

• Please let us know why you need such a mechanism, and we can evaluate such policies. Maybe a common API can be added to core.

Detective measures

When the initial ComfyUI_LLMVISION happened, we started planning our security scanning infra. We use AI and static analysis tools to scan potential mechanisms that custom nodes might be a security threat and alert a private channel. A huge shout-out to our friends at #security-private channel to help us improve our security scanning practices.

Going forward, we will alert potential security threats in a public Discord channel #security-review-council. Please help us and the rest of the ecosystem to verify the security issues being flagged in that channel as a second line of defense.

Code obfuscation, HTTP requests, and other potential anomalies will be flagged during detection.

Given the nature of the security defense, our security scanning functionality and code will be held privately. If you want to contribute to it, please contact us at hello@comfy.org.

Future Roadmap:

• Verification Process:

  • We will gradually verify ComfyUI custom node authors and mark their nodes as verified. The details of this process and practice are yet to be discussed.

• Stronger Preventive Measures:

  • Sandboxed version of ComfyUI: We want to experiment with using Window Sandbox for future releases of the ComfyUI Desktop experience while testing similar solutions for Mac (yes, we know Docker exists). If you are interested in working on it, please reach out to us at hello@comfy.org

  • Our CI system (ci.comfy.org) will run all custom nodes on example graphs in the future to verify dependency conflicts and check for weird behaviors.

• Corrective measures:

  • We will introduce a new mechanism in the ComfyUI manager that allows users to remotely remove, disable, and spin down malicious custom nodes without updating ComfyUI.

Need Your Input:

• These are just the beginning of our process of improving our security practices.

• What are some of the other cases we should be watching out for? Should there be a policy on custom wheels, binaries, git python dependencies (git+[http|ssh]…), remote web accesses, file accesses, and running subprocesses? Should there be a bounty program? How should we introduce permission management? If you have strong opinions, please email us at our forum security section: https://forum.comfy.org/c/security-discussion/12, or join us at the security discussions on Discord.

• Similarly, How do these practices impact your nodes? Please comment on the suggestions at https://forum.comfy.org/c/security-discussion/12

Important Final Message!

We are pushing the boundaries of visual Gen AI tooling in open source to democratize AI. We are a very small, intense, and well-funded team in San Francisco. We want to build an OS for AI. If this mission excites you and you view yourself as a top-tier talent, talk to us at hiring@comfy.org. Your future latent self is waiting for you at Comfy Org.