Is it time to open responsible disclosure to trusted third parties?

A recent case involving VMware raises a critical question: Does responsible disclosure unintentionally extend the window of exposure, also known as "dwell time", between the discovery of a vulnerability and its public acknowledgment or remediation? Particularly when new intelligence is received which increases the vulnerability's criticality (CVSS).

Does this bring into question the actual “responsibility” of responsible disclosure in its current form?

The Case in Question

Broadcom, which now owns VMware, recently issued an advisory for a high-severity vulnerability (CVE-2025-41244) affecting VMTools and Aria Operations.

The advisory made no mention of active exploitation, which would lead to a change to CVE criticality. Dark Reading reached out for clarification on this point, Broadcom did not respond at the time [https://www.darkreading.com/remote-workforce/china-exploited-new-vmware-bug-nearly].

Yet, according to a blog post by NVISO [https://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/], a penetration testing and incident response firm, this vulnerability may have been exploited in the wild as early as October 2024, nearly a year before disclosure.

Broadcom’s advisory states that the vulnerability, rated 7.8 on the CVSS scale, can only be remediated by applying the appropriate patch. No workarounds or mitigations were offered; not quite the 'full picture'.

The key is to understand the scope of this risk - are you impacted; do you need to act? In this situation, the vulnerability only affects users who meet all of the following conditions:

1. Running VMware Aria Operations AND
2. Using VMware Tools (versions 11.x, 12.x, or 13.x) AND
3. Have the Service Discovery Management Pack (SDMP) enabled

This significantly narrows the attack surface.

Mitigation:

The priority here is to address the risk quickly utilising all available means. Waiting for a generic OEM patch fix is not the only way. For example, CVE-2025-41244 can quickly be mitigated by disabling SDMP. Yes, this may reduce visibility of monitored applications and services, however, functionality, if needed, can be restored using tools like vRealize Network Insight (vRNI) offer visibility by analysing network flows and VM-to-VM communications, without relying on guest OS scripts. Alternatives solutions also include Opentext Universal Discovery, and to a more limited extent, open source solution such as Nagios, Zabbix, and Prometheus, although customisation and extension of these solutions may be required to achieve desired results.

Levelling the Playing Pitch

This raises a broader concern: Are Original Equipment Manufacturers (OEMs) acting quickly enough to detect and disclose active exploitation? And if not, should trusted third parties be allowed access to vulnerability intelligence at the same time as the OEM to develop and provide viable alternative mitigation actions?

Independent software support providers can also help organizations assess and implement mitigations tailored to their environments. This is especially important for vulnerabilities in open-source components, which are often bundled with enterprise software but not actively supported by OEMs. In fact, over 60% of security risks reported to Origina Ltd stem from such components.

A Broader Pattern

This isn’t an isolated case. On September 8, 2025, CVE-2025-41243—a CVSS 10.0 vulnerability in Spring Cloud Gateway Server WebFlux left many organizations exposed, particularly those using unsupported versions (4.1 or earlier). Without access to patches, these users were left vulnerable.

Proactive Security Posture

Organizations like Origina Ltd promote a contextual, risk-based, defense-in-depth approach. Rather than reacting to each CVE in isolation, they use vulnerabilities like CVE-2025-41243 to inform broader defensive strategies, protecting not just the affected product, but the entire environment.

The Bigger Question

While OEMs typically advocate for patching as the primary remediation path, either to simplify support or, more cynically, to maintain control of customer roadmaps product strategies through support contracts, there are viable alternatives.

• Should vetted third parties be granted access to vulnerability intelligence at the same time as OEMs?
• Could doing so accelerate response times and offer more flexible, compliant and tailored options for users?

Afterall, the goal is security, not blindly following processes hidden behind the mantra of 'its always been done this way....'