A buffer overflow tracked as CVE-2026-97631 sat in TianoCore EDK II for 16 years. This open source code is used by most of the world's server vendors and data centers, delivered through firmware suppliers like AMI, Insyde, and Phoenix. The practical result is that the flaw affects most servers worldwide.
Firmware myths persist because firmware sits in a gap. Security teams own the operating system and the network. Procurement owns the vendor relationship. Nobody owns the layer that runs before any of those controls load. The myths below fill that gap with comfortable assumptions. Here's where they break.
Myth 1: "Secure Boot protects us from boot-level attacks."
Reality: Secure Boot engages partway through the boot sequence. This flaw is exploitable earlier. An attacker on the local network can send an oversized ICMP error message to a machine while it boots over the network (PXE). If the attacker knows the target's firmware build, they can run code at the highest privilege level before defenses like Secure Boot take effect.
Secure Boot isn't worthless, but you can't cite it as a compensating control for every firmware-layer risk. When documenting your control environment, state which phase of the boot process each control covers. A control you can't place in the sequence is a control you're assuming.
Myth 2: "We're not exposed unless the vendor tells us we are."
Reality: Exposure is conditional, and you have to establish the conditions yourself. In this case, only machines using network boot are exposed. That's useful, but only if you know which of your servers PXE boot. Many organizations can't answer that quickly because boot configuration lives in firmware settings that rarely appear in asset inventories.
Build the inventory now: server models, firmware vendor, firmware version, and whether network boot is enabled. A simple record of those four fields lets you scope the next firmware advisory in an afternoon instead of a week. It also supports the Identify function in the NIST CSF Core Functions, where asset management starts.
Myth 3: "Coordinated disclosure gives us time to prepare."
Reality: Coordinated disclosure gives you time only if it holds. Here, the flaw became public months ahead of a planned January disclosure after AMI published a code fix. Researchers from Anthropic and Google found it, a disclosure schedule was set, and a public fix collapsed the timeline anyway. Organizations were left to seek firmware updates from their vendors with the clock already running.
Plan for the early-exposure case. Your vulnerability process should assume a flaw can go public before your vendor has a packaged update. Have pre-agreed interim steps ready: disabling network boot where it isn't needed, restricting who can reach boot networks, and monitoring for anomalous ICMP traffic on provisioning segments. Interim controls are what you run during the gap between a public fix and a vendor-delivered firmware build.
Myth 4: "Patching firmware is the vendor's job."
Reality: The vendor builds the fix. You own the deployment, testing, downtime window, and evidence that it happened. With this flaw, the supply chain has layers. The vulnerable code sits in an open source project, flows through firmware suppliers, and reaches you through your server manufacturer. A fix has to travel that whole path.
Ask your server vendors three questions, and put the answers in writing:
- Which firmware suppliers and open source components are in your products?
- What is your committed timeline from upstream fix to customer-ready update?
- How do you notify customers when a component-level flaw affects a product line?
Those answers belong in vendor risk reviews and contract renewals. If a supplier can't name its firmware dependencies, that's a finding.
Myth 5: "Our cyber policy will respond if firmware is exploited."
Reality: Maybe, but don't assume it. Underwriters increasingly ask about patch management on the Underwriting Questionnaire, and your answers carry weight. If you attest to timely patching of critical vulnerabilities and a known, vendor-fixed firmware flaw sits unaddressed for months, you've created a gap between your representation and your practice. That gap is where an Application Fraud Warranty dispute or a contested claim can start.
Read your policy for how it treats known-but-unpatched vulnerabilities. Check whether Business Interruption Coverage is triggered by a system failure that results from a security event. Confirm whether Contingent Business Interruption Coverage applies if a vendor's compromised or bricked systems disrupt you. Speak with your broker before renewal, not after an incident.
What to Do Instead
Replace the assumptions with a short, repeatable routine:
- Inventory the firmware layer. Record vendor, version, and boot configuration for every server class.
- Define interim controls in advance. Know which settings you'd change within 24 hours of a public firmware flaw, and who can approve the change.
- Add firmware to vendor governance. Require disclosure of upstream components and update commitments.
- Align your attestations with your practice. What you tell underwriters about patching should match what your records show.
- Test the response. Run a tabletop where a critical firmware flaw goes public before a vendor patch exists. The decisions that stall in the exercise are the ones that would stall in production.
The lesson of a 16-year-old flaw isn't that firmware is uniquely dangerous. It's that the layers you don't inventory are the layers you can't defend, and the timelines you assume are the first things to break.
