pengutronix CVE Vulnerabilities & Metrics

Focus on pengutronix vulnerabilities and metrics.

Last updated: 29 Mar 2026, 22:25 UTC

About pengutronix Security Exposure

This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with pengutronix. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.

For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.

Global CVE Overview

Total pengutronix CVEs: 7
Earliest CVE date: 05 Sep 2019, 15:15 UTC
Latest CVE date: 20 Mar 2026, 23:16 UTC

Latest CVE reference: CVE-2026-33243

Rolling Stats

30-day Count (Rolling): 1
365-day Count (Rolling): 1

Calendar-based Variation

Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.

Variations & Growth

Month Variation (Calendar): 0%
Year Variation (Calendar): 0%

Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): 0.0%

Monthly CVE Trends (current vs previous Year)

Annual CVE Trends (Last 20 Years)

Critical pengutronix CVEs (CVSS ≥ 9) Over 20 Years

CVSS Stats

Average CVSS: 5.5

Max CVSS: 7.5

Critical CVEs (≥9): 0

CVSS Range vs. Count

Range Count
0.0-3.9 1
4.0-6.9 3
7.0-8.9 3
9.0-10.0 0

CVSS Distribution Chart

Top 5 Highest CVSS pengutronix CVEs

These are the five CVEs with the highest CVSS scores for pengutronix, sorted by severity first and recency.

All CVEs for pengutronix

CVE-2026-33243 pengutronix vulnerability CVSS: 0 20 Mar 2026, 23:16 UTC

barebox is a bootloader. In barebox from version 2016.03.0 to before version 2025.09.3 and from version 2025.10.0 to before version 2026.03.1, when creating a FIT, mkimage(1) sets the hashed-nodes property of the FIT signature node to list which nodes of the FIT were hashed as part of the signing process as these will need to be verified later on by the bootloader. However, hashed-nodes itself is not part of the hash and can therefore be modified by an attacker to trick the bootloader into booting different images than those that have been verified. This issue has been patched in barebox versions 2025.09.3 and 2026.03.1.

CVE-2021-37848 pengutronix vulnerability CVSS: 5.0 02 Aug 2021, 20:15 UTC

common/password.c in Pengutronix barebox through 2021.07.0 leaks timing information because strncmp is used during hash comparison.

CVE-2021-37847 pengutronix vulnerability CVSS: 5.0 02 Aug 2021, 20:15 UTC

crypto/digest.c in Pengutronix barebox through 2021.07.0 leaks timing information because memcmp is used during digest verification.

CVE-2020-25860 pengutronix vulnerability CVSS: 7.1 21 Dec 2020, 18:15 UTC

The install.c module in the Pengutronix RAUC update client prior to version 1.5 has a Time-of-Check Time-of-Use vulnerability, where signature verification on an update file takes place before the file is reopened for installation. An attacker who can modify the update file just before it is reopened can install arbitrary code on the device.

CVE-2020-13910 pengutronix vulnerability CVSS: 6.4 07 Jun 2020, 20:15 UTC

Pengutronix Barebox through v2020.05.0 has an out-of-bounds read in nfs_read_reply in net/nfs.c because a field of an incoming network packet is directly used as a length field without any bounds check.

CVE-2019-15938 pengutronix vulnerability CVSS: 7.5 05 Sep 2019, 15:15 UTC

Pengutronix barebox through 2019.08.1 has a remote buffer overflow in nfs_readlink_req in fs/nfs.c because a length field is directly used for a memcpy.

CVE-2019-15937 pengutronix vulnerability CVSS: 7.5 05 Sep 2019, 15:15 UTC

Pengutronix barebox through 2019.08.1 has a remote buffer overflow in nfs_readlink_reply in net/nfs.c because a length field is directly used for a memcpy.