Skip to content

CVE-2025-47827

In IGEL OS before 11, Secure Boot can be bypassed because the igel-flash-driver module improperly verifies a cryptographic signature.

Medium Known exploited
Severity
4.6 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
5.15%
Chance of exploitation in the next 30 days. Higher than 92.43% of scored vulnerabilities.
Known exploited
Yes
In CISA's catalog since Oct 14, 2025
Weakness
CWE-347 Improper Verification of Cryptographic Signature
Fix
None yet
No fixed version published
Exploited in the wild. IGEL OS Use of a Key Past its Expiration Date Vulnerability (IGEL IGEL OS). Required action: Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. Due for U.S. federal agencies by Nov 4, 2025.

Description

In IGEL OS before 11, Secure Boot can be bypassed because the igel-flash-driver module improperly verifies a cryptographic signature. Ultimately, a crafted root filesystem can be mounted from an unverified SquashFS image.

How to fix

No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.

Severity breakdown

CVSS 3.1 4.6

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

Attack vector
Physical
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-347: Improper Verification of Cryptographic Signature

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

References

Timeline

  1. Published
  2. Added to CISA's Known Exploited Vulnerabilities catalog
  3. Remediation due for U.S. federal agencies
  4. Last updated by the source
  5. Latest EPSS score
AdvisorySeverityWhy it's related
EEF-CVE-2026-65632
ECDSA signature length is not validated in jose, allowing signature malleability
Not rated yet Same weakness, CWE-347
GHSA-pxh4-856f-4h89
PyJWT: HS256/384/512 verify accepts empty HMAC key via oct JWK (PyJWK/PyJWKClient) enabling token forgery
High Same weakness, CWE-347
GHSA-j7h2-66j4-ghjf
A russh SSH server accepts a publickey authentication whose signature uses a different algorithm than the one named in the request
Low Same weakness, CWE-347
GHSA-w2cx-738m-mc7w
PyJWT accepts public JWK containers as HMAC secrets
High Same weakness, CWE-347
GHSA-r6x4-923q-g947
PyJWT BOM Bypass
High Same weakness, CWE-347
GHSA-p4g4-x82p-q773
PyJWT: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard
High Same weakness, CWE-347
GHSA-ffc3-869f-jxw9
PyJWT: Asymmetric-PEM detection bypass: whitespace/line-ending-mutated public keys skip the HS/asymmetric confusion guard
Critical Same weakness, CWE-347
GHSA-9j54-fg26-wv3r
PyJWT: PyJWK accepts empty HMAC keys, bypassing PyJWT's empty-key validation
Critical Same weakness, CWE-347
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor