CVE-2024-6717 is a high severity (CVSS 7.7) flaw in HashiCorp Nomad and Nomad Enterprise, where archive unpacking during allocation migration can write outside the allocation directory. It affects 1.6.12 through 1.7.9 and 1.8.1. HashiCorp fixed it in 1.6.13, 1.7.10 and 1.8.2.
What's affected
HashiCorp bulletin HCSEC-2024-15 lists Nomad and Nomad Enterprise 1.6.12 up to 1.7.9, and 1.8.1, as affected. The fixed releases are 1.6.13, 1.7.10 and 1.8.2, or newer.
The bulletin says the issue came from HashiCorp's internal testing. It does not state that the flaw has been exploited in the wild. The record gives no KEV flag. The CPE entries cover both the open source and enterprise editions.
How to check if you're exposed
On each server and client node, check the version:
nomad version
Compare it with the ranges above. Versions 1.6.12 to 1.7.9 and exactly 1.8.1 are affected. Older 1.6.x releases before 1.6.12 are not listed.
Migration is the trigger, so also review jobs that use ephemeral disk migration or sticky volumes, because those are the cases where an allocation directory is moved between clients. Clusters that do not use migration have a lower exposure, though HashiCorp still advises assessing risk and upgrading.
What to do now
- Inventory Nomad servers and clients, including Enterprise nodes, and record their versions.
- Upgrade to 1.6.13, 1.7.10 or 1.8.2, following HashiCorp upgrade documentation.
- Upgrade clients as well as servers, since unpacking happens on the client side.
- Review which jobs use allocation migration and who may submit jobs.
- Restrict job submission rights to trusted users with ACLs until the upgrade is done.
Why it matters
The record classifies this as CWE-610, externally controlled reference to a resource in another sphere. In plain terms, the unpacking code accepted paths inside an archive without making sure they stayed inside the allocation directory. A crafted archive can then place files elsewhere on the client host.
The score is 7.7 with a changed scope, low privileges, network access, and high integrity impact only. That fits the practical risk: a user who can run jobs may be able to write files outside the sandbox that the job is supposed to live in. On a shared cluster, the sandbox boundary is what the scheduler sells. Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan for checking the packages your own projects pull in.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to upgrade servers and clients?
HashiCorp advises upgrading to a fixed version. The unpacking happens during migration on the client, so upgrade both.
Is it exploited?
The bulletin does not say so, and the record has no known exploited flag.
Sources
Last reviewed: 19 October 2026.
