What is the CVSS score of CVE-2026-42301?

CVE-2026-42301 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of pyp2spec are affected by CVE-2026-42301?

pyp2spec versions before 0.14.1 allow arbitrary code execution on RPM packagers' workstations through malicious PyPI package metadata, directly compromising Fedora/RHEL package maintainers and…. A patch is available.

How to fix or mitigate CVE-2026-42301?

Within 24 hours: inventory all systems running pyp2spec, identify version numbers, and restrict network access to PyPI for affected packagers. Within 7 days: upgrade pyp2spec to version 0.14.1 or later on all Fedora/RHEL packaging workstations and validate upgrades via package verification. Within 30 days: audit dist-git SSH key rotation, Koji credential reset, and Bodhi permissions for all potentially compromised packager accounts; review package submission audit logs from the compromise window for any unauthorized uploads.

pyp2spec CVE-2026-42301

HIGH

Improper Input Validation (CWE-20)

2026-05-04 https://github.com/befeleme/pyp2spec

GHSA-r35x-v8p8-xvhw

Information Disclosure

7.8

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.8 HIGH

AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Attack Vector

Local

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 04, 2026 - 21:02 vuln.today

Analysis Generated

May 04, 2026 - 21:02 vuln.today

DescriptionGitHub Advisory

Impact

pyp2spec was writing PyPI package metadata (e.g. the summary field) into the generated spec file without escaping RPM macro directives. When a packager then runs rpmbuild, those directives get evaluated, so a malicious package can execute arbitrary commands on the build machine.

The macro evaluates during spec parsing, not only during the build step. Any rpm tool touching the generated spec triggers execution, rpmbuild -bs, rpmbuild --nobuild, rpm -q --specfile, so the victim doesn't need to commit to a full build before getting compromised. The realistic attack path is typosquatting or targeting a package known to be under Fedora review rather than drive-by publishing. Fedora packagers hold dist-git SSH keys, Koji build credentials, and Bodhi update credentials, so compromise of one packager's workstation enables committing malicious source to dist-git and riding it through the normal build pipeline to end users.

Patches

Patched in 0.14.1.

Workarounds

None

AnalysisAI

Arbitrary code execution on RPM packagers' workstations occurs when pyp2spec generates spec files from malicious PyPI package metadata containing unescaped RPM macro directives. Affects pyp2spec versions prior to 0.14.1, primarily impacting Fedora/RHEL packagers who process untrusted PyPI packages. Attack triggers during spec file parsing (rpmbuild -bs, rpm -q --specfile) before any build step, enabling compromise via typosquatted packages or those under Fedora review. Exploited packager workstations hold dist-git SSH keys, Koji build credentials, and Bodhi update rights, creating supply chain risk. Vendor-released patch 0.14.1 available per GitHub advisory GHSA-r35x-v8p8-xvhw. No public exploit identified at time of analysis, but attack complexity is low with realistic targeting scenarios described.

Technical ContextAI

pyp2spec is a Python tool that converts PyPI package metadata into RPM spec files for packaging Python software in RPM-based distributions like Fedora and RHEL. The vulnerability stems from improper input neutralization (CWE-20) where user-controlled PyPI metadata fields (summary, description, etc.) are written directly into generated spec files without sanitizing RPM macro syntax. RPM macros use %{directive} or %macro format and are evaluated by the RPM parser at spec file load time, not just during build execution. Any RPM tooling that parses the spec file (rpmbuild, rpm, rpmspec) triggers macro expansion, enabling pre-build code execution. The vulnerable component is the spec file generation logic in pyp2spec < 0.14.1, which failed to escape special characters that initiate macro evaluation. The CPE identifier pkg:pip/pyp2spec indicates this is a Python package distributed via PyPI, creating an ironic attack surface where a tool meant to package PyPI software can itself be weaponized through malicious PyPI metadata.

RemediationAI

Upgrade pyp2spec to version 0.14.1 or later, which implements proper escaping of RPM macro directives in PyPI metadata before writing to spec files. Install via pip: 'pip install --upgrade pyp2spec>=0.14.1'. Vendor advisory with patch details at https://github.com/befeleme/pyp2spec/security/advisories/GHSA-r35x-v8p8-xvhw and code fix at https://github.com/advisories/GHSA-r35x-v8p8-xvhw. The advisory explicitly states no workarounds exist for unpatched versions. Compensating controls for organizations unable to immediately patch: restrict pyp2spec usage to isolated build VMs without credentials or network access, manually inspect all generated spec files for RPM macro syntax (%{...} or %macro patterns) before processing with rpmbuild, limit pyp2spec to processing packages from trusted sources only (avoid processing packages under review or from unknown PyPI uploaders), and implement mandatory code review of generated spec files as part of packaging workflow. Trade-offs: manual inspection adds significant overhead to packaging workflows and is error-prone; isolated build VMs prevent credential theft but do not prevent initial compromise; trusted-source-only policies conflict with Fedora's open packaging review process. Organizations maintaining RPM package infrastructure should prioritize this upgrade given the supply chain risk to packager credentials.