conda-forge.github.io EUVD-2026-108820

Exploitation requires the attacker to control a conda-forge feedstock recipe or the upstream source a feedstock pulls from (achievable by creating a feedstock via a reviewed staged-recipes PR, after which the maintainer controls their recipe and upstream releases), and to cause an autotick-bot version-update or migration step to FAIL in a way that captures attacker-chosen build/patch/traceback output - containing an executing HTML payload such as '<img src=x onerror=...>' or '<svg onload=...>' - into the errors[name] field of version_status.v2.json or the pre_pr_migrator_status field of a migration_json file. The victim side needs no authentication but requires UI:R: a user must visit https://conda-forge.org/status/ (Version Updates panel) or the migration status page and expand the affected entry. LIMITING FACTORS: reliably landing an executing event-handler payload in captured program output is non-trivial and was not demonstrated end-to-end; attacker needs ecosystem-level access to a feedstock/upstream; and impact is confined to the conda-forge.org origin (C:L/I:L/A:N).

This is a medium-severity stored/DOM XSS (CWE-79) with multiple mitigating factors that keep real-world risk moderate rather than urgent. The vuln.today decision label is 'this_month' (not act_now/emergency), no CISA KEV listing is present, and no EPSS probability was supplied in the input - so widespread or automated exploitation is not indicated by any decision signal. The two supplied CVSS vectors CONFLICT and this should be verified: the top-level input vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N (AC:L), while the GHSA advisory itself scores AC:H. The AC:H reading is better supported by the advisory's own 'honest caveat' that severity hinges on reliably landing an executing payload in bot-captured output, which was not demonstrated end-to-end. Either way the vector requires attacker privilege in the ecosystem (PR:L - control of a feedstock) plus victim interaction (UI:R - a user must visit/expand the status entry), both of which blunt mass exploitation. The absence of sanitization is PROVEN with live production data (unescaped '<frozen _collections_abc>' reaching the DOM), but weaponization is characterized by the reporter as plausible, not demonstrated. Net: a legitimate issue worth fixing on a normal patch cadence for a high-trust package-distribution origin, but not a drop-everything emergency given PR:L, UI:R, limited (C:L/I:L/A:N) impact, and no evidence of active exploitation.

An attacker who controls a conda-forge feedstock recipe (obtainable via a reviewed staged-recipes PR) or an upstream source tarball crafts content - e.g. a filename or build/patch output containing '<img src=x onerror=...>' - that the autotick bot captures as error/status output and publishes verbatim into the status JSON. When any visitor loads conda-forge.org/status/ and expands that entry, dangerouslySetInnerHTML injects the markup and the attacker's JavaScript executes in the conda-forge.org origin. No working exploit code was supplied; the GHSA advisory proves the sink is unsanitized with live data but explicitly notes end-to-end weaponization was not demonstrated.