CVE-2023-6395 is a medium severity privilege escalation in Mock, the RPM build tool. Jinja2 templates in some configuration parameters are expanded without sandboxing, which may let a less privileged build user run code as root on the build server. Apply the update from your distribution.
What's affected
- Product: Mock from rpm-software-management, as shipped in Fedora and EPEL 7, 8 and 9 according to the record.
- Affected: the record gives no version range for Mock.
- Fix: the record references commits in the templated-dictionary project. Confirm fixed package versions in the Red Hat and Fedora advisories.
- Precondition: a build system that calls mock on behalf of users and lets them set configuration tags.
The record gives a CVSS 3.1 base score of 6.7 (medium) with the vector CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. The CISA Known Exploited Vulnerabilities flag in the record is false. This post does not claim exploitation in the wild.
How to check if you're exposed
Check the installed Mock version and whether your build system lets users influence Mock configuration.
rpm -q mock
rpm -q python3-templated-dictionary
rpm -q --changelog mock | grep -i CVE-2023-6395
Then review how your build service passes user supplied values to mock. The Mock documentation, as quoted in the record, says members of the mock group are privileged. The risk appears when a service lets lower privileged users set tags that reach mock.
What to do now
- List build servers that run Mock, including CI runners and shared build farms.
- Update Mock and its templating dependency to the version your distribution lists for CVE-2023-6395.
- Audit any service that calls mock for users, and stop it from passing user controlled configuration tags through.
- Keep the mock group limited to people you would trust with root on the build host.
- Run the free in-browser dependency scan at gold.safeguard.sh/scan on any project you build that bundles this component, and keep the result next to your inventory.
Why it matters
The record maps this issue to CWE-20 (Improper Input Validation): The software accepts input without checking that it has the properties the code expects, so later logic works on data it was never meant to handle. ; CWE-94 (Code Injection): Input is treated as code or template content and evaluated, so the author of the input can influence what the program executes.
The record lists improper input validation and code injection. Jinja2 is a templating language that can reach Python features when it is not run in a sandbox. If a value from a lower privileged user is expanded as a template, the template author is effectively running code in the process that expands it, and here that process has root rights.
The score is medium because it needs high privileges in the base vector. The real exposure depends on your wrapper. A shared build service that forwards user settings can turn a documented privileged tool into a path from low access to root on the builder, and build hosts often hold signing keys and credentials.
Try it yourself
This demo shows a pull request gate, one way to stop unreviewed configuration or dependency changes from reaching a build system.
Click through it at your own pace, or open it full screen.
Quick check
Is Mock safe if only I use it?
The record frames the risk around build systems that call mock for other users. If only trusted administrators supply configuration, the exposure is much smaller.
Where are the fixes?
The record links commits in the templated-dictionary project and Red Hat tracking pages. Confirm package versions there.
Sources
These are the references listed in the NVD record for this CVE. They were not fetched when this post was written, so confirm fixed versions in the advisory before acting.
- www.openwall.com
- www.openwall.com
- access.redhat.com
- bugzilla.redhat.com
- github.com
- github.com
- Gold entry for CVE-2023-6395
Last reviewed: 19 October 2026.
