2026-09-07 · CVE-2026-76657
CVE-2026-76657 + CVE-2026-76658: Two Perfect 10s in HPE Fabric Composer, and Why 'Internal Only' Isn't a Mitigation
On September 1, 2026, HPE disclosed two vulnerabilities in Networking Fabric Composer (AFC) that both scored a maximum CVSS 10.0 — and the reason both hit the ceiling is the same reason they're worth teaching together: neither one requires a single valid credential to reach administrative control of the host.
Fabric Composer is the kind of product most people outside data-center operations have never heard of and most attackers actively look for anyway: a management plane that provisions and orchestrates network fabrics across a data center. It doesn't sit at the edge facing the internet like a VPN appliance — it sits in the management segment, which is exactly why compromising it is so valuable. Own the fabric manager, and you own the thing that can reconfigure the network underneath everything else running on it.
What the two bugs actually are
CVE-2026-76657 is an authentication bypass in the Fabric Composer API. HPE's advisory describes it plainly: a remote, unauthenticated attacker can circumvent existing authentication controls and obtain administrative privileges without valid credentials. That's the whole bug in one sentence — whatever check is supposed to gate API access to authenticated administrators, it doesn't hold, and the failure mode is "you're an admin now," not "you're locked out."
CVE-2026-76658 lives in the SSH daemon shipped with Fabric Composer. Same profile: unauthenticated, network-reachable, and the outcome is administrative access with the ability to execute arbitrary commands as a privileged OS user. Where the first bug hands you the application's own admin plane, this one hands you a root shell on the underlying operating system.
Both are rated 10.0 for the same reasons: no authentication required, low attack complexity, network-reachable, and complete loss of confidentiality, integrity, and availability if exploited. HPE hasn't published the low-level root-cause writeup for either one — vendor advisories at this severity rarely do until well after patch adoption catches up — but the practical shape of both bugs is clear enough to reason about, and reason about it we should, because this pattern (an API that fails open, an SSH daemon that doesn't actually require SSH credentials) shows up again and again in management-plane software that was built assuming it would only ever be reached from a trusted segment.
| CVE-2026-76657 (API auth bypass) | CVE-2026-76658 (SSH daemon) | |
|---|---|---|
| Auth required | None | None |
| CVSS | 10.0 | 10.0 |
| Surface | Fabric Composer management API | SSH daemon on the AFC host |
| Impact | Administrative control of the application | Arbitrary command execution as a privileged OS user |
| Fixed in | 7.3.4 / 7.4.0 | 7.3.4 / 7.4.0 |
Why "it's only on the management network" isn't the mitigation it sounds like
The instinctive defense here is "Fabric Composer isn't internet-facing, it's on an internal management segment, so the blast radius is contained." That's true right up until it isn't. Management segments get flatter than architecture diagrams suggest — jump hosts, vendor VPNs, a contractor's laptop with a misconfigured route, a compromised workstation three hops away that happens to have reachability to the same VLAN. "Not internet-facing" describes an intended network boundary, not a guaranteed one, and the entire reason ransomware operators spend time on lateral movement is that internal segments are reachable from somewhere once you're inside the perimeter at all.
That's also precisely why an unauthenticated bug on a fabric-management tool is worse than the same bug on, say, a single application server. A compromised app server gets you that server. A compromised fabric manager potentially gets you visibility into — and control over — the network fabric connecting dozens or hundreds of hosts behind it. The blast radius scales with what the tool manages, not with the size of the tool itself.
If your incident-response runbook treats "internal-only" as a mitigating factor that lowers a finding's priority, this pair of CVEs is a good prompt to revisit that assumption specifically for orchestration and fabric-management tooling. The right question isn't "is this reachable from the internet," it's "if an attacker already has a foothold anywhere on this network, what does this system let them reach next, and is that reach worse than the foothold itself?" For a fabric manager, the answer is almost always yes.
What this means for defenders right now
The unglamorous advice applies here same as it always does: patch to 7.3.4 (if staying on the 7.3 branch) or 7.4.0, and do it before assuming network segmentation buys you meaningful time. Until the patch is applied, the only real compensating control is network-level — restrict reachability to the Fabric Composer API and SSH daemon to the smallest possible set of hosts that actually need it, and audit whether "management segment" in your environment is actually as isolated as the network diagram claims. If a jump host, a VPN concentrator, or a shared admin workstation can reach both Fabric Composer and something less trusted, that's your real attack path, diagram notwithstanding.
The more durable lesson is about how these bugs get found and exploited in the first place, and it's a familiar shape: authentication bypasses in management-plane software rarely announce themselves as "the auth check is missing." They show up as an edge case in how a session token is validated, a code path that was supposed to be unreachable without a prior authenticated step but turns out not to be, or a service (like an SSH daemon) that was configured or built with an assumption about its network position baked in rather than enforced. An SSH daemon that doesn't actually require SSH credentials sounds absurd stated flatly — but it's exactly the kind of thing that happens when a component gets treated as "internal by design" during development and that assumption never gets revisited once the product ships into environments where internal isn't the same as trusted.
Why we teach it this way
This is the same category of finding we build into 0Labs' infrastructure-security labs: not "here's a CVE, memorize the number," but "here's a management plane, here's what it's trusted to do, now go find where that trust boundary doesn't actually hold." An authentication bypass is a much better teaching tool when the student has to probe the actual API surface and notice the gap themselves — send the request an authenticated admin would send, skip the part that's supposed to require a login, and watch it work anyway — than when they just read a paragraph describing that it happened to someone else.
The specific product changes. Fabric Composer today, something else with a different vendor name in eighteen months. What doesn't change is the instinct: when you're evaluating any management-plane tool, ask what it's implicitly trusting about its network position, and go check whether that trust is actually enforced or just assumed. That's a skill you build by finding the gap yourself on a target you're allowed to break, not by reading someone else's advisory after the fact — which is exactly why this pair of CVEs, unauthenticated API bypass paired with an SSH daemon that doesn't require SSH, makes a better lab scenario than a blog post.