Review ACI DHCP implicit rules after the software fix

Bottom line: Keep software installation and the intended DHCP contract behavior as separate acceptance checks. Review the documented implicit-rule control before assuming a user-defined contract governs the traffic in question.

Source fact: documented behavior

The Cisco Nexus 9000 Series Fabric Switches in ACI Mode Endpoint Group Contract Bypass Vulnerability describes implicit DHCPv4 and DHCPv6 permit rules that take precedence over user-defined contracts and the generic implicit deny.

Cisco describes the fix as a control exposed through the APIC REST API for disabling or re-enabling those implicit rules; disabling them permits user-defined contract actions for DHCP traffic to be honored.

The advisory says the default remains that DHCP implicit rules are enabled and points to the APIC Basic Configuration Guide for the new control.

What the source does not establish

This article reviews the documented rule-precedence decision. It does not prescribe an APIC endpoint, request body or universal DHCP policy, and it does not claim that changing the control is harmless. Use the applicable current configuration guide and the fabric owner’s design before proposing an API change.

Applicability questions

• Which ACI fabric, APIC and software release are in scope?
• What DHCP behavior do the approved contracts intend?
• What is the actual implicit-rule setting after the software change?
• Which DHCP and isolation checks can the fabric owner authorize safely?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends explicit acceptance of the implicit-rule setting and intended DHCP contract behavior after reviewing the applicable fixed-software path.

1. Identify the actual fabric and software versions through approved administration. Match them to Cisco’s current advisory and configuration guidance. Preserve the intended DHCP paths with the fabric owner before changing any rule behavior. Keep software deployment success in one field and the reviewed implicit-rule setting in another rather than collapsing them into a single patched label.
2. Review the supported configuration control in the guide applicable to that deployment. Have the owner identify which contracts should permit, deny or redirect the relevant traffic and why. Do not invent an API URL or copy a request from an unrelated APIC release. Prepare the supported recovery path and the permitted ordinary DHCP checks before authorizing an edit.
3. Apply only an expressly approved control change through the documented workflow. Read the actual setting back and compare it with the intended fabric policy. Keep the configuration result and the service observations together. If a required path fails, retain the evidence and follow the supported recovery plan instead of broadly opening contracts to restore an unexplained outcome.

Verification and evidence

Proposed verification: prepare an approved pilot with one required DHCP path and one separately reviewed isolation expectation. Observe ordinary permitted client behavior and the fabric owner’s supported policy evidence. Record both the setting and actual result; do not infer enforcement solely from the presence of a user-defined contract in a screenshot.

Have a second reviewer distinguish fixed-software inventory, implicit-rule configuration and observed contract behavior. Keep any untested path explicit in the handoff. No APIC request, contract change or DHCP test was performed for this article, and the proposed pilot is not an exploit demonstration or a claim of complete fabric isolation.

Official references

• Cisco Nexus 9000 Series Fabric Switches in ACI Mode Endpoint Group Contract Bypass Vulnerability — Cisco; official security advisory.

Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.