CVE-2017-5715 (Spectre Variant 2)
CVE-2017-5715 is a Central Processing Unit (CPU)-level vulnerability commonly found in multi-tenant cloud environments and shared hosting infrastructure. These are the kind of environments run by SaaS providers, MSPs, and the third-party platforms that even non-technical vendors depend on.
While Spectre Variant 2 is a speculative execution flaw that requires local access and does not directly enable code execution, it remains relevant because it can expose sensitive data such as credentials (PII), cryptographic material, or API tokens under the right conditions. In shared hardware environments, this includes scenarios where a malicious or compromised co-tenant is able to observe data belonging to other workloads running on the same physical infrastructure.
This enables downstream supply chain risk for the hosting vendor’s customers—and potentially their customers’ customers—by exposing sensitive data used to access other environments. TPRM leaders anxious to address the risks around Spectre may want to ask critical vendors whether they’ve enabled CPU-level mitigations, or whether sensitive workloads are isolated to dedicated resources. If a critical vendor isn’t a hosting provider, it may be worth asking whether their hosting providers apply comparable controls.
In this analysis, CVE-2017-5715 ranks as a ‘top’ vulnerability not because it is new or easy to exploit in isolation, but because it continues to surface at scale in threat intelligence sources associated with third-party vendors. Its persistent appearance reflects how widely the underlying condition still exists across hosting environments and how attractive it remains as a supporting technique in broader supply chain and post-compromise attack chains.
For TPRM leaders: The risk is less about Spectre as a standalone exploit and more about environmental exposure. Organizations may want to ask critical vendors whether CPU-level mitigations are enabled, whether sensitive workloads are isolated to dedicated hardware, and how hosting providers reduce the risk of cross-tenant data exposure.
CVE-2018-3615 (Foreshadow)
CVE-2018-3615 is another CPU-level vulnerability that can pose elevated risk in multi-tenant environments, particularly where hardware-based secure enclaves are used. This CVE targets enclave technologies designed to create protected execution spaces intended to keep sensitive data confidential even if other parts of the system are compromised. Some vendors rely on enclave-backed services to assure customers that cryptographic material, analytics data, or key-management secrets remain inaccessible to both attackers and the service operator itself.
Foreshadow undermines those assurances. While exploiting this vulnerability requires prior local access to the system, it can allow attackers to extract secrets from enclaves that were explicitly designed to prevent such exposure. This can include cryptographic keys, credentials, or sensitive customer data processed within the enclave.
For TPRM leaders: The concern is not Foreshadow as an initial access vector, but its ability to significantly worsen the impact of an existing compromise in shared or multi-tenant environments. Organizations whose critical vendors promote hardware-based confidential computing may want to confirm whether mitigations have been applied and whether enclave usage is limited to environments where underlying access controls and isolation are rigorously enforced.
CVE-1999-0024 (DNS Cache Poisoning)
CVE-1999-0024 is over two decades old, and yet the attackers are still exploiting this vulnerability due to missed patching. It’s a DNS cache poisoning flaw that when exploited makes it possible to inject forged responses into a DNS resolver’s cache, silently redirecting anyone who relies on that resolver to infrastructure controlled by the attacker. DNS cache poisoning in general is a potent and prevalent third-party attack vector.
Recent studies show that 15% of open DNS resolvers are susceptible to these types of flaws. In the hands of a supply chain attacker it is a tool that quickly scales operations. A single poisoned resolver at an ISP, hosting provider, or other vendor could redirect traffic for thousands of downstream users simultaneously. Attackers can use it to harvest credentials through fake login portals or even to serve malicious software updates to multiple organizations at once.
For TPRM leaders: Given the prevalence of this attack vector, TPRM leaders may want to ask vendors whose systems connect directly into their environments who provides their DNS resolution and what protections are in place against cache poisoning.
CVE-2017-0161 (NetBIOS Remote Code Execution)
This is a Windows networking flaw that gives attackers free reign to execute code on vulnerable systems without authentication. Like all of these frequently targeted flaws, this is another old one, this time afflicting a legacy protocol that’s often enabled by default and overlooked on internal network segments, especially in older Windows environments. This makes CVE-2017-0161 particularly dangerous in vendor environments with flat networks or weak segmentation. This could include vendors for whom IT isn’t core to the business and where security modernization is limited, and yet who have systems that connect to their customers. Think call centers, legal or accounting firms, benefits administrators, healthcare vendors and so on.
Threat actors that use this to scale attacks can gain a foothold in a vendor network and then scan for systems with NetBIOS exposed so they can exploit the flaw to take over jump hosts, support workstations, or management servers. These are the types of systems that store VPN credentials and remote management tools with direct access into customer environments. One compromised jump host could be just the bridge attackers need to get into many customer environs.
For TPRM leaders: The frequent targeting of this flaw is why TPRM programs should be checking on how vendors segment internal networks to limit lateral movement. It may also be worth specifically checking whether critical vendors are disabling NetBIOS on systems that handle customer access.
CVE-2017-8517 (Browser Memory Corruption)
This is a browser-based remote code execution flaw that attackers can trigger just by luring a user to a malicious or compromised webpage. Once exploited, the attacker’s code runs with all the privileges of a logged-in user, potentially including access to SSO cookies, VPN credentials, saved passwords, and any internal web apps open in that browser session.
Many vendors browse web-based customer admin panels, support portals, and remote management consoles as part of their daily work, making this flaw a handy one for kicking off a supply chain attack. Exploiting it could give attackers everything they need to access customer environments using the vendor’s own legitimate credentials and tools.
For TPRM leaders: While patches have been available since 2017, vulnerable browsers persist at lower-maturity vendors. Its use by threat actors signals the importance of TPRM programs checking into browser patching policies for vendor employees who access customer environments.
Lessons for TPRM leaders
On first blush, these CVEs may look like a random assortment of flaws. But if you look at them closely with an attacker’s mindset, it becomes clear that there’s a unifying thread woven throughout. Exploiting these flaws targets shared infrastructure, trust boundaries, and systems that sit at the intersection of supply chain connections.
As TPRM leaders mull over the attack patterns, some important lessons come to mind.
- Vulnerabilities in shared infrastructure creates cascading risk: Attackers target vulnerabilities that compromise trust boundaries and shared services at vendors so they can gain reach across the supply chain. This means TPRM programs need to think beyond whether or not a vendor could be breached and instead begin to delve into how much of the organization becomes accessible if the vendor is breached. Third-party risk managers may even want to consider segmenting critical vendors based on ‘blast radius’ should a compromise occur. This can help prioritize vendors operating DNS, VPN, remote access, or multi-tenant hosting infrastructure that taps into customer systems.
- Old vulnerabilities remain relevant, especially at less tech-savvy vendors: The vulnerabilities that attackers use to target third parties aren’t cutting-edge zero-days. They’d just as soon pick the five-, 10-, or even 20-year-old flaws that work just as well in vendor environments that let unpatched, legacy systems linger. The fact that none of the top flaws used to target vendors are less than eight years old serves as testament to that. These older flaws are especially relevant in non-tech vendors who still interface heavily with your tech systems. HVAC suppliers, logistic providers, and outsourcing firms may not always have dedicated security teams that root out and eliminate ancient vulns. But these problems become yours without mitigations in place to reduce the risks around them.
- Continuous monitoring picks up on exposures that questionnaires miss: Traditional TPRM relies heavily on questionnaires and point-in-time assessments that aren’t very accurate or specific. Vendors are going to tell you they absolutely do patch within 30 days but they may be forgetting about some key systems. Continuous monitoring of vendor-facing infrastructure can reveal what questionnaires can’t, including outdated browser versions on remote access systems, unsupported operating systems on externally-facing assets, or DNS configurations vulnerable to cache poisoning. This can help prioritize remediation conversation around concrete exposures rather than broader policy compliance.
- Threat intelligence can drive more targeted TPRM action: Only a fraction of the vulnerabilities and misconfigurations present in any given system are actually used by the attackers. The trick is knowing which one of these flaws are the ones being targeted. Cyber threat intelligence can offer crucial context about which flaws are being used against your vendors and how. Not only can this help to advise your entire portfolio of especially risky exposures they should tend to, it can also potentially be used to prioritize which vendors matter most to your risk profile during a given threat cycle. In this way cyber threat intelligence can be used to help TPRM programs mature prioritization methods beyond spend and criticality and start laying in evidence of targeted campaigns relevant to their portfolio.
This top five list should be an invitation to start moving toward threat-informed vendor management. By combining continuous monitoring with cyber threat intelligence, organizations can better pinpoint the exposures that matter most to their supply chains. One of the first ways to start may be to engage with critical vendors in joint risk reviews where you walk through specific attack paths together. The goal shouldn’t be to audit vendors into submission. Rather it should be to start collaborative discussions that target the riskiest threats to them and you.
