CVE-2026-76465: Cisco NX-OS MPLS OAM Exposure and Fixes

CVE-2026-76465 affects MPLS OAM processing on certain Cisco Nexus switches running NX-OS. The important qualifier is configuration: Cisco identifies Nexus 3000 and standalone NX-OS Nexus 9000 devices running affected software with MPLS OAM enabled. Its security advisory rates the issue Critical, CVSS 3.1 9.8, and describes possible root-level code execution or denial of service. MPLS OAM is disabled by default; a product-family match alone does not establish an exposed deployment.

The practical response is to establish the device’s operating mode, running release, feature state, and relevant network access, then select an appropriate fixed image. Keep those observations together. A scanner result that names NX-OS is a starting point for an inventory review, while an authenticated configuration check can answer a different and more useful question: does this particular switch meet the published conditions?

Start with the platform and feature gates

Cisco’s affected-product guidance excludes Nexus 9000 devices in ACI mode and Silicon One models that cannot enable this feature. Do not flatten hardware family, operating mode, software release, and configuration into a single affected flag. An asset record should preserve each field and the evidence supporting it.

A useful inventory row includes a stable asset identifier, hardware model, operating mode, complete running software release, feature state, observation time, and owner. “Nexus 9000” is not sufficient detail for a maintenance decision. If the inventory and device output disagree, resolve the discrepancy before selecting an image or marking the finding closed.

Unknown information needs its own status. Missing feature output does not mean the feature is disabled, and a truncated release string does not mean the software is fixed. Assign the next observation needed to resolve uncertainty. This prevents incomplete discovery from quietly becoming a false negative in the final report.

Use a read-only check before planning changes

Cisco documents the following feature query in the advisory. Run it only through authorized administration of your own device. It reads feature state; it does not prove exploitability, generate malformed traffic, or modify configuration. Collect the complete running release through your established device-inventory procedure as well.

show feature | include mpls_oam

An enabled result should lead to a release and exposure review. An empty or unexpected result should lead to an explanation, not an automatic safe verdict: confirm the platform, command support, operating context, and collection method. Preserve the output together with its asset identity so that a copied terminal fragment cannot be mistaken for evidence about another switch.

그리고 NX-OS MPLS Segment Routing OAM guide explains the diagnostic role of MPLS ping and traceroute. That role is why a feature decision belongs with the network owner. Removing a diagnostic capability may be reasonable for one deployment and disruptive to another team’s fault-isolation process.

Separate the commands used to collect evidence from commands used to change a device. Put proposed changes into the normal maintenance plan with ownership, impact assessment, and verification. This article does not require an operator to test an exploit or make a configuration change just to establish whether the advisory applies.

Understand the affected traffic path

그리고 Cisco-authored CVE record identifies improper validation of an MPLS echo-request, classified as CWE-590. A crafted request reaching affected processing can result in root execution or process crashes and a possible device reload. This is a network-packet handling issue; the public description is not a web-login bypass or a management-API exploit recipe.

Network reachability must therefore be evaluated against the relevant path. An HTTPS management interface check cannot establish whether MPLS diagnostic processing can receive the triggering traffic. Conversely, a switch address appearing in a public inventory does not establish every prerequisite. Map the path with the network team instead of substituting an unrelated port test.

Use a bounded reachability review: identify potential source segments, the device addresses and interfaces involved, and the controls expected to govern that traffic. Label inferred paths separately from observed paths. Do not broaden the exercise into internet scanning or packet-fuzzing against operational equipment. The administrative evidence is already useful without provoking a failure.

Try Penligent for Authorized Security Testing →

A small offline model for consistent triage

The following Python example encodes the decision process using synthetic inventory entries. It sends no traffic and contains no NX-OS exploit. Its purpose is to show why missing evidence, a disabled feature, and a fixed release should not all be compressed into the same status. The caller must supply a release assessment obtained from authoritative release guidance; the code deliberately does not guess from version ordering.

from dataclasses import dataclass

@dataclass
class Asset:
    in_scope_platform: bool | None
    affected_release: bool | None
    oam_enabled: bool | None

def classify(asset):
    if asset.in_scope_platform is False:
        return "outside published platform scope"
    if asset.in_scope_platform is None:
        return "platform evidence missing"
    if asset.affected_release is False:
        return "fixed-release evidence recorded"
    if asset.affected_release is None:
        return "release assessment required"
    if asset.oam_enabled is None:
        return "feature evidence missing"
    if asset.oam_enabled is False:
        return "feature condition absent; retain upgrade plan"
    return "conditions met; review reachability and remediate"

assert classify(Asset(False, True, True)).startswith("outside")
assert classify(Asset(True, None, False)).startswith("release")
assert classify(Asset(True, True, None)).startswith("feature evidence")
assert classify(Asset(True, True, False)).startswith("feature condition")
assert classify(Asset(True, False, True)).startswith("fixed-release")
assert classify(Asset(True, True, True)).startswith("conditions met")
print("Six offline triage checks passed.")

Notice that this model stops before declaring a reachable exploit. Meeting the platform, release, and feature conditions creates a remediation target; it does not establish an observed attack. That separation is useful in fleet reporting, where one owner may collect configuration evidence and another may assess network access. Each should be able to see which conclusion the other actually supported.

The model also avoids lexicographic version comparisons. A string that sorts later is not a substitute for a vendor-supported release assessment across hardware platforms and release trains. When automating inventory, store the advisory identifier and the source of the release determination alongside the result. This makes a later rule change auditable.

Select a fixed release for the actual device

The advisory directs operators to Cisco 소프트웨어 검사기. Evaluate the exact product, platform, and release. The checker distinguishes the first release addressing a particular advisory from a combined first-fixed result addressing the advisories in its selected scope. Those can answer different maintenance questions.

Do not publish one universal NX-OS version as the fix for every Nexus deployment. The appropriate target depends on the supported hardware and release path. An image that addresses this advisory but does not support the installed hardware or required features is not a valid remediation plan. Keep the checker result and compatibility review with the change record.

A fleet plan should distinguish device groups that can share an image from groups requiring separate validation. Begin with a representative device whose role, traffic pattern, and support requirements are understood. Confirm the target and rollback procedure before expanding the rollout. This is a change-management recommendation, not a claim that every network requires the same topology or upgrade method.

Avoid a false choice between immediate uncontrolled changes and indefinite delay. A clear maintenance plan can assign a temporary risk decision, a supported target, an owner, and a deadline while preserving network functionality. An unresolved compatibility question should be visible as a blocker with a next action, rather than hidden in a ticket marked patched.

Distinguish temporary mitigation from remediation

Cisco states that there is no workaround that fixes the underlying vulnerability. Its mitigation guidance says disabling unneeded MPLS OAM removes the attack vector, and a Live Protect shield can provide temporary protection. A supported fixed software release remains the remediation. Evaluate functional impact before applying either temporary option.

The distinction changes what evidence should be collected. For a feature-based mitigation, record which feature was changed, which devices received the change, and how the required network operations were checked afterward. For a shield-based mitigation, retain the vendor’s applicable release and platform requirements and verify the intended protection is active. Availability of a shield download is not evidence that it is installed or applicable.

A temporary decision needs an expiration condition. For example, the ticket can remain mitigated until a specified upgrade window and require re-review if the feature is re-enabled. Without that condition, an operational exception can become a permanent security status even after its assumptions change. Record who owns the exception and what observation would invalidate it.

Verify the rollout without triggering the vulnerability

After maintenance, collect the running release and feature state again and associate them with the same asset identifiers used before the change. Verify the operational functions relevant to that device role through the organization’s approved health checks. The evidence should show both that the intended software is running and that the network still performs the work the maintenance plan expected.

Do not use a crash as a patch test. A non-crashing switch also does not prove the absence of a vulnerable path. An exploit-shaped probe introduces an unnecessary availability risk when the key remediation questions can be answered through provenance, configuration, release mapping, and ordinary functional validation.

Try Penligent for Authorized Security Testing →

Choose acceptance criteria before the maintenance window. Include which device groups are in scope, what running-release evidence must be retained, which diagnostic or service checks will be repeated, and who can approve return to service. Define how a failed check changes the rollout decision. This keeps a time-constrained window from turning into an improvised search for reassuring output.

Check the saved inventory as well as the immediate terminal session. If a later automation job overwrites the collected release or records the wrong device identity, the report can diverge from the work performed. The goal is a reproducible relationship between asset, installed image, configuration state, and validation result. A single screenshot with no asset context is weak evidence even when it looks technically plausible.

Make the maintenance decision reviewable

Before the change, separate three decisions that often get bundled together: whether the device meets the advisory conditions, which temporary exposure reduction is acceptable, and which software target the organization can support. Each needs different evidence and may have a different owner. The security reviewer can identify the affected condition while the network owner determines the operational impact and approved upgrade path.

Build a compact pre-change record with the device identity and current observations, the selected image or temporary protection, the relevant vendor assessment, and the expected health checks. Record what would cause the team to stop expanding the rollout. These are local acceptance criteria, so choose them for the device role rather than copying a generic checklist that includes tests unrelated to the deployment.

A useful post-change comparison should answer specific questions. Did the intended device receive the intended image? Does the running release agree with the approved target? Is the feature state consistent with the response decision? Do the required network operations still work? Did any check produce an unexplained difference? The comparison is stronger when the same collection method and asset identifiers are used before and after maintenance.

Keep rollback planning connected to security status. If an operational failure requires returning to an earlier affected image, the service may recover while the original exposure returns. The change record should reopen or preserve that exposure assessment and identify the temporary decision that applies. A successful rollback is an availability outcome, not evidence that the CVE has been resolved.

For a fleet, report counts using evidence-based categories: verified fixed, verified temporary mitigation, current feature condition absent, outside published scope, and assessment incomplete. Avoid presenting every closed operational task as a fixed vulnerability. The category tells the next operator what is known and which observation could change the decision.

Finally, document exceptions in language that survives a shift change. An exception should name its affected assets, owner, reason, assumptions, expiration, and next decision. If the decision depends on a feature staying disabled or on a temporary protection remaining active, make that dependency explicit. This is how a temporary response remains maintainable instead of becoming an invisible permanent assumption.

Investigate suspicious activity as a separate question

In the advisory version reviewed on October 20, Cisco PSIRT reports that it is not aware of public announcements or malicious use of this vulnerability. That is the vendor’s published knowledge at that point, not a guarantee that exploitation is impossible. Do not rewrite a rising search trend as confirmed exploitation, and do not interpret a lack of published attacks as a reason to ignore a reachable affected configuration.

If a device has unexpected reloads, process failures, configuration changes, or other independently suspicious behavior, preserve the available evidence under the organization’s incident process. Those observations can have several causes. A crash alone does not attribute a CVE, and a clean uptime display does not exclude a historical event. Document the time interval, telemetry available, and gaps in visibility.

Keep patch closure separate from incident closure. A successful upgrade answers a question about current software. It does not retrospectively explain every earlier failure or establish that no credentials or configurations were affected. Conversely, an investigation may conclude that a particular failure was unrelated while software remediation is still required.

For an authorized assessment, require tools and reviewers to make these boundaries explicit. A useful finding identifies the affected asset, the configuration evidence, and the retest needed to close it. When evaluating Penligent or another testing workflow, match the claimed result to the access actually granted; an external web check cannot stand in for authenticated switch configuration evidence.

Questions network operators ask

Does every Nexus 9000 switch need the same response

No. Hardware, operating mode, running release, and feature state determine the relevant classification. Keep those fields visible rather than assigning a family-wide verdict from the product name.

Is a disabled MPLS OAM feature equivalent to an upgrade

No. It supports a configuration-dependent mitigation decision. Retain a software-remediation plan and make sure later configuration changes do not silently invalidate the mitigation.

Can a management-port scan verify the vulnerability

It does not establish the MPLS OAM processing conditions described here. Use authorized administrative evidence and a bounded review of the relevant network path.

Should a scanner’s Critical label be ignored when the feature is disabled

Keep the software finding and the current configuration assessment as separate fields. The label helps prioritize review; the documented configuration explains current exposure and the chosen response.

What is the minimum useful closure record

Retain the exact asset and hardware identity, running-release assessment, feature state, selected remediation or temporary protection, operational validation, and any unresolved investigation. Another operator should be able to reconstruct the decision.

The strongest response to CVE-2026-76465 is specific: identify the applicable platform and feature, map the installed release to a supported fix, and verify the deployed change without provoking a failure. That produces a defensible network-maintenance decision while preserving the difference between exposure, mitigation, repair, and evidence of an attack.