Six More Vulnerabilities Are Being Exploited: What UK Businesses Should Do Now

A long vulnerability list can create the illusion that every update is equally urgent. It is not. On 10 November 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added six more flaws to its Known Exploited Vulnerabilities (KEV) Catalogue after finding evidence that attackers are already using them.

The additions affect products from Cisco, Barracuda Networks, Openwave Messaging, Microsoft and Google. They include weaknesses in Outlook and Chromium as well as flaws in internet-facing communications and security products.

For UK organisations, the important lesson is broader than any single software update: patching decisions should be driven by exposure and real-world exploitation, not by the size of a vulnerability score alone.

What makes a KEV different?

A newly disclosed vulnerability is a potential route into a system. A vulnerability in the KEV Catalogue has crossed a more serious threshold: CISA has evidence that malicious actors have exploited it in the wild.

That does not mean every business is affected. It does mean that any organisation using the vulnerable product should quickly establish whether the flaw is present, exposed and patched. Attackers often move rapidly once public advisories, technical details and fixes become available.

The six additions announced on 10 November include:

• CVE-2026-20320, affecting Cisco BroadWorks;
• CVE-2026-111560 and CVE-2026-116606, affecting Barracuda Networks products;
• CVE-2026-111793, affecting Openwave Messaging Webtop;
• CVE-2026-124194, affecting Microsoft Outlook; and
• CVE-2026-125350, affecting Google Chromium.

The vendors’ remediation instructions should be treated as the definitive technical guidance for each product. CISA’s alert is the signal to check your environment and act.

A practical response for UK businesses

1. Confirm whether the products exist in your environment

Start with an accurate asset inventory. Check managed and unmanaged devices, servers, virtual machines, cloud services, remote-access systems and software supplied by third parties. Remember that Chromium is also the foundation for several other browsers and embedded applications, so a product name may not tell the whole story.

Ask your IT provider for evidence rather than a general assurance: which affected products were checked, which versions were found, and what action was taken?

2. Prioritise internet-facing and high-privilege systems

A vulnerable email client, security gateway or communications platform can create very different risks depending on how it is deployed. Prioritise systems that are reachable from the internet, hold sensitive information, process email or identity data, or provide administrative access to other services.

Also consider business impact. A flaw on a system that supports payroll, customer service or production may deserve faster action than the same flaw on an isolated test device.

3. Apply the vendor fix and verify it

Install the supported vendor update or follow the vendor’s published remediation guidance. Where possible, test critical applications before broad deployment, but do not let a slow or undefined test process turn an urgent patch into an indefinite delay.

After deployment, verify the version or build actually running on the device. Check that services restarted correctly and that important functions still work. A successful software-deployment message is useful, but it is not the same as proof that the vulnerability is no longer present.

4. Look for signs of earlier exploitation

Patching prevents future use of the flaw; it does not undo a compromise that has already happened. Review security alerts, authentication activity, endpoint detections, email-gateway logs, unexpected processes, new accounts, configuration changes and unusual outbound connections.

The right checks depend on the affected technology and the vendor’s indicators of compromise. If there is evidence of suspicious activity, preserve the evidence and begin a structured incident response rather than simply reinstalling the update.

5. Record the decision

Keep a concise record of the affected assets, owner, action taken, verification result and any accepted risk. This gives managers a clear view of progress and creates useful evidence for audits, customers and insurers.

Do not let CVSS become the whole strategy

Severity scores remain useful, but they describe technical characteristics rather than your complete business risk. A slightly lower-scoring vulnerability under active exploitation on an exposed system may be more urgent than a critical-scoring flaw that cannot be reached in your environment.

A sound vulnerability process combines:

• evidence of active exploitation;
• asset exposure and accessibility;
• the privileges an attacker could gain;
• the sensitivity of the data and service involved;
• available mitigations and vendor fixes; and
• the operational impact of patching or delaying.

Build a repeatable patching rhythm

The most resilient organisations do not begin from scratch every time a high-profile alert appears. They maintain an asset inventory, define emergency change procedures, assign system owners, monitor trusted advisories and test recovery plans.

Astley Digital’s Managed IT Solutions include proactive monitoring, patch management and support, while our cyber security consulting services help organisations assess risk, improve governance and prepare for incidents.

If you are unsure whether these actively exploited vulnerabilities affect your organisation, contact Astley Digital. We can help you establish exposure, prioritise action and build a patching process that stands up when the next urgent advisory arrives.