CVE-2026-80462 · A vulnerability in the Chef Automate API gateway and identity valid…

01 · The Real Story

Someone left the master key to your entire puppet show hanging on the front door

CVE-2026-80462 is a missing-authentication flaw (CWE-306) in the Chef Automate API gateway's identity validation path. Versions 4.13.516 through 4.13.519 improperly verify trust tokens exchanged between internal microservices, allowing an unauthenticated remote attacker to craft requests directly to private endpoints and gain administrative access to Chef Automate functionality. Chef 360, Chef Infra Server, and versions prior to 4.13.516 are not affected. The fix is Chef Automate 4.13.520. Progress has already patched all SaaS-hosted instances; on-premises deployments require manual upgrade.

The vendor's CVSS 10.0 is technically faithful to the vector — network-accessible, zero-complexity, no auth, no user interaction, scope-changed, full CIA impact. In a vacuum that score is correct. Where reality diverges is the four-version window: only builds 4.13.516–519 carry the bug, so the fraction of the Chef Automate installed base actually exposed is smaller than a product-wide vuln would create. That said, Chef Automate is an infrastructure automation control plane — compromise here means pushing arbitrary cookbooks and run-lists to every managed node. The blast radius, when it hits, is fleet-scale. noisgate holds the CRITICAL floor but trims the score to 9.2 to reflect the narrow exposure population.

"Unauthenticated gateway bypass on your fleet's command-and-control plane — narrow version window is the only saving grace."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Reach the Chef Automate API gateway

The attacker identifies a Chef Automate instance reachable over the network. In most enterprises this is an internal HTTPS endpoint (typically port 443) used by ops teams, CI runners, and reporting dashboards. External exposure is uncommon but not impossible — Shodan queries for Chef Automate historically return low-hundreds of results.

Conditions required:

Network path to Chef Automate HTTPS endpoint (port 443)

Where this breaks in practice:

Most deployments sit behind a corporate firewall or VPN; direct internet exposure is rare
Network segmentation or ZTNA may block lateral movement to the management VLAN

Detection/coverage: Shodan/Censys dork for Chef Automate login pages; internal asset inventory should flag all Automate instances

STEP 02

Craft a forged internal trust-token request

The attacker sends a specially crafted HTTP request to the API gateway that mimics an internal microservice-to-microservice call. Because versions 4.13.516–519 fail to validate the trust token, the gateway treats the request as originating from a trusted internal component. No credentials, cookies, or API keys are required.

Conditions required:

Target runs Chef Automate 4.13.516–4.13.519
Knowledge of internal API endpoint paths (discoverable via documentation or enumeration)

Where this breaks in practice:

Only four patch versions are vulnerable — many environments may be on older or already-patched builds
No public PoC simplifies this today, but the attack surface (REST API) is well-documented

Detection/coverage: WAF rules inspecting for anomalous trust-token headers; Chef Automate audit logs showing unauthenticated admin-level API calls

STEP 03

Gain administrative access to Chef Automate

With the forged trust token accepted, the attacker now has elevated privileges within Chef Automate. This grants read/write access to all managed node data, compliance reports, credentials stored in data bags, and — critically — the ability to modify cookbooks and run-lists.

Conditions required:

Successful trust-token bypass from Step 2

Where this breaks in practice:

None once Step 2 succeeds — the gateway grants full admin context

Detection/coverage: Anomalous admin session creation without corresponding SSO/LDAP authentication event; SIEM correlation on Chef Automate audit feed

STEP 04

Push malicious cookbooks to managed fleet

The attacker uploads a modified cookbook or alters an existing run-list to include arbitrary commands. On the next Chef client convergence cycle (typically every 30 minutes), every managed node pulls and executes the attacker's payload with root/SYSTEM privileges. This is fleet-scale code execution.

Conditions required:

Admin access to Chef Automate (achieved in Step 3)
Managed nodes configured to converge automatically

Where this breaks in practice:

Organizations using cookbook version pinning and promotion gates add a manual approval step
Chef client ssl_verify_mode :verify_peer with pinned certs may reject tampered server responses in hardened configs

Detection/coverage: Cookbook version diff alerts; file-integrity monitoring on cookbook artifacts; EDR on managed nodes detecting unexpected child processes from chef-client

STEP 05

Establish persistence and lateral movement

With code execution on every managed node, the attacker harvests credentials (data bags, encrypted secrets, service accounts), installs backdoors, and moves laterally to systems not managed by Chef. If the Chef Automate instance also stores cloud credentials or CI/CD tokens, the blast radius extends to cloud accounts and build pipelines.

Conditions required:

Successful cookbook push from Step 4

Where this breaks in practice:

Encrypted data bags with external key management limit credential exposure
EDR/XDR on endpoints may detect post-exploitation tooling

Detection/coverage: EDR behavioral alerts on managed nodes; credential-use anomaly detection; network-layer east-west traffic monitoring

03 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	None confirmed. Progress states no active exploitation has been observed. Not listed on CISA KEV as of 2026-09-12.
Proof-of-Concept	No public PoC exists. No repositories on GitHub or ExploitDB reference working exploit code. The attack surface (REST API with trust-token forgery) is conceptually straightforward, so weaponization timelines could be short once researchers reverse the patch diff.
EPSS Score	Not yet scored. CVE was disclosed 2026-09-11; FIRST EPSS model has not ingested it yet. Expect initial score within 7–14 days.
KEV Status	Not listed. No CISA KEV entry as of 2026-09-12.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H` — Perfect 10.0. Scope: Changed means the attacker can impact resources beyond the vulnerable component (i.e., managed nodes). Every metric is worst-case.
Affected Versions	Chef Automate 4.13.516, 4.13.517, 4.13.518, 4.13.519. Versions prior to 4.13.516 and Chef 360 / Chef Infra Server are not affected.
Fixed Version	Chef Automate 4.13.520. SaaS instances already patched by Progress. On-premises requires manual upgrade.
Scanning / Exposure	Chef Automate is predominantly deployed on internal networks. Historical Shodan/Censys scans show low-hundreds of internet-facing instances globally. No GreyNoise tags for this CVE yet.
Disclosure Date	2026-09-11 (vendor advisory and CVE publication simultaneous).
Reporter	Not publicly attributed. Progress advisory does not name a researcher or coordinating organization.

04 · The Call

noisgate verdict.

Final Verdict

= UNCHANGED to CRITICAL (9.2/10)

Chef Automate is canonically a fleet-control-plane component — compromise grants arbitrary code execution on every managed node, making the blast radius fleet-scale by definition. The single most decisive factor sustaining the CRITICAL floor is the role multiplier: this bug lives in an infrastructure automation platform where ≥90% of installs serve the high-value orchestration role, and the chain requires zero authentication, making the narrow version window the only downward pressure (score trimmed from 10.0 to 9.2).

HIGH Vulnerability existence and affected version range

HIGH Attack vector characterization (unauthenticated, network-accessible)

MEDIUM Real-world exposure population (narrow version range limits it, but exact adoption of 4.13.516–519 is unknown)

LOW Exploitation timeline (no PoC today, but patch diffing is straightforward)

Why this verdict

Zero-auth, zero-complexity network attack: The CVSS vector is a clean sweep — no credentials, no user interaction, low complexity. Any attacker with network access to the gateway can exploit this.
Role multiplier — fleet-scale blast radius: Chef Automate is an infrastructure automation control plane. Compromise equals pushing arbitrary code to every managed node with root/SYSTEM. This is not a single-host bug; it is a domain-takeover-equivalent for the infrastructure layer. ≥90% of Chef Automate installs exist specifically to serve this orchestration role, exceeding the 10% high-value-role threshold by a wide margin. The floor is CRITICAL.
Narrow version window provides the only meaningful friction: Only four patch versions (4.13.516–519) carry the flaw. Organizations on older trains or those that auto-updated past 519 are unaffected. This limits the exposed population and justifies trimming the score from 10.0 to 9.2, but does not break the CRITICAL floor.
No PoC and no exploitation — yet: Disclosed yesterday with no public exploit code. This buys defenders a short window, but the attack surface (REST API, trust-token header forgery) is amenable to rapid weaponization once the patch is diffed.

Why not higher?

The score is already near-maximum at 9.2. A full 10.0 would require broad version exposure across the installed base; the four-version window meaningfully narrows the reachable population. Additionally, no public PoC or in-the-wild exploitation exists yet, which tempers immediacy slightly.

Why not lower?

Dropping below CRITICAL would require evidence that the fleet-control-plane blast radius is somehow contained, but it is not — Chef Automate's entire purpose is to push configuration and code to managed nodes. The unauthenticated, low-complexity attack vector with scope-changed impact on a canonically high-value-role component locks the floor at CRITICAL. The narrow version range limits *who* is vulnerable, not *how bad* it is when they are.

05 · Compensating Control

What to do — in priority order.

Restrict API gateway access to trusted IPs immediately — Apply firewall rules or security-group changes to limit inbound HTTPS (port 443) to the Chef Automate instance to only known admin workstations, CI runners, and managed-node subnets. This is the highest-leverage mitigation — if the attacker cannot reach the gateway, the chain dies at Step 1. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL.
Enable and monitor Chef Automate audit logging — Ensure the audit log stream is enabled and forwarded to your SIEM. Alert on any admin-level API calls that lack a corresponding SSO/LDAP authentication event. This provides detection coverage for bypass attempts. Deploy within 3 days.
Pin cookbook versions and require manual promotion — Configure your Chef workflow to require explicit version pinning and human approval before cookbook changes propagate to production environments. This breaks the attacker's ability to silently push malicious code to the fleet even if they gain admin access. Deploy within 3 days.
Rotate Chef Automate secrets and data-bag keys — After patching, assume the instance may have been accessed. Rotate all API tokens, data-bag encryption keys, and any credentials stored within Chef Automate. This limits the value of any exfiltrated material.

What doesn't work

WAF signature blocking alone — the forged trust-token request uses standard HTTPS to a legitimate API path. Without a specific signature for the malformed token (which requires knowing the exact exploit format, unavailable without a PoC), generic WAF rules will not catch this.
Chef client SSL verification — while ssl_verify_mode :verify_peer protects node-to-server communication integrity, it does not prevent an attacker who has already gained admin access from legitimately signing and pushing cookbooks through the normal workflow.
Network-layer IDS/IPS — the traffic is encrypted HTTPS to a legitimate endpoint; content inspection is not possible without TLS termination, and even then the request structure is valid API traffic.

06 · Verification

Crowdsourced verification payload.

Run this script on each Chef Automate server (requires shell access and the chef-automate CLI in PATH). Invoke with: sudo bash check_cve_2026_80462.sh. Requires root or equivalent to read the Automate version.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_80462.sh
# Checks whether the local Chef Automate instance is vulnerable to CVE-2026-80462
# Requires: root/sudo, chef-automate CLI in PATH
# Outputs: VULNERABLE / PATCHED / UNKNOWN

set -euo pipefail

VULN_MIN="4.13.516"
VULN_MAX="4.13.519"
FIXED="4.13.520"

if ! command -v chef-automate &>/dev/null; then
  echo "UNKNOWN — chef-automate CLI not found in PATH. Is this a Chef Automate server?"
  exit 2
fi

VERSION=$(chef-automate version 2>/dev/null | grep -oP '\d+\.\d+\.\d+' | head -1)

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN — could not determine Chef Automate version."
  exit 2
fi

# Version comparison helper
ver_cmp() {
  printf '%s\n%s' "$1" "$2" | sort -V | head -1
}

LOWER=$(ver_cmp "$VERSION" "$VULN_MIN")
UPPER=$(ver_cmp "$VERSION" "$VULN_MAX")

if [[ "$LOWER" == "$VULN_MIN" && "$UPPER" == "$VERSION" ]] && \
   [[ "$VERSION" != "$(ver_cmp "$VERSION" "$FIXED")" || "$VERSION" == "$FIXED" ]]; then
  # Version >= VULN_MIN. Now check if < FIXED
  BELOW_FIXED=$(ver_cmp "$VERSION" "$FIXED")
  if [[ "$BELOW_FIXED" == "$VERSION" && "$VERSION" != "$FIXED" ]]; then
    echo "VULNERABLE — Chef Automate $VERSION is in the affected range ($VULN_MIN–$VULN_MAX). Upgrade to $FIXED+."
    exit 1
  else
    echo "PATCHED — Chef Automate $VERSION is at or above the fixed version ($FIXED)."
    exit 0
  fi
else
  echo "PATCHED — Chef Automate $VERSION is below the affected range (pre-$VULN_MIN) and not vulnerable."
  exit 0
fi

07 · Bottom Line

If you remember one thing.

TL;DR

If you run Chef Automate on-premises, check your version today — only builds 4.13.516 through 4.13.519 are affected. If you're in that window, this is a drop-everything patch. Per the noisgate mitigation SLA for CRITICAL, restrict network access to the API gateway to trusted IPs within 3 days and enable audit-log alerting for unauthenticated admin calls. Per the noisgate remediation SLA, apply the vendor patch (upgrade to 4.13.520+) within 90 days, though given the zero-auth attack vector and fleet-scale blast radius, you should realistically push the upgrade this week. If you're on a version prior to 4.13.516 or running SaaS, you're clear — Progress already patched hosted instances. After patching, rotate all secrets and API tokens stored in Automate as a precaution.

Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only

0 flags selected · stored anonymously

Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.