Nomad ACLs Can Not Deny Access to Workload's Own Variables

Vulnerability

Description

A vulnerability in HashiCorp Nomad and Nomad Enterprise versions 1.4.0 through 1.5.0 allows a deny ACL policy to be silently ignored when applied to a workload's own variables [3]. This occurs because the access control system does not correctly enforce deny capabilities for variables that a workload accesses via its workload identity, a feature introduced in Nomad 1.4.0 [3]. Despite the presence of a deny policy, the Nomad ACL system may permit access that should be blocked.

Exploitation

An authenticated user or process that can create or modify Nomad policies could exploit this vulnerability by setting a deny rule on a specific variable path [3]. Under normal operation, such a rule would restrict access; however, due to the bug, the deny is not applied when the workload itself (using its own workload identity) attempts to read that variable. The attacker must have sufficient privileges to craft a policy with a deny capability and either be the workload itself or induce a workload to access the variable.

Impact

Successful exploitation allows a workload (or a user acting as that workload) to bypass intended ACL restrictions and access variables that should have been denied [3]. This could lead to unauthorized disclosure of sensitive data stored in Nomad variables, such as secrets or configuration that other workloads or administrators intended to protect.

Mitigation

HashiCorp fixed this vulnerability in Nomad 1.4.6 and 1.5.1 [3]. Users running affected versions should upgrade to these patched releases or later. No workarounds have been published; upgrading is the recommended action [3]. The issue was reported by a member of the HashiCorp OSS community [3].