Unauthenticated first-boot provisioning permits administrative takeover

An unauthenticated network caller can claim administrative ownership of an unconfigured appliance by reaching first-boot provisioning before its intended owner.

Published: 2026-11-10
Researcher: HACKZA
Severity: High
Vendor status: Not a vulnerability
CVE status: Vendor declined
Product: VMware Cloud Foundation Operations

Summary

Several CASA first-boot cluster and master-provisioning endpoints are accessible without authentication. On an unconfigured appliance, a request can supply the initial administrator password and cluster topology. The application changes the initial administrative credential and deploys privileged master roles without requiring an existing credential, bootstrap token, console confirmation, or authenticated provisioning channel.

An attacker who reaches a newly deployed appliance before its intended owner can claim administrative ownership.

Broadcom classifies this as intended, documented behavior rather than a security vulnerability. HACKZA disagrees because installation state establishes when setup may occur, but does not authenticate who is entitled to perform it.

Affected product

Product	Tested version	Fixed version
VMware Cloud Foundation Operations	`9.1.0.0400.25541561`, build `25541561`	None announced

Severity assessment

HACKZA assesses the issue as High, with a CVSS 3.1 base score of 8.1:

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

This is a researcher assessment, not a Broadcom score. The metric rationale is:

Attack Vector — Network (AV:N): the affected provisioning routes are reachable through the appliance HTTPS interface.
Attack Complexity — High (AC:H): the request itself is straightforward, but successful exploitation depends on a transient condition outside the attacker’s full control: the appliance must still be unconfigured and the attacker must reach it before the intended owner completes provisioning.
Privileges Required — None (PR:N): no existing account, bootstrap token, or authenticated session is required.
User Interaction — None (UI:N): no action by another user is required for the attack request to succeed while the appliance remains unconfigured.
Scope — Unchanged (S:U): the assessed impact remains within the security authority of the affected appliance and its provisioning functions.
Confidentiality, Integrity, and Availability — High (C:H/I:H/A:H): a successful caller establishes the appliance administrator credential and can control its privileged master-role deployment and subsequent configuration.

The AC:H value follows CVSS 3.1 guidance for exploitation that depends on conditions beyond the attacker’s control and conservatively accounts for the limited first-boot window. Broadcom assessed the overall impact as limited because an unconfigured node contains no customer data, credentials, adapters, or connections to the customer’s infrastructure. The vendor did not classify the reported behavior as a vulnerability.

Prerequisites and limits

The target must be in its initial unconfigured state. The attacker must be able to reach the appliance HTTPS interface during the deployment window.

The tested direct path is unavailable after initial configuration. The finding does not demonstrate access to an already configured appliance or to an existing customer estate. Recovery for an owner who detects an unauthorized claim is to discard and redeploy the unconfigured appliance.

Affected routes

POST /casa/cluster
POST /casa/public/cluster
POST /casa/cluster-with-cert
POST /casa/public/cluster-with-cert
POST /casa/node/master

Technical analysis

The application treats mutable installation state as sufficient authorization for password establishment and privileged role deployment. It checks whether the appliance has already been configured, but it does not authenticate whether the network caller is the intended appliance owner.

The tested build accepts the listed routes without an authentication header and reaches the first-boot password-change and privileged master-role deployment behavior while the appliance is unconfigured. The configured-state check blocks the same direct path after provisioning; it does not authenticate the first caller during the deployment window.

Safe reproduction

Use only an owner-approved disposable appliance that has not been configured. Send a first-boot provisioning request without an Authorization header, with dry-run behavior disabled and a tester-selected administrator password:

POST /casa/cluster HTTP/1.1
Host: authorized-lab-appliance.example
Content-Type: application/json
Connection: close

{
  "admin_password": "<lab-only-password>",
  "master": {"address": "localhost", "name": "lab-master"},
  "init": true,
  "dry-run": false
}

A successful result changes the initial administrative credential and begins privileged master-role deployment. Restore the appliance snapshot immediately afterward. Do not test this behavior against production, third-party, or unclaimed appliances.

Security impact

The first unauthenticated network caller can become the appliance administrator, select initial cluster members, and control subsequent management and monitoring configuration. This provides complete confidentiality, integrity, and availability impact for the unclaimed deployment.

The deployment-window and empty-appliance limitations materially constrain the attack opportunity. They do not, in the researcher’s assessment, establish that the first network caller is authorized to set the administrative credential or own the appliance.

Remediation

Broadcom stated that the product team plans to incorporate hardening in a future release, but did not announce a release, fixed version, security advisory, or supported workaround.

HACKZA recommends:

Require a random, single-use bootstrap secret delivered through the VM console, deployment orchestrator, or another authenticated channel.
Bind the secret to the appliance and expire it after a short interval or first successful use.
Do not authorize password establishment or role deployment solely from installation state.
Restrict bootstrap access at the network layer and log all attempts.

Until product hardening is available, administrators should isolate the appliance setup interface and complete provisioning immediately after deployment.

Vendor position

Broadcom VCF PSIRT concluded that unauthenticated first-boot setup is intended and documented. Its assessment emphasized that the public REST endpoints implement the documented installation wizard, that the exposure ends after configuration, and that an unconfigured node does not yet contain customer data, credentials, or infrastructure connections.

The vendor stated that the planned hardening is a defense-in-depth improvement, not an acknowledgement of a vulnerability. It will not assign a CVE or publish a vendor security advisory for this report.

Researcher assessment

HACKZA agrees that the appliance is empty before configuration and that the affected setup path closes afterward. The disagreement concerns authorization: documentation explains that first-boot setup is unauthenticated, but does not verify that the caller establishing the administrative credential is the intended owner. Network position during a deployment window therefore determines ownership of the appliance.

Weakness classification

HACKZA maps the reported behavior to CWE-306: Missing Authentication for Critical Functionality. MITRE describes this weakness as critical functionality that lacks authentication despite requiring a provable user identity. Establishing an appliance’s initial administrator credential and deploying privileged cluster roles are the critical functions in this report.

This is the researcher’s mapping, not a classification assigned by Broadcom.

Comparable public precedents

The following published vulnerabilities demonstrate that unauthenticated setup and bootstrap boundaries are security-relevant in other products. They do not prove that this report must receive the same classification or severity: product capabilities, exposure windows, state transitions, and downstream impact differ.

Reference	Relevant similarity	Material difference
Nginx UI CVE-2026-42222	A fresh instance exposed `POST /api/install` without authentication during a ten-minute setup window. The first caller could set the administrator credentials and initial application secrets. The advisory maps the behavior to CWE-306.	The Nginx UI advisory assigns High severity and includes a fixed setup timeout; the affected product and post-claim capabilities differ from VCF Operations.
Portainer CVE-2026-55761	An uninitialized instance exposed administrator initialization during a five-minute setup window. The maintainer advisory expressly notes that the new instance has no confidential data or running workloads, while still treating unauthorized first-administrator creation as a security issue.	Portainer administrators may later control Docker or Kubernetes environments, creating downstream impact that is product-specific. The Portainer window also expires and reopens on restart.
Jenkins CVE-2026-117618	An unauthenticated account-creation endpoint was available while no users existed during setup. Jenkins classified the resulting administrator-creation race as High severity and added setup-completion validation.	The exploitable interval occurred while the setup wizard replaced an initial account, rather than during the original claim of a newly deployed appliance.
Krayin CRM CVE-2026-41452	An installer endpoint accepted attacker-selected administrator credentials without authentication and was classified as CWE-306.	The installer-middleware bypass could overwrite an administrator on a CRM containing existing data, so its exposure and impact are broader than a first-boot-only condition.
FileRise CVE-2026-57492	Setup state depended on an empty user store, allowing an unauthenticated caller to become administrator when that state reappeared. It illustrates the need for durable, independently protected setup state.	The maintainer explicitly distinguishes ordinary initial setup from the vulnerability: the reported flaw was that setup could reopen after state loss. It is therefore a state-reentry precedent, not a direct first-boot precedent.

The closest comparisons are Nginx UI and Portainer because both advisories require a reachable, uninitialized instance within a limited setup window and describe the first unauthenticated caller establishing administrative control.

Disclosure coordination

The report was submitted privately and investigated by Broadcom VCF PSIRT. After the vendor’s initial determination, HACKZA requested clarification and notified the vendor of an intended independent technical publication. Broadcom’s final response reiterated its classification and did not request an embargo or delayed publication. The correspondence did not contain an explicit grant of publication permission; this advisory is independently published after the vendor completed and clarified its assessment.

Disclosure timeline

Date	Event
2026-09-19	HACKZA privately reported the issue to VMware PSIRT at Broadcom.
2026-09-21	Broadcom acknowledged the report and opened an investigation.
2026-10-29	HACKZA requested an update and proposed a coordinated disclosure timeline.
2026-10-30	Broadcom reported that its investigation was complete and classified the behavior as documented; it also stated that hardening was planned.
2026-11-10	HACKZA requested formal clarification, reconsideration, and CVE assignment, and notified Broadcom of the intended independent publication.
2026-11-10	Broadcom confirmed it would not classify the issue as a vulnerability, issue a CVE, or publish a security advisory.
2026-11-10	KECYBER-SA-2026-001 published independently.

References

No CVE or vendor security advisory was issued for this report.

Credit

Discovered and reported by HACKZA.