How do you patch or mitigate CVE-2022-23748 (Dante Discovery Process Control)?

CISA’s required action for CVE-2022-23748 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Audinate Dante Discovery in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.

What actually changes when you patch Dante Discovery Process Control?

The practical objective is to remove the vulnerable management surface from exposure, not just to install a file and move on. For CVE-2022-23748, that means locating every Dante Discovery instance, applying the vendor update or documented mitigation, and confirming that the product is no longer reachable in ways the advisory says are unsafe. If the vendor path cannot be applied, discontinuing use is a valid outcome.

For teams that are still triaging whether the product exists anywhere in the environment, the first question is inventory, not remediation timing. If you cannot identify all deployments, you cannot know whether the required mitigation has actually reduced exposure. A disciplined vulnerability workflow, as covered in the Vulnerability Management Guide, helps turn a one-off fix into a repeatable asset-scope and verification exercise.

For patchable third-party software, the usual sequence is straightforward: confirm the exact product instance, validate the vendor guidance for that build, apply the update or mitigation, and then verify the service is behaving as expected after change. If the product is part of a broader asset estate, the patch decision should be tracked like any other exploited-vulnerability event, using the same urgency you would apply to other confirmed in-the-wild issues described in the Zero-Day and Exploited Vulnerabilities Guide.

How should you handle systems that cannot be patched immediately?

When patching must wait, the job is to reduce reachable attack surface and bound the blast radius as tightly as possible. That usually means removing internet exposure, restricting who can reach the service, and documenting the exception so it is not treated as an open-ended risk acceptance. If a service can still be reached from untrusted networks, the mitigation is incomplete even if the software package itself has been updated in a lab.

For this class of issue, the best short-term control is often operational containment rather than a compensating detective control. If you cannot satisfy the vendor fix path right away, isolate the instance, limit access to the smallest trusted set, and keep the product under active change control until remediation is complete. In vulnerability triage terms, that is the same logic used to separate high-priority exploitable exposure from routine backlog items in the Patch Management Guide.

If the product is business-critical and cannot be removed immediately, treat the exception as temporary and measurable. The decision should specify who owns the exception, what exposure remains, and what condition ends the exception. If the vendor mitigation is unavailable or ineffective, discontinuation is the safer answer than trying to preserve availability at the cost of a known exploitable path.

What should you verify after remediation?

Post-fix validation matters because patch application alone does not prove exposure is gone. You should confirm that all instances have been covered, the vendor change is present, the service is no longer exposed beyond the intended boundary, and nothing reintroduced the vulnerable condition through a rollback, image rebuild, or forgotten node. If the product was externally reachable before, verify the new access posture from outside the trusted network as well as from inside it.

It is also worth checking whether the vulnerable service was exposed for long enough to justify compromise review. For an exploited vulnerability, the question is not only whether the patch landed, but whether the service was exposed during a window that could have been abused. That is why KEV-driven triage remains useful: the CISA Known Exploited Vulnerabilities Catalog is designed to prioritize exactly this kind of active exploitation risk.

After remediation, preserve proof of what was done and when. In practice, that means keeping the asset list, the version or mitigation state, the change record, and the verification result. Those records are what let you show that the vulnerable product was actually contained or removed rather than merely presumed fixed.

Risk and Threat Considerations

This vulnerability matters because a control or discovery component is especially dangerous when it is left reachable longer than necessary. An exposed management path can become an easy foothold for unauthorized access, service disruption, or follow-on abuse if the issue is not remediated quickly.

Failure mechanism: The vulnerable product remains deployed, reachable, or only partially mitigated after the advisory is known, which leaves the exploitable surface available to an attacker or to accidental misuse.

Impact: Continued exposure can turn a single product flaw into broader environment risk, especially if the service sits on a management network, supports production operations, or can be reached from the internet.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	CVE remediation requires tracked mitigation and verification across the asset estate.
	ID.AM-01 — Physical devices and systems inventoried	You must find every Dante Discovery instance before you can patch or contain it.
	PR.PS-05 — Installation and use of software are managed	The answer centers on updating or discontinuing vulnerable third-party software.
Recommendation — Track the issue through remediation and verify every exposed instance is covered. Inventory all deployments before applying mitigations or removal. Manage software changes so the vulnerable product is updated or retired.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This is an exploited vulnerability response problem requiring identification and remediation.
	CM-8 — System Component Inventory	Finding all Dante Discovery instances depends on an accurate component inventory.
	SI-2 — Flaw Remediation	The core action is to apply the vendor fix or an approved mitigation.
Recommendation — Use vulnerability monitoring to confirm exposure and drive remediation. Maintain an inventory that lets you locate and remediate every instance. Apply the vendor fix or approved mitigation and remove unfixable exposure.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE-2022-23748 should be handled as a prioritized vulnerability remediation item.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Mitigation may require restricting exposure or changing the deployment posture.
Recommendation — Prioritize, remediate, and verify this vulnerable software across the environment. Harden the deployment and remove unsafe exposure paths if patching must wait.
OWASP ASVS	V13 — Configuration	Operationally, the issue is about unsafe deployment and exposure configuration of a product.
	V15 — Secure Coding and Architecture	Mitigation may require architectural containment when a fix is unavailable.
Recommendation — Verify the deployment configuration no longer exposes the vulnerable service. Re-architect or remove exposure when a secure fix cannot be applied.

Practitioner Guidance

What to verify: Do not trust a “patched” status until you have confirmed every instance, every reachable path, and every exception. For exposed third-party software, validation should include the estate inventory, the vendor fix state, and an external reachability check.

Escalation / exception: If the vendor mitigation cannot be applied promptly, escalate to service removal or exposure reduction rather than leaving the product online under a temporary promise to fix it later. A short-lived exception is acceptable only when ownership, end date, and compensating containment are explicit.

Practitioner takeaway: For KEV-class issues, the real decision is whether you can still bound exposure safely; if you cannot, removal is a remediation action, not a fallback failure.