[GH-ISSUE #3085] ComfyUi-MpiNodes flagged by registry security scan (false positive) — latest_version stuck at 1.0.4 despite clean source #1097

New issue

Closed

opened 2026-10-27 21:25:45 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-27 21:25:45 +00:00

Owner

Originally created by @MadPonyInteractive on GitHub (Jul 15, 2026).
Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/3085

Publisher: mad-pony-interactive
Node pack: ComfyUi-MpiNodes
Repo: https://github.com/MadPonyInteractive/ComfyUi-MpiNodes
Referred here by: Denys (Comfy Org Support), via email.

Problem

Every version I've published since 1.0.5 is NodeVersionStatusFlagged, so latest_version is frozen at 1.0.4 (March 2026). Registry/Manager users installing my pack get months-old code. I believe this is a scanner false positive and would like a manual review.

This looks like the same class of issue as #3072 and #3059.

Status from the API

GET https://api.comfy.org/nodes/ComfyUi-MpiNodes/versions

Versions	Status	Note
1.0.0 – 1.0.4	✅ Active
1.0.5 – 1.0.8	⛔ Banned	these genuinely used `eval()` — correct ban
1.1.0 – 1.2.3	🚩 Flagged	the false positive

latest_version = 1.0.4

What I already fixed

The ban on 1.0.5–1.0.8 was legitimate — a math node used eval(). I removed it entirely: math evaluation is now a pure ast-whitelist evaluator (numeric literals + arithmetic operators + math.* only; no attribute access, no arbitrary calls). That downgraded the status Banned → Flagged, but it has stayed Flagged for every release since — including ones that contain no eval/exec token anywhere in the source.

Current source is clean (verified on latest)

$ grep -rnE '\beval\b|\bexec\b|os\.system|pickle|__import__|\bcompile\(' --include=*.py .
(no matches)

$ grep -rn 'shell=True' --include=*.py .
(no matches)

No eval / exec / os.system / pickle / __import__ / compile() / runtime pip install.
The only subprocess calls invoke ffmpeg with fixed argument lists (no shell=True, no user-controlled command string) — the same pattern VHS-VideoHelperSuite uses for video I/O, and that pack is not flagged.
No obfuscation, no non-allowlisted network calls.

Ask

Could someone manually review the latest version (or the whole 1.1.0+ line) and, if it passes, clear the flag so latest_version advances? If there's a specific pattern the scanner is catching, I'd genuinely like to know so I can fix it directly.

Thanks!

Originally created by @MadPonyInteractive on GitHub (Jul 15, 2026). Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/3085 **Publisher:** `mad-pony-interactive` **Node pack:** `ComfyUi-MpiNodes` **Repo:** https://github.com/MadPonyInteractive/ComfyUi-MpiNodes **Referred here by:** Denys (Comfy Org Support), via email. ### Problem Every version I've published since 1.0.5 is `NodeVersionStatusFlagged`, so `latest_version` is frozen at **1.0.4** (March 2026). Registry/Manager users installing my pack get months-old code. I believe this is a **scanner false positive** and would like a manual review. This looks like the same class of issue as #3072 and #3059. ### Status from the API `GET https://api.comfy.org/nodes/ComfyUi-MpiNodes/versions` | Versions | Status | Note | |---|---|---| | 1.0.0 – 1.0.4 | ✅ Active | | | 1.0.5 – 1.0.8 | ⛔ Banned | these genuinely used `eval()` — correct ban | | 1.1.0 – 1.2.3 | 🚩 **Flagged** | the false positive | `latest_version` = **1.0.4** ### What I already fixed The ban on 1.0.5–1.0.8 was legitimate — a math node used `eval()`. I **removed it entirely**: math evaluation is now a pure `ast`-whitelist evaluator (numeric literals + arithmetic operators + `math.*` only; no attribute access, no arbitrary calls). That downgraded the status **Banned → Flagged**, but it has stayed Flagged for every release since — including ones that contain **no `eval`/`exec` token anywhere in the source**. ### Current source is clean (verified on latest) ``` $ grep -rnE '\beval\b|\bexec\b|os\.system|pickle|__import__|\bcompile\(' --include=*.py . (no matches) $ grep -rn 'shell=True' --include=*.py . (no matches) ``` - No `eval` / `exec` / `os.system` / `pickle` / `__import__` / `compile()` / runtime `pip install`. - The only `subprocess` calls invoke **ffmpeg** with fixed argument lists (no `shell=True`, no user-controlled command string) — the same pattern VHS-VideoHelperSuite uses for video I/O, and that pack is not flagged. - No obfuscation, no non-allowlisted network calls. ### Ask Could someone manually review the latest version (or the whole 1.1.0+ line) and, if it passes, clear the flag so `latest_version` advances? If there's a specific pattern the scanner is catching, I'd genuinely like to know so I can fix it directly. Thanks!

bsakaguchi closed this issue

2026-10-27 21:25:45 +00:00

bsakaguchi commented

2026-10-27 21:25:46 +00:00

Author

Owner

@MadPonyInteractive commented on GitHub (Jul 15, 2026):

Update — I think I found the likely trigger, same class as #3072's python_network_operations false positive.

My web/ frontend had exactly one network call: a fetch() in JavaScript (web/combos.js) loading a same-origin JSON asset my own pack ships. No external host, no http(s)://, no user input — but it's a network op in a .js file, which is exactly what misfired in #3072.

That fetch belonged to a BETA node (MpiCombo) that's now superseded by a vanilla ComfyUI node and used in zero workflows. I've removed it and the entire combo node group in v1.2.4 (just published). The pack now has zero network calls anywhere in the frontend, on top of already having no eval/exec/subprocess-shell in the Python.

If the scanner re-scans 1.2.4 and it clears, that confirms the JS-fetch was the trigger. If it still flags with a zero-network-call frontend, then it's matching something non-obvious and I'd really appreciate knowing what. Either way, could someone re-review 1.2.4?

@MadPonyInteractive commented on GitHub (Jul 15, 2026): Update — I think I found the likely trigger, same class as #3072's `python_network_operations` false positive. My `web/` frontend had exactly one network call: a `fetch()` in JavaScript (`web/combos.js`) loading a same-origin JSON asset my own pack ships. No external host, no `http(s)://`, no user input — but it's a network op in a `.js` file, which is exactly what misfired in #3072. That fetch belonged to a BETA node (`MpiCombo`) that's now superseded by a vanilla ComfyUI node and used in zero workflows. I've **removed it and the entire combo node group** in **v1.2.4** (just published). The pack now has **zero network calls anywhere in the frontend**, on top of already having no `eval`/`exec`/`subprocess`-shell in the Python. If the scanner re-scans 1.2.4 and it clears, that confirms the JS-fetch was the trigger. If it still flags with a zero-network-call frontend, then it's matching something non-obvious and I'd really appreciate knowing what. Either way, could someone re-review 1.2.4?

bsakaguchi commented

2026-10-27 21:25:46 +00:00

Author

Owner

@MadPonyInteractive commented on GitHub (Jul 19, 2026):

Update — the conditional in my previous comment has resolved, and it
resolved the other way.

I removed the web/combos.js fetch in 1.2.4, so the pack has had zero
frontend network calls since. I have published 1.2.5 and 1.2.6
since then. All still flagged; latest_version is still 1.0.4.

GET https://api.comfy.org/nodes/ComfyUi-MpiNodes
  latest_version.version: 1.0.4        (checked 2026-07-19)

That is seven consecutive versions (1.1.0 → 1.2.6) that publish
successfully and are CDN-downloadable, none of which has advanced the
pointer. So the JS-fetch was not the trigger, and my earlier guess
was wrong — please disregard it.

What this rules out, concretely:

No eval/exec/os.system/pickle/__import__/compile() anywhere
in the Python (removing eval did move it Banned → Flagged, so the
scanner does respond to source changes).
Zero network calls in the frontend since 1.2.4.
The only subprocess use is ffmpeg with fixed argument lists, no
shell=True — the same pattern VHS-VideoHelperSuite uses.

I am out of things to test from my side: the version-status endpoint
returns no status_reason, so there is nothing to work backwards from.

I see #3059 was cleared this way on 2026-07-18 — same symptom (flagged
versions blocking the latest_version pointer), resolved by a manual
review. Could the 1.1.0+ line get the same treatment? And if the scanner
is matching something specific, I would genuinely like to know what it is.

@MadPonyInteractive commented on GitHub (Jul 19, 2026): Update — the conditional in my previous comment has resolved, and it resolved the *other* way. I removed the `web/combos.js` fetch in 1.2.4, so the pack has had zero frontend network calls since. I have published **1.2.5** and **1.2.6** since then. All still flagged; `latest_version` is still **1.0.4**. GET https://api.comfy.org/nodes/ComfyUi-MpiNodes latest_version.version: 1.0.4 (checked 2026-07-19) That is seven consecutive versions (1.1.0 → 1.2.6) that publish successfully and are CDN-downloadable, none of which has advanced the pointer. So the JS-fetch was **not** the trigger, and my earlier guess was wrong — please disregard it. What this rules out, concretely: - No `eval`/`exec`/`os.system`/`pickle`/`__import__`/`compile()` anywhere in the Python (removing `eval` did move it Banned → Flagged, so the scanner does respond to source changes). - Zero network calls in the frontend since 1.2.4. - The only `subprocess` use is ffmpeg with fixed argument lists, no `shell=True` — the same pattern VHS-VideoHelperSuite uses. I am out of things to test from my side: the version-status endpoint returns no `status_reason`, so there is nothing to work backwards from. I see #3059 was cleared this way on 2026-07-18 — same symptom (flagged versions blocking the `latest_version` pointer), resolved by a manual review. Could the 1.1.0+ line get the same treatment? And if the scanner is matching something specific, I would genuinely like to know what it is.

bsakaguchi referenced this issue

2026-10-28 21:03:31 +00:00

[PR #1097] [MERGED] Update install_type for ComfyUI-Molmo in custom-node-list.json #1708