Vulnerabilities: Everything You’ve Wanted To Know

(Day 5 of 22 in our Cybersecurity Awareness Month series. Today: vulnerabilities)

AI is a force multiplier. Good folks use it to do their work faster and with more accuracy. Bad actors use it to… do their work faster and with more accuracy, too. One thing that AI definitely does faster is find vulnerabilities in software. AI models are very good at detecting vulnerabilities, developing exploits, and chaining them together. This is manifesting as an explosion of CVEs and patches, which is stressful for organizations and their change control processes.

The thing to remember amongst all this is that it’s very possible the bad actors already knew about some of these issues. Threat actors get to see everything defenders do, but we don’t get to see what they know. And if it’s true that they knew about some of these issues, it behooves us to do something about it, to deny them the ability to attack us all in these ways.

The big issue, though, isn’t really about vulnerabilities. It’s that many organizations have trouble assessing and mitigating security risk, and all of this hullabaloo isn’t helping. To start, the traditional measurements of risk, like CVSS score, aren’t enough on their own anymore. AI can chain vulnerabilities together, using multiple low- and moderate-severity vulnerabilities to achieve the same effect as one critical issue. And, in this regard, it’s very hard to tell what will be important to an AI. As a result, organizations that pick and choose what to update based solely on criticality are being caught off guard, especially if they’ve been biased towards only patching higher-severity issues.

The other plot twist is also related to attackers being able to see everything defenders do. Software vendors everywhere are using AI to examine their own code, which is a good thing. But every detail a vendor publishes about a security improvement is also a hint to bad actors about where to look. That is a hard balance to strike, and it is one reason release notes across the industry can be short on detail. Organizations that haven’t yet surrendered to the idea that they need to patch everything, all the time, can find that frustrating.

Over the next few posts we’ll talk about this more, because there are a lot of tools inside VMware Cloud Foundation (VCF) that help mitigate these risks. But first let’s take a step back and talk more about vulnerability basics.

Vocabulary of Vulnerabilities

Information security staff use specific terminology when talking about vulnerabilities, because being precise is helpful.

Vulnerability: A flaw in software, hardware, or configuration that someone can use to do something they shouldn’t be able to do. Not every bug is a vulnerability, and not every vulnerability can be reached in your environment. Both of those ideas matter, a lot.

CVE: Common Vulnerabilities and Exposures. This is an ID, like CVE-2026-12345, that lets everyone talk about the same flaw without confusion. A CVE is a name. It says nothing about how bad the flaw is, and the CVE program issues tens of thousands of them every year. It is also worth noting that not all vulnerabilities are assigned CVE numbers, either.

CVSS: The Common Vulnerability Scoring System, maintained by FIRST, the Forum of Incident Response and Security Teams. It produces a score from 0 to 10 and a “vector,” a compact string that describes how an attack would work. Does the attacker need to be on the network or on the machine? Do they need privileges already? Does a person have to click something? Put frankly, the vector is usually more useful than the number, especially nowadays.

Severity: The word that goes with the CVSS number. Our advisories use Critical (CVSS 9.0 to 10.0), Important (7.0 to 8.9), Moderate (4.0 to 6.9), and Low (0.1 to 3.9). Other organizations might say “High” and “Medium” where we say Important and Moderate, but the ranges are the same.

VMSA: A VMware Security Advisory, which is how we tell you about vulnerabilities in our products. Each one lists the affected products and versions, the CVEs and their scores, the versions that contain the fix, and any workarounds. You can find them on the Broadcom Support Portal at:

https://www.broadcom.com/support/vmware-security-advisories

Exploit: Code or a technique that takes advantage of a vulnerability. A “proof of concept” shows that it can be done. A working exploit in the hands of attackers is a different and more urgent thing.

Chaining: Using several vulnerabilities together, where each one gets the attacker a step closer to the goal. A chain of small flaws can do as much damage as one big one.

Zero-day: A vulnerability that has no patch available when it is disclosed. The name comes from how many days the defenders have had to prepare. The term gets overused. If a patch was available when the flaw was disclosed, it was not a zero-day, no matter how bad the breach that followed. Log4Shell was a real zero-day. EternalBlue was not, because the patch had been out for two months before the WannaCry ransomware started using it.

Negative-day: A vulnerability that attackers are exploiting before defenders know it exists, so the clock is already below zero when it is disclosed. People also use the term for a flaw whose fix shows up in public code before the advisory does, which lets an attacker work out the flaw from the fix. AI makes both easier for attackers.

KEV: The Known Exploited Vulnerabilities catalog, kept by the US Cybersecurity and Infrastructure Security Agency, or CISA. If a CVE is on this list, someone has confirmed that attackers are using it.

EPSS: The Exploit Prediction Scoring System, also from FIRST. It estimates the probability that a vulnerability will be exploited in the next 30 days. KEV tells you what is happening, and EPSS is an educated guess about what will.

Workaround: A change you can make to reduce or remove the risk without installing the fix, such as disabling a feature or blocking a port.

Coordinated disclosure: The practice of keeping the details of a vulnerability private until a fix is ready, then publishing both together. This is why you usually hear about a vulnerability and its patch on the same day. The alternative is full disclosure, where someone publishes the details right away, fix or no fix.

Severity Is Not Risk

A CVSS score describes the vulnerability in general, assuming the worst reasonable case. It knows nothing about your environment. Risk is what you get when you combine that vulnerability with the context of your environment, with your system and network design, your access controls, and your workloads.

A good example is a vulnerability with a CVSS score of 9.8 in a management interface. If that interface sits on an isolated management network that only a handful of administrators can reach, with MFA, the attacker has a lot of work to do before the 9.8 matters. If the same interface is reachable from the Internet, the attacker has no work to do at all. The score is the same, and the risk is very different.

This is where the vector comes in. “AV:N” means the attack works over the network, and “AV:L” means the attacker needs to already be on the system. “PR:N” means no privileges are needed, and “PR:H” means the attacker already has to be an administrator. If the attacker is already an administrator on your vCenter, a new vulnerability is not your biggest problem.

Questions to Ask About a Vulnerability

When something new appears, ask yourself a few questions:

1. Is anyone exploiting it? Check the advisory and the KEV catalog. If the answer is yes, most of the other questions stop mattering. Security advisories for VMware products generally indicate if exploitation “in the wild” is known to us (but also remember that vendors are not omniscient, either).
2. Can an attacker reach it? Think about where the affected component sits and who can talk to it. In many ways it’s less about vulnerabilities than attack paths nowadays. How can the attacker get to the problem to exploit it?
3. What does the attacker need first? Read the vector. A flaw that needs administrator access and a person to click something is a different problem from one that needs nothing. Also remember that an attacker who has administrator access won’t exploit a vulnerability, because they already have the access that they need (this is why identity and access control are extremely important as defense-in-depth).
4. Are you fully patched otherwise? Are you up to date so that an attacker cannot chain two issues together to make this a bigger deal than the individual severity would portray?

You shouldn’t skip patching, but isolation and hardening and access control buy you time, and these questions help you figure out how much time you might have.

Chaining Changes Things

Traditionally, organizations look at a vulnerability by itself. The problem is that attackers, and especially AI-driven attackers, don’t work that way. They combine flaws. One gets them onto the network, a second gets them privileges, and a third gets them out of a sandbox. On its own each might be rated Low or Moderate. Together they behave like a Critical.

Chaining is not new, but it has become more prominent. Building a chain used to take a skilled person days or weeks, so attackers saved that effort for their most valuable targets. AI models can now read advisories, compare patches, and work out which flaws fit together, and they do it quickly and cheaply. This changes things.

A prerequisite is not a barrier. When a vector says the attacker needs local access or privileges, ask whether another unpatched flaw in your environment could supply it, and who already has the access needed to exploit it.

Low and Moderate still need to get patched. You can schedule them, but don’t skip them. A backlog of small flaws is the raw material for a chain.

Staying current beats attempting to pick and choose. If you sort vulnerabilities one at a time and patch only the ones that seem scary, you leave the other pieces lying around. Regular updates that take everything remove them all at once.

The good news is that a chain fails when you break any one link. Isolation, hardening, and MFA all break links, and so does every patch you apply, including the boring ones. If you’ve been wondering why so many vendors stress patching, this is part of the reason.

How We Decide What to Do About Vulnerabilities

VMware Security Advisories emerge at the end of a long process that starts with us learning about an issue, and ends with coordinated disclosure. All issues are different, which makes the security response process infinitely interesting, and it means none of this is a formula. Still, there are a few things that we think about.

How Critical Is the Vulnerability?

Criticality, according to everyone else. The first number most people see comes from the National Vulnerability Database (NVD), or from the project that owns the code. Those numbers are usually worst-case and do not include any context. It’s also true that those numbers change. CVE-2023-51385, a flaw in OpenSSH, is a good example. NVD first scored it 9.8, which is Critical. After more analysis NVD revised it to 6.5. Other projects and vendors that ship OpenSSH scored it 4.8 and 3.9. Which score do you choose to believe? Especially when vulnerability scanners often choose the worst number to report (entirely understandable, from their perspective, as they’re caught in the middle, too).

Criticality, as implemented in the products. A generic score assumes the worst case, but is the problem actually exploitable in the product? Who can exploit it? What do they get if they do? A library can be present and never called, or reachable only by someone who is already an administrator. Or, conversely, the affected software could be there in part, but the issue is in a module that we don’t ship, meaning the issue may not affect the product at all.

Timing and Risk

Who reported it. Outside researchers have their own timelines. Some set disclosure deadlines of 90 or 120 days. Others want to present their work at a conference, and some work through bug bounty programs. We value this work and the people who do it, and those dates are part of how we plan.

The release cycle. Is a fix already available, perhaps from an open-source project, or are we building one? Which supported releases need it, and how soon can each one deliver it? Do we stop a release to do this, or wait for the next? Will we be able to test the change properly? We take our position in the infrastructure stack very seriously, and we work hard to make what we ship solid amongst the tradeoffs.

The overall risk to users. A security fix is a change, and every change carries risk. What does it do to a product that is feature-complete, like downlevel-yet-supported versions of ESX? What is the downstream risk, to third-party systems and the partner ecosystem? The OpenSSH release that fixed CVE-2023-51385 also listed “potentially incompatible changes” in its release notes. That is normal for security fixes, especially in the open-source world, and it is why testing matters so much to us.

Security also includes availability, after all.

So What Should I Do When I See a VMSA?

In order to “see” a VMSA, start by subscribing to the VMSA mailing list at:

https://go-vmware.broadcom.com/vmsa_email_alert

We also strongly recommend subscribing to all your vendors’ security mailing lists. Some organizations subscribe a single shared mailbox or distribution list, and others have all their staff subscribe individually. Up to you, but make sure it works. This is also a good task for an agentic AI bot (not kidding!). “Keep me posted twice daily on all security news for this list of vendors, make no mistakes.”

When an Advisory Arrives

When an advisory is issued, check whether it applies to you. The advisory lists the affected products and versions. If you don’t run the product, or you already run the fixed version, the advisory does not apply to you. Sometimes an advisory covers an issue that a release has already resolved. Coordinated disclosure generally means waiting until fixes are available for the supported versions, so an advisory can arrive after some releases already have shipped the fix. Patches are cumulative, too, so if you’re running a version that was released after the fixed version you will be covered as well.

Read the severity and the vector. Ask the questions above.

You might look for a workaround, and for some vulnerabilities there are workarounds. Workarounds buy time but they are not an easier path, for, in most cases, a workaround consumes more staff time overall than just fixing it the right way from the start. With tools like vMotion, snapshots, Live Patch, and more, we’ve made it very easy to patch VCF. These ideas aren’t just about VCF, either. Your workloads need patching, too, and VCF has a lot of tools to protect them and reduce the risk of patching them.

Read the VMSA itself, and read the Questions & Answers if there is one. For critical or not-as-straightforward advisories (issues with nuances) we publish a companion Q&A that attempts to answer the questions we know you are going to ask. We also update it with new questions as we go. You can see examples of this in our GitHub repository:

https://github.com/vmware/vcf-security-and-compliance-guidelines/tree/main/security-advisories

Plan the update. If your organization follows change management frameworks like ITIL, lean into those. Declare ITIL-esque Emergency changes, where the risk of not doing the update is much higher than the risk of doing it. Also lean into Live Patch on ESX and Quick Patch on vCenter where the patches support it.

Frequently Asked Questions About Vulnerabilities

Q1: How can I find out about vulnerabilities sooner? Can you tell me more about the issue?

A1: Telling you also tells the attackers. Under coordinated disclosure we keep the details private until a fix is ready, and then we publish the advisory and the fix together. Publishing early would give attackers a head start and give you nothing to install.

Similarly, we tell you what we can about the issue at hand. If an advisory seems light on detail, please know that we aren’t trying to be coy. Detail helps attackers, too, and limiting it buys you time.

Q2: My scanner says VCF is affected by a CVE in an open-source component. Is it?

A2: Maybe, but often not. A scanner can see that a component is present. It usually cannot see whether the vulnerable code is used, or whether an attacker can reach it. We will talk about scanners more in a future post in this series.

Q3: How can I know if my scanner is reporting a false positive?

A3: In the VCF download portal, under the tab “Additional Downloads,” is a CVE disposition report in CSV format that you can use to determine where the product stack stands.

Q4: The CVSS score on your advisory is different from the one I see elsewhere. Who is right?

A4: Scores can differ because the people doing the scoring know different things. We know how the product uses the affected code, and a public database often has to assume the worst. When the scores disagree, compare the vectors to see where the assumptions differ. The OpenSSH example above shows how far apart they can be.

Q5: Is there always a workaround?

A5: No. Some vulnerabilities are in code you cannot turn off, and the only answer is the fix. Other times a potential workaround would cause stability or other issues, too.

When a workaround does exist, treat it as a stopgap for when you cannot patch right away. Workarounds seem interesting but often cause more overall work than just fixing it the right way and moving on.

If you can patch, patch, and spend the time you save on improving your defense-in-depth.

Q6: I’ve isolated and hardened my environment. Do I still need to patch?

A6: Yes. Isolation and hardening make an attacker’s job harder and give you time, but attackers are patient and environments change.

Q7: Do you evaluate older versions that are out of support?

A7: No. Products past their End of General Support date are not evaluated as part of security advisories. If you are running a downlevel version, assume it is affected and plan your upgrade. If you have Extended Support for the version you are running, please contact Support for guidance.

Q8: Do I need to apply all the updates you release?

A8: We encourage that. Something to keep in mind is that Live Patch requires sequential patching, like from version A to B to C to D. If you skip versions you will need to do the more traditional vMotion-based patching to catch up (which really isn’t a problem, but Live Patch is better). So staying up to date in a timely manner, and working through process issues in your organization that might prevent that, is well worth the effort.

Also remember that vCenter and other management appliance updates are designed not to impact workloads. Your change managers may not know this.

Q9: How do I report a vulnerability I found in a Broadcom product?

A9: Please report it privately to Broadcom’s VMware Security Response Center using the information at:

https://www.broadcom.com/support/vmware-services/security-response