/
Navigation
Chronicles
Browse all articles
Explore
Semantic exploration
Research
Entity momentum
Nexus
Correlations & relationships
Story Arc
Topic evolution
Drift Map
Semantic trajectory animation
Posts
Analysis & commentary
Pulse API
Tech news intelligence API
Browse
Entities
Companies, people, products, technologies
Domains
Browse by publication source
Handles
Browse by social media handle
Detection
Concept Search
Semantic similarity search
High Impact Stories
Top coverage by position
Sentiment Analysis
Positive/negative coverage
Anomaly Detection
Unusual coverage patterns
Analysis
Rivalry Report
Compare two entities head-to-head
Semantic Pivots
Narrative discontinuities
Crisis Response
Event recovery patterns
Connected
Search: /
Command: ⌘K
Embeddings: large
TEXXR

Chronicles

The story behind the story

days · browse · Enter similar · o open

Binarly: UEFI Secure Boot is completely compromised on 200+ device models sold by Acer, Dell, Gigabyte, Intel, and Supermicro due to a cryptographic key leak

Keys were labeled “DO NOT TRUST.”  Nearly 500 device models use them anyway.  —  In 2012, an industry-wide coalition of hardware …

Ars Technica Dan Goodin

Context & Ripple Effects

This is the latest in a series of firmware-trust failures rather than an isolated application-security bug. Earlier coverage found an insecure default Secure Boot configuration across hundreds of MSI motherboards, showing that the protection can fail at the policy layer as well as through software vulnerabilities.

The affected vendors also have recent precedent for broad firmware remediation: Gigabyte issued BIOS updates for a firmware backdoor affecting more than 270 motherboard models. The leaked-key report matters because it challenges the cryptographic trust material underlying Secure Boot itself.

First-order effects

  • Devices using the leaked keys lose the signature-verification assurance Secure Boot is meant to provide, affecting systems sold under the Acer, Dell, Gigabyte, Intel, and Supermicro brands.
  • The named vendors and their customers must identify affected models and determine what firmware or key-management remediation is available; the reported exposure spans more models than the 200-plus described as compromised.

Second-order effects

  • Enterprise IT teams will need to treat firmware provenance and Secure Boot status as fleet-management issues, not merely operating-system configuration checks, when assessing affected hardware.
  • PC and motherboard makers face pressure to tighten control and review of signing keys and firmware release processes, particularly after Gigabyte's earlier firmware-update vulnerability affected 271 models.

Third-order effects

  • If repeated firmware failures and key-management lapses persist, hardware security will increasingly be judged on vendors' ability to operate a durable root-of-trust lifecycle—key custody, revocation, updates, and device inventory—not simply on whether Secure Boot is present.
  • The episode reinforces a structural constraint in platform security: a widely reused or mishandled trust credential can turn a nominally distributed hardware market into a correlated risk event across brands and device generations.

The trend: This is one data point in the shift from treating firmware as a static trusted foundation to treating its keys, update channels, and defaults as continuously managed security infrastructure.

Discussion

  • @kennwhite@mastodon.social Kenn White on mastodon
    Protip: When choosing a root-of-trust encryption key for a hardware secure enclave, maybe don't use the vendor's asymmetric key literally labeled “CN=DO NOT TRUST - Test PK”.  New scoop by @dangoodin: Secure Boot is Completely Broken on 200+ Models from 5 Big Device Makers  —  ht…
  • @e__soriano @e__soriano on x
    “we noticed that the private key from American Megatrends International (AMI) related to the Secure Boot “master key”, called Platform Key (PK), was publicly exposed in a data leak (...) devices corresponding to this key are still deployed in the field” https://www.binarly.io/...
  • @binarly_io @binarly_io on x
    🚨New! “PKFail: Untrusted Platform Keys Undermine Secure Boot on UEFI Ecosystem.” #PKfail is a supply-chain issue affecting x86/ARM devices around the globe. Blog: https://www.binarly.io/... Full report: https://22222483.fs1.hubspotusercontent - na1.net/... A free scanning tool: h…
  • @vermaden @vermaden on x
    Secure Boot was introduced by Microsoft not to increase security of anything - but to make installing/using free and open operating systems harder - https://arstechnica.com/... - so I could not care less if its secure or not - first thing I do on my devices is to disable this shi…
  • @agarri_fr Nicolas Grégoire on x
    What a joke! 🤡 https://arstechnica.com/...
  • @nikolajschlej Nikolaj Schlej on x
    Don't want to be a “well, actually” guy here, but the whole UEFI SecureBoot key hierarchy is supposed to be re-generated by the local admin, as trusting whomever (be it the HW vendor with their PK or MS with their KEK) other than yourself is way too dangerous even if convenient.
  • @plumferno Plum on x
    It's that time again, folks! Here's Plum with another super-comforting bit of security industry news 🥰 *cries* https://arstechnica.com/...
  • r/hardware r on reddit
    Secure Boot is completely broken on 200+ models from 5 big device makers
  • r/technology r on reddit
    Secure Boot is completely broken on 200+ models from 5 big device makers |  Keys were labeled “DO NOT TRUST.”  Nearly 500 device models use them anyway