Bug 2449892

Summary:	pyp2spec: RPM spec injection via unsanitized PyPI package metadata
Product:	[Fedora] Fedora	Reporter:	nick.gould777343
Component:	pyp2spec	Assignee:	Karolina Surma <ksurma>
Status:	CLOSED ERRATA	QA Contact:
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	ksurma, mhroncok
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
URL:	https://github.com/befeleme/pyp2spec
Whiteboard:
Fixed In Version:	pyp2spec-0.14.1-1.fc45 pyp2spec-0.14.1-1.fc42	Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-04-21 13:56:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description nick.gould777343 2026-03-21 00:10:44 UTC

I'd like to responsibly disclose a vulnerability in pyp2spec (https://github.com/befeleme/pyp2spec).

  pyp2spec generates RPM spec files from Python package metadata without escaping RPM directives. A malicious package on PyPI can embed content in its metadata that, when processed by pyp2spec and built
  with rpmbuild, results in arbitrary command execution on the build machine.

  I have a self-contained Docker-based proof of concept that demonstrates the full attack chain. Happy to share it privately through this bug.

  I haven't disclosed this anywhere else.

Reproducible: Always

Steps to Reproduce:
  1. Create a Python package with RPM macro directives embedded in the summary metadata field
  2. Build an sdist and wheel from the package
  3. Run pyp2spec against the local package
  4. Run rpmbuild on the generated spec file
  5. Observe that the embedded directives are evaluated by rpmbuild
Actual Results:
RPM macros in package metadata are written verbatim into the generated spec file and execute during rpmbuild.


Expected Results:
Package metadata containing RPM directives should be escaped before being written to the spec file.


Additional Information:
I have a self-contained Docker-based proof of concept ready to share privately once this report is triaged.

Comment 1 Karolina Surma 2026-03-24 16:54:12 UTC

Hello, thank you for the report. Can you share the PoC through my e-mail: ksurma[at]redhat.com?

Comment 2 nick.gould777343 2026-03-24 17:19:31 UTC

(In reply to Karolina Surma from comment #1)
> Hello, thank you for the report. Can you share the PoC through my e-mail:
> ksurma[at]redhat.com?

Hello Karolina,

Ive sent the poc to your email (as a zip file). There are a few files in there but the short of it is: to run the poc first unzip, then change the permissions on the folder to allow sh files to execute, and finally run ./poc.sh . Please let me know if you have any comments, questions, or concerns.


Thanks,
Nick G.

Comment 3 Fedora Update System 2026-04-21 13:52:13 UTC

FEDORA-2026-9ba2d85db0 (pyp2spec-0.14.1-1.fc45) has been submitted as an update to Fedora 45.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-9ba2d85db0

Comment 4 Fedora Update System 2026-04-21 13:53:49 UTC

FEDORA-2026-91671b8061 (pyp2spec-0.14.1-1.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-91671b8061

Comment 5 Fedora Update System 2026-04-21 13:56:57 UTC

FEDORA-2026-9ba2d85db0 (pyp2spec-0.14.1-1.fc45) has been pushed to the Fedora 45 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 6 nick.gould777343 2026-04-21 16:07:48 UTC

Hey @mhroncok,

Now that this is fixed and shipped I'd like to request a CVE for tracking. The fix landed in pyp2spec-0.14.1-1.fc45 and pyp2spec-0.14.1-1.fc42.

Short recap of the issue: 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. CWE-94 / CWE-78.

One thing worth flagging on impact: 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.

For CVSS I'd suggest AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, which comes out to 8.8 High. I'll leave the final impact rating to yall.

Fix PR: https://github.com/befeleme/pyp2spec/pull/66

I have a Docker-based PoC, Let me know if anyone wants a copy.

Thanks,
Nick G.

Comment 7 nick.gould777343 2026-04-21 16:50:54 UTC

sorry didnt tag correct , tagging correctly now: @mhroncok

Comment 8 Fedora Update System 2026-04-23 02:14:02 UTC

FEDORA-2026-91671b8061 has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-91671b8061`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-91671b8061

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2026-05-01 01:23:00 UTC

FEDORA-2026-91671b8061 (pyp2spec-0.14.1-1.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.