CVE-2025-32784: conda-forge Race Condition Vulnerability

CVE-2025-32784 Overview

CVE-2025-32784 is a Time-of-Check to Time-of-Use (TOCTOU) race condition in conda-forge-webservices, the web application that runs conda-forge admin commands and linting. The flaw affects versions prior to 2025.4.10 and resides in the shared build infrastructure that publishes packages from the cf-staging Anaconda channel to the production conda-forge channel. An attacker holding the cf-staging token can swap a validated artifact for a malicious one between the hash check and the copy operation. The result is unauthorized publication of tampered packages to the production channel, creating a software supply chain risk for every downstream consumer of conda-forge.

Critical Impact
Successful exploitation allows publication of malicious build artifacts to the production conda-forge channel, impacting downstream package consumers across the Python and scientific computing ecosystem.

Affected Products

conda-forge-webservices versions prior to 2025.4.10
conda-forge shared build infrastructure (cf-staging Anaconda channel)
Downstream conda-forge production channel consumers

Discovery Timeline

2025-04-15 - CVE-2025-32784 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-32784

Vulnerability Analysis

The vulnerability is classified under [CWE-367] Time-of-Check Time-of-Use Race Condition. The artifact promotion workflow in conda-forge-webservices performs two sequential steps: it validates an artifact hash on cf-staging, then copies the artifact to the production conda-forge channel. These two operations are not atomic. Between the hash check and the copy, an attacker with the cf-staging token can replace the artifact with a malicious build that shares the package name but contains different content. Because cf-staging permits artifact overwrites, the substitution is accepted by Anaconda's backend.

The production copy then promotes the malicious artifact, and any user installing the affected package from conda-forge receives the tampered build.

Root Cause

The root cause is the absence of atomicity between hash validation and the artifact copy operation. The webservice trusts that the artifact bytes observed during validation remain unchanged at the moment of promotion. No re-verification occurs against the destination channel after the copy completes, so a swapped artifact bypasses integrity controls.

Attack Vector

Exploitation requires possession of the cf-staging upload token, which makes this a high-privilege attack rather than an unauthenticated network exploit. With that token, the attacker uploads a benign artifact, waits for the webservice to validate its hash, then issues anaconda upload --force to overwrite the staged file before the copy executes. The race window must be timed against the webservice promotion pipeline.

python

         self.write(json.dumps({"deprecated": True}))
 
 
+def _comment_on_core_notes_if_bad_copy(copied, errors, outputs, label, hash_type):
+    from conda_forge_webservices.feedstock_outputs import _is_valid_output_hash, PROD
+
+    gh = get_gh_client()
+    repo = gh.get_repo("conda-forge/core-notes")
+
+    channel_str = "conda-forge" if label == "main" else f"conda-forge/label/{label}"
+
+    for o in outputs:
+        if (
+            copied[o]
+            and not _is_valid_output_hash({o: outputs[o]}, hash_type, PROD, label)[o]
+        ):
+            copied[o] = False
+            errors.append(
+                f"package {o} has an incorrect hash on {channel_str}"
+            )
+
+            comment = (
+                f"The package `{o}` was found on {PROD}, but with the incorrect hash ("
+                f"`{hash_type}:{outputs[o]}`). Please investigate!"
+            )
+
+            for issue in repo.get_issues(state="open"):
+                if f"`{o}`" in issue.title:
+                    issue.create_comment(comment)
+                    return

Source: conda-forge-webservices commit 141ed27. The patch re-validates the artifact hash against the production channel after copy and surfaces a failure when the destination bytes do not match the staged hash.

Detection Methods for CVE-2025-32784

Indicators of Compromise

Conda packages on conda-forge whose recorded hash does not match the hash on cf-staging for the same artifact name and version.
Multiple anaconda upload --force calls against cf-staging for the same artifact within a short window.
Unexpected commits or issues on conda-forge/core-notes referencing incorrect hashes after the patch is applied.

Detection Strategies

Compare SHA256 hashes of promoted artifacts against the staged artifact recorded at validation time, and alert on divergence.
Audit cf-staging token usage and correlate token activity with promotion pipeline events.
Monitor open-source package telemetry for sudden changes in package size, dependencies, or postinstall behavior on conda-forge.

Monitoring Recommendations

Enable logging on Anaconda channel upload events, including all --force overwrites against cf-staging.
Track installation telemetry from CI systems consuming conda-forge for new or unexpected binaries.
Alert on outbound network connections from build agents that install conda-forge packages immediately after dependency resolution.

How to Mitigate CVE-2025-32784

Immediate Actions Required

Upgrade conda-forge-webservices to version 2025.4.10 or later across all conda-forge infrastructure.
Rotate the cf-staging Anaconda token and audit historical token usage for --force overwrites.
Review recently promoted artifacts on conda-forge and verify their hashes match cf-staging records.

Patch Information

The fix is published in conda-forge-webservices2025.4.10. The patch introduces _comment_on_core_notes_if_bad_copy, which re-checks the artifact hash on the production conda-forge channel after the copy operation. When the post-copy hash does not match, the package is marked as not copied, an error is recorded, and a comment is posted on the conda-forge/core-notes repository for human follow-up. Reference GHSA-28cx-74fp-g2g2 for the full advisory.

Workarounds

Restrict access to the cf-staging token to the minimum set of automation accounts and store it in a hardened secret manager.
Disable artifact overwrites on staging channels where supported, eliminating the race window.
Pin conda-forge package versions and hashes in lockfiles so downstream consumers detect unexpected artifact changes.

bash

# Upgrade conda-forge-webservices to the patched release
pip install --upgrade 'conda-forge-webservices>=2025.4.10'

# Verify the installed version
python -c "import conda_forge_webservices; print(conda_forge_webservices.__version__)"