CVE-2026-12392 Overview
Canonical Metal-as-a-Service (MAAS) contains an information exposure vulnerability [CWE-200] that leaks the Remote Procedure Call (RPC) secret in plaintext through the vendor data metadata endpoint. An unauthenticated attacker who knows or infers a target machine's system ID can query the preseed/metadata server and retrieve the secret. The flaw affects deployments where the register as rack option was enabled during machine deployment. Canonical fixed the issue in MAAS versions 3.4.10, 3.5.14, 3.6.5, 3.7.3, and 3.8.0.
Critical Impact
An unauthenticated network attacker can retrieve the MAAS RPC secret, enabling impersonation of rack controllers and lateral access to the MAAS cluster communication fabric.
Affected Products
- Canonical MAAS versions prior to 3.4.10
- Canonical MAAS 3.5.x prior to 3.5.14, 3.6.x prior to 3.6.5, and 3.7.x prior to 3.7.3
- Canonical MAAS 3.8.x prior to 3.8.0
Discovery Timeline
- 2026-10-02 - CVE-2026-12392 published to the National Vulnerability Database (NVD)
- 2026-10-06 - Last updated in NVD database
Technical Details for CVE-2026-12392
Vulnerability Analysis
MAAS exposes a preseed/metadata server that provisioned machines contact during deployment to retrieve cloud-init style vendor data. When a machine is deployed with the install_rackd (register as rack) option, the vendor data response includes the shared RPC secret used by rack controllers to authenticate to region controllers. The endpoint does not require authentication beyond knowledge of the target machine's system ID, which is a short identifier that can be enumerated or inferred.
An attacker with network reach to the MAAS metadata server can issue a crafted HTTP request against the vendor data endpoint for an eligible system ID and recover the RPC secret in plaintext. Possession of the RPC secret allows an attacker to register rogue rack controllers against the MAAS region, inject commands into the control plane, and potentially pivot into deployment workflows that touch managed machines.
Root Cause
The root cause is sensitive information placement in a response channel that is not adequately protected. The vendor data generator embedded the RPC secret into the preseed metadata to support automated rack controller enrollment. The metadata endpoint relied on obscurity of the system ID rather than enforced authentication, so any party that could reach the endpoint and guess a valid identifier could retrieve the secret.
Attack Vector
Exploitation requires network access to the MAAS metadata/preseed service and a valid machine system ID associated with a deployment that used install_rackd. The attacker sends an HTTP GET request to the vendor data endpoint and parses the returned document for the embedded secret. No credentials and no user interaction are needed.
# Canonical patch excerpt - src/maasserver/api/machines.py
# Deprecates and disables the install_rackd deploy parameter
@param (string) "comment" [required=false] Optional comment for the
event log.
-@param (boolean) "install_rackd" [required=false] If true, the rack
-controller will be installed on this machine.
+@param (boolean) "install_rackd" [required=false] Deprecated. If true, the rack
+controller will be installed on this machine. This feature has been removed and can't be used anymore.
@param (boolean) "install_kvm" [required=false] If true, KVM will be
installed on this machine and added to MAAS.
# Source: https://github.com/canonical/maas/commit/3864ef9dca54e36e3d34d18233b87666b8ee1dc8
The fix disables the install_rackd deployment parameter outright, removing the code path that caused the RPC secret to be rendered into vendor data responses.
Detection Methods for CVE-2026-12392
Indicators of Compromise
- Unexpected HTTP GET requests to MAAS metadata endpoints such as /MAAS/metadata/*/vendor-data from hosts that are not provisioned MAAS clients.
- Rack controller registration events for hostnames or IP addresses not previously known to the MAAS inventory.
- Repeated enumeration patterns against the metadata API using sequential or guessed system IDs.
Detection Strategies
- Alert on anonymous access to the preseed and vendor data endpoints originating from outside the provisioning subnet.
- Correlate rack controller enrollment events in MAAS region logs with the source IPs that previously queried vendor data for the same system ID.
- Baseline normal metadata request volumes per system ID and flag high-cardinality probing.
Monitoring Recommendations
- Forward MAAS region controller logs and nginx/HTTP access logs to a central analytics platform for retention and query.
- Monitor for any machine deployment request that includes the install_rackd parameter after upgrading, since the parameter is now deprecated.
- Track outbound connections from the MAAS region to unexpected endpoints that could indicate a rogue rack controller has registered.
How to Mitigate CVE-2026-12392
Immediate Actions Required
- Upgrade MAAS to a fixed release: 3.4.10, 3.5.14, 3.6.5, 3.7.3, or 3.8.0.
- Rotate the MAAS RPC shared secret after upgrading to invalidate any previously disclosed value.
- Review historical deployments that used the install_rackd option and treat associated system IDs as potentially exposed.
Patch Information
Canonical addressed the vulnerability by deprecating and disabling the install_rackd deployment parameter, removing the code path that embedded the RPC secret in vendor data responses. The relevant upstream commits are published in the Canonical MAAS repository and referenced from Launchpad Bug Report #2153942. Backport commits are available in Canonical MAAS Commit 3864ef9, Canonical MAAS Commit 65e89c0, Canonical MAAS Commit 8489979, Canonical MAAS Commit a9486ad, and Canonical MAAS Commit ead659f.
Workarounds
- Restrict network access to the MAAS metadata and preseed endpoints so only trusted provisioning subnets can reach them.
- Avoid deploying machines with the install_rackd option until the fixed MAAS version is installed.
- Deploy rack controllers manually using out-of-band configuration rather than through the vendor data channel.
# Example firewall restriction limiting MAAS metadata to provisioning subnet
sudo iptables -A INPUT -p tcp --dport 5240 \
-s 10.0.0.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 5240 -j DROP
# After upgrade, rotate the RPC shared secret
sudo maas-region local_config_set --rpc-shared-secret
sudo systemctl restart maas-regiond
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

