spaCy wheels bundle vulnerable version of black (CVE‑2026‑32274)

[NemoLeerink]

black==22.3.0 is bundled inside the spaCy wheel and cannot be upgraded or overridden by downstream projects. There is a CVE affecting black versions prior to the fixed release, specifically CVE‑2026‑32274. Because the vulnerable version is embedded inside the wheel rather than installed as a standalone dependency, consumers cannot mitigate or replace it in their own projects.

Impact

Even though this is not a run‑time vulnerability in typical spaCy usage (the black code is not invoked at runtime unless explicitly imported), it still appears in automated security scans that are standard within enterprise environments. This leads to:

• Critical vulnerabilities flagged in tools like Nexus/Wiz,
• Mandatory internal processes for vulnerability handling,
• No viable remediation path for consuming teams, because the black version is not under their control.

To avoid cascading false‑positive security failures across downstream users, it would be helpful if spaCy could update or remove the bundled version.

Request

Please evaluate what it would take to either:

Upgrade the bundled black version inside the wheel to a non‑vulnerable release (fixed in latest, 26.3.1) ,
or
Remove the vendorized black package from the wheel if it is no longer required.

This would allow enterprise consumers to clear CVE findings and avoid unnecessary exceptions/waivers.

How to reproduce the behaviour

In our environment we use Nexus IQ for scanning, but the issue can be reproduced manually:

• Install spaCy from PyPI
• Inspect the installed wheel contents
• You will see black==22.3.0 bundled inside the wheel, triggering the CVE detection.

Your Environment

Operating System: not relevant (Linux-based, but occurs on all platforms)
Python Version: not relevant (reproduced on 3.8 / 3.9 / 3.10)
spaCy Version: not relevant (affects current master)
Environment: building Docker images on Linux and Windows hosts

Please reach out if anything is unclear. Many many thanks in advance!

[rikjansen-hu]

The bigger issue seems to be that tests are included in the wheel, which goes against packaging best practices.

Suggested solution: exclude them in package finder (in pyproject.toml:

[options.packages.find]
exclude =
    spacy.tests*

[honnibal]

What do you mean by "bundled inside the wheel"?

[NemoLeerink]

Hi @honnibal,

The spacy/tests/ directory is included in every published .whl on PyPI, across all Python versions, operating systems, and architectures. Within that directory, spacy/tests/package/requirements.txt lists black==22.3.0. Security scanners like Nexus IQ inspect the full contents of .whl files, including nested requirements.txt files, and flag this as a vulnerable component (CVE-2026-32274).

For example, the cp310-cp310-macosx_10_9_universal2 wheel triggers the finding, and the same applies to every other platform wheel published for the same spaCy version.

There are two complementary fixes:

• Upgrade black to a non-vulnerable release (≥26.3.1) to directly resolve CVE-2026-32274.
• Exclude spacy/tests/ from all wheels at build time. This is packaging best practice and the more durable fix. Including test files in published wheels exposes downstream consumers to vulnerabilities in test-only dependencies. Removing spacy/tests/ prevents this class of issue from recurring in the future.

I agree with @rikjansen-hu that both changes are worth making together, as the second removes the root cause rather than just patching the current symptom.

[honnibal]

Okay I understand now. The scan is a misclassification: we happen to have a file named requirements.txt inside our tests, these are not the package requirements and are not installed anywhere.

I'll fix it because it's indeed annoying to have the misclassification on vulnerability scanners, thanks. I'll rename that file so it doesn't trigger the scanner, but we do need to run tests on our built artifacts in our CI currently

[NemoLeerink]

Thanks for the quick response and the proposed fix. Much appreciated!