Rpm Software Management
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in any Rpm Software Management product.
RSS Feeds for Rpm Software Management security vulnerabilities
Create a CVE RSS feed including security vulnerabilities found in Rpm Software Management products with stack.watch. Just hit watch, then grab your custom RSS feed url.
Products by Rpm Software Management Sorted by Most Security Vulnerabilities since 2018
By the Year
In 2026 there have been 0 vulnerabilities in Rpm Software Management. Rpm Software Management did not have any published security vulnerabilities last year.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 0 | 0.00 |
| 2025 | 0 | 0.00 |
| 2024 | 2 | 9.80 |
It may take a day or so for new Rpm Software Management vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Rpm Software Management Security Vulnerabilities
| CVE | Date | Vulnerability | Products |
|---|---|---|---|
| CVE-2024-1930 | May 08, 2024 |
dnf5daemon-server: No Max Open Sessions Before 5.1.17No Limit on Number of Open Sessions / Bad Session Close Behaviour in dnf5daemon-server before 5.1.17 allows a malicious user to impact Availability via No Limit on Number of Open Sessions. There is no limit on how many sessions D-Bus clients may create using the `open_session()` D-Bus method. For each session a thread is created in dnf5daemon-server. This spends a couple of hundred megabytes of memory in the process. Further connections will become impossible, likely because no more threads can be spawned by the D-Bus service. |
Dnf5
|
| CVE-2023-6395 | Jan 16, 2024 |
Mock Build System (Red Hat) Privilege Escalation via Jinja2 TemplatesThe Mock software contains a vulnerability wherein an attacker could potentially exploit privilege escalation, enabling the execution of arbitrary code with root user privileges. This weakness stems from the absence of proper sandboxing during the expansion and execution of Jinja2 templates, which may be included in certain configuration parameters. While the Mock documentation advises treating users added to the mock group as privileged, certain build systems invoking mock on behalf of users might inadvertently permit less privileged users to define configuration tags. These tags could then be passed as parameters to mock during execution, potentially leading to the utilization of Jinja2 templates for remote privilege escalation and the execution of arbitrary code as the root user on the build server. |
Mock
|