SECURITY PRACTICES & DOMAINS AI Security AI Infrastructure’s Firmware Problem Is Bigger Than Any Single Vendor By Cybersecurity Insiders - [ Join Cybersecurity Insiders ] September 2, 2026 The rapid construction of AI infrastructure is creating new security challenges across the hardware and software stack, from inference servers and telemetry tools to network adapters, management controllers and trusted platform modules. An analysis published in the August edition of Eclypsium ‘s InfraTrust Pulse found that vulnerabilities affecting AI environments are appearing across multiple layers and reaching customers through a fragmented chain of chipmakers, equipment manufacturers and software suppliers. The report examined 118 new infrastructure security advisories published by 12 vendors between July 18 and August 24. Together, those advisories covered 1,051 vulnerabilities. A further 74 previously published advisories were revised during the period. For organizations building GPU clusters and other high-performance computing environments, the findings suggest that tracking advisories from a single technology provider is unlikely to provide a complete picture of their exposure. Vulnerabilities Span the AI Stack Nvidia published several advisories affecting products that sit above the hardware layer. The company’s Triton Inference Server was the subject of two bulletins, including an August 18 advisory rated 9.8 that covered five vulnerabilities. Nvidia Dynamo received another 9.8-rated bulletin covering 15 vulnerabilities, while advisories also addressed weaknesses in DCGM Exporter, Cumulus Linux and NVOS. These products perform different functions within AI environments. Triton supports the serving of AI models, Dynamo helps manage distributed inference workloads and DCGM Exporter collects GPU telemetry. Vulnerabilities in these components can therefore affect the services and monitoring systems positioned directly in front of expensive accelerator infrastructure. Security issues were also identified further down the stack in Nvidia BlueField data processing units and ConnectX network adapters. Relevant fixes reached customers through at least three separate channels: Nvidia, Dell and Lenovo. That distribution model creates a practical problem for defenders. The original component manufacturer may disclose a vulnerability before server manufacturers have firmware ready for their own systems. Conversely, organizations monitoring only their equipment manufacturer may not learn about the underlying issue until a product-specific update is released. Businesses operating the same components across hardware from multiple vendors must also track each supplier separately. Updating BlueField firmware in Dell servers, for example, does not address affected components housed in Lenovo systems. A Wave of Firmware Advisories The scale of this dependency problem became particularly visible on August 11, when vendors published 38 firmware advisories in a single day — roughly one-third of the month’s total. Many were equipment manufacturers redistributing fixes for shared upstream components. The advisories included vulnerabilities affecting Intel wireless products, chipset firmware and neural processing unit drivers, as well as collections of BIOS updates from Dell and Lenovo. AMD also disclosed two vulnerabilities in Trusted Platform Module reference code. Lenovo subsequently released separate advisories addressing the issue in firmware-based and discrete TPM products. Reference code is intended to provide a common foundation that multiple manufacturers can use in their own products. A vulnerability in that code can consequently spread across a large number of devices and implementations, requiring each vendor to develop, validate and distribute its own update. This pattern makes it difficult to treat firmware vulnerabilities as isolated product defects. A single upstream flaw can reappear across laptops, servers, networking equipment and other appliances under different advisory numbers and on different release schedules. Old Vulnerabilities Keep Reappearing Dell’s advisories illustrate how inherited vulnerabilities can resurface across apparently unrelated products. One Dell Networking OS10 update covered 435 CVEs, including CVE-2026-31431, a Linux kernel privilege-escalation vulnerability that had already appeared in an earlier Dell advisory. The same vulnerability later appeared in a third advisory for Dell Metro Node. Other Dell security rollups contained vulnerabilities originally associated with Chromium’s V8 JavaScript engine. One of those advisories applied to Dell ThinOS, while another affected the company’s PowerVault ME5 storage systems. The presence of a browser-engine vulnerability in a storage product underscores how difficult it can be for customers to understand the components embedded inside an appliance. Products marketed as purpose-built hardware may still contain operating systems, web interfaces, open-source packages and third-party libraries that introduce vulnerabilities from elsewhere in the software ecosystem. Large rollup advisories can also make prioritization more difficult. A bulletin containing hundreds of vulnerabilities may carry a high or critical headline score without clearly communicating which flaws are relevant to a particular deployment or remotely reachable in its default configuration. Quiet Revisions Create a Visibility Gap Newly published advisories represent only part of the workload. Of the 191 advisories that InfraTrust recorded as new or updated during the reporting period, 74, approximately 39%, were revisions to existing documents. Lenovo accounted for 38 revisions, followed by Dell with 23 and HP with nine. Cisco, HPE and F5 also revised previously issued advisories. These changes can be operationally significant. A vendor may add newly identified affected models, publish a corrected severity rating, provide an updated fixed version or release new instructions for checking whether a system was compromised. Cisco’s advisory for a critical Secure Firewall Management Center authentication bypass provides one example. The vulnerability itself was disclosed months earlier, but Cisco revised its guidance in August to include updated hotfix information and clarified compromise-detection procedures. A vulnerability management process that collects advisories only on their original publication date could miss those changes entirely. Lenovo also revised numerous multi-vendor BIOS advisories dating back to February 2025 as the company continued identifying affected models across its product line. In such cases, the advisory functions as a living document rather than a fixed disclosure. Infrastructure Security Requires Component-Level Tracking The findings point to a growing need for organizations to maintain a detailed inventory of the components inside their infrastructure, not simply a list of finished products. That inventory should account for accelerators, network adapters, DPUs, firmware, BIOS versions, management controllers, embedded software and upstream libraries. Security teams must then monitor both the original component supplier and the equipment manufacturers responsible for distributing installable updates. Processes should also track when an advisory was last modified, alongside its original publication date. Without that capability, organizations may overlook newly affected systems or updated remediation guidance even when they have already recorded the underlying CVE. As investment in AI infrastructure accelerates, longstanding firmware and supply-chain weaknesses are being replicated inside a new generation of high-value systems. The processors may be new, but the challenge remains familiar: Defenders cannot patch what they cannot accurately identify and track. Join our LinkedIn group Information Security Community! Facebook X WhatsApp Linkedin Cybersecurity Insiders RELATED ARTICLES MORE FROM AUTHOR AI Security HackerOne Adds OpenAI Cyber Models to Code Security and Remediation Tools AI Security The Exhausting Paradox of AI Security AI Security Beyond Phishing: How AI is Advancing Enterprise Payment Fraud No posts to display
The article describes a systemic vulnerability management challenge rather than a single CVE, where AI infrastructure security is fragmented across chipmakers, OEMs, and software vendors, creating exposure gaps. For example, firmware vulnerabilities in components like Nvidia BlueField DPUs require tracking separate advisories and patches from multiple hardware vendors (e.g., Dell, Lenovo) for the same underlying issue. This necessitates that security teams monitor advisories across the entire supply chain, as relying on a single technology provider's bulletins does not provide a complete view of the threat landscape.