Two CVEs from one advisory, two version floors. Your change record has one field.

Most vendor advisories ship one CVE per row in the operator’s head and one CVE per row in the operator’s tooling, and those two rows agree. cisco-sa-fmc-rce-NKhnULJh ships two. The deserialization RCE (CVE-2026-20131, CVSS 10.0, Scope:Changed) and the authentication bypass (CVE-2026-20079, CVSS 10.0) landed in the same advisory on March 4, 2026, against the same management interface. Five of the six remediation branches close both CVEs at the same minimum version. The 7.4.x branch does not. 7.4.4 closes the auth bypass. 7.4.6 is the floor for the deserialization RCE.

The advisory states this. The change record does not have a field for it. The standard advisory-to-ticket workflow opens one ticket per advisory and writes one target version per branch. A team that writes 7.4.6 (the higher of the two floors) into the ticket closes cleanly against both CVEs. A team that writes 7.4.4 (the version the auth-bypass scanner returned first, the version the release-notes summary surfaced) closes the ticket against CVE-2026-20079 and leaves CVE-2026-20131 open underneath a closed ticket. The scanner that re-runs after the upgrade reports the deserialization RCE as still vulnerable. Whether that signal reaches the same change record depends on the team’s tooling integration, and most integrations are one-CVE-per-row.

The KEV listing compounds the schema problem. CISA added CVE-2026-20131 to the catalog on March 19 with a three-day federal due date against a class of equipment whose structural minimum is the HA-pair coordination, the pre-upgrade snapshot, the optional multi-hop intermediate release on older branches, and the post-upgrade policy redeploy. The three-day deadline is honest about adversary tempo: a 36-day zero-day window before patch, a public PoC on GitHub one week after fix, Interlock ransomware activity through the window. The deadline is not honest about the version-floor split. An FCEB operator on a 7.4.x branch who patches to 7.4.4 within three days clears the BOD 22-01 row against the catalog and misses the actual remediation against the actual CVE the catalog row names.

The advisory’s own structure makes the disjunction visible to a reader willing to do the cross-reference. The per-CVE fixed-version table is in the document. The release notes for 7.4.4 mention the auth bypass and not the RCE. The operator with time to read both is fine. The operator working from a vulnerability-management tool that imported the advisory as one entry and surfaced the lower of the two version numbers as “the fix” is not. The failure mode is not a vendor failure. It is a schema failure between three layers (advisory text, change record, scanner output) that all model the same advisory and disagree about what “fixed” means on the 7.4.x branch.

The narrow remediation question has one answer: on the 7.4.x branch, patch to 7.4.6 minimum, not 7.4.4. The reconciliation question is wider. Cisco’s monthly-style advisory model has lived in this state on other product lines for years. Microsoft’s cumulative-update model at least collapses the disjunction into one rollup version that closes everything in the bundle. The Cisco FMC model on this advisory is one document, two CVEs, two floors on one branch. The audit narrative has one field per host. Until the tooling chain grows the second field, the reconciliation has to live in the workflow that imports the advisory. The fastest reliable rule is the one this editorial corpus keeps arriving at from different angles: read the advisory, not the row the tool surfaced from it.