CVE-2026-5061: HashiCorp Consul Template's sandbox_path Bypass Through a Symlink TOCTOU

Intro

I found this issue while reviewing HashiCorp Consul Template, with a very specific security question in mind:

If sandbox_path validates a symlink during template evaluation, does the later file read stay bound to that same validated target?

In this case, the answer was no.

The file template helper resolved the path and enforced the configured sandbox during template evaluation. But after that check, it created a file dependency using the original raw path.

That dependency was fetched later.

If an attacker retargeted the symlink in the gap between validation and dependency fetch, Consul Template could read an out-of-sandbox file. If the link was restored before the next render, sandbox validation passed again and the cached external content was still rendered.

That issue became CVE-2026-5061.

HashiCorp bulletin: HCSEC-2026-12
IBM bulletin: CVE-2026-5061 security bulletin
CVE: CVE-2026-5061
Fixed in: 0.42.0

Attack Chain

attacker-controlled in-sandbox symlink -> sandbox validation resolves to safe target -> dependency stores original raw path -> attacker retargets link outside sandbox -> dependency fetch reads external file -> attacker restores safe link -> next validation passes -> cached external content is rendered

What Consul Template Does

Consul Template is a template rendering tool for Consul and Vault data.

It can run continuously, watch dependencies for changes, and render data into files or environment variables for applications to consume.

The file template helper reads a local file and inserts its contents into rendered output.

Because local file reads can expose process-readable secrets, Consul Template provides sandbox_path as a boundary for this helper.

The documented security property is straightforward:

• paths passed to file must fall inside the configured sandbox
• relative paths must not escape the sandbox
• linked targets must not turn an allowed path into an external file read

That makes sandbox_path a real security boundary.

The important question was not whether the path looked like it was under the sandbox.

The real question was:

Does the file that gets read remain the same file that passed sandbox validation?

In vulnerable versions, it did not.

Why This Surface Was Worth Looking At

Filesystem sandboxes often fail at the gap between path validation and file access.

The common pattern is:

• validate a path
• release control back to the filesystem
• use the path again later
• assume it still identifies the same object

That assumption is unsafe when an attacker can modify a symlink or equivalent filesystem redirection between the two operations.

Consul Template made this surface especially interesting because template evaluation and dependency fetching were separate stages.

That separation created the right security question:

Is the dependency fetch bound to the validated target, or does it resolve the attacker-controlled path again?

That was the boundary I focused on.

Root Cause

The root cause was a time-of-check to time-of-use mismatch between:

• sandbox validation in template/funcs.go
• the later dependency read in dependency/file.go

At the tested revision, fileFunc() did this:

normalized := strings.TrimSpace(s)
err := pathInSandbox(sandboxPath, normalized)
if err != nil {
    return "", err
}
 
d, err := dep.NewFileQuery(s)

The validation helper correctly resolved symlinks before checking containment:

sandboxResolved, err := filepath.EvalSymlinks(filepath.Clean(sandbox))
targetResolved, err := filepath.EvalSymlinks(filepath.Clean(path))
 
rel, err := filepath.Rel(sandboxResolved, targetResolved)
if rel == ".." || strings.HasPrefix(rel, ".."+string(filepath.Separator)) {
    return fmt.Errorf("'%s' is outside of sandbox", path)
}

So the sandbox check itself understood the resolved target.

But that resolved target was discarded.

NewFileQuery() stored the original string instead:

return &FileQuery{
    stopCh: make(chan struct{}, 1),
    path:   s,
}, nil

Then the later dependency fetch read that path again:

data, err := os.ReadFile(d.path)

That is the whole vulnerability.

The code checked one filesystem resolution, then later used another.

Why this is exploitable

Because a symlink is mutable.

The attacker does not need to make an out-of-sandbox target pass pathInSandbox() directly.

They only need to change what the already-approved raw path resolves to after validation but before Fetch() performs the read.

The sequence is:

• the link resolves to a safe file during pathInSandbox()
• validation succeeds
• FileQuery records the raw link path
• the link is replaced or retargeted to an external file
• os.ReadFile(d.path) resolves the link again
• the outside file is read
• the fetched value is cached in the template brain
• the link is restored before the next template evaluation
• validation succeeds again
• cached external content is returned and rendered

That last step is important.

Restoring the safe link did not remove the already-fetched secret from the dependency cache.

What Makes This a Security Issue, Not Just a Filesystem Race

The important distinction is bypass of an explicit security control.

This was not merely:

"the file changed while Consul Template was watching it"

Watching files for changes is expected behavior.

The real issue was:

a path that passed the documented sandbox restriction could later be used to read a file outside that sandbox

That is a direct trust-boundary failure.

The application had already made a security decision:

• this target is inside the sandbox
• therefore it is safe to register and fetch

But the later fetch was not tied to the target that justified that decision.

That is what turned ordinary filesystem mutability into a vulnerability.

Proof of Concept

I built a standalone reproducer around the exact evaluation and dependency-fetch sequence.

The controlled setup used:

• a configured sandbox directory
• a safe file inside that sandbox
• a secret file outside the sandbox
• a watched symlink path inside the sandbox
• deterministic link swaps around the dependency fetch

The reproduction flow was:

1. Point the watched symlink at the safe in-sandbox file.
2. Evaluate the file helper so sandbox validation succeeds and the raw path is registered as a dependency.
3. Retarget the watched symlink to the outside secret before dependency fetch.
4. Run the dependency fetch and allow os.ReadFile(d.path) to read through the redirected link.
5. Store the fetched value in the template cache.
6. Restore the symlink to the safe in-sandbox file.
7. Evaluate the template again.
8. Confirm sandbox validation still succeeds.
9. Confirm the rendered output contains the previously fetched outside secret.

The observed behavior was:

• initial sandbox validation passed
• the dependency retained the original link path
• the fetch read the out-of-sandbox file after the link changed
• the safe target was restored before the next render
• the next sandbox check passed
• the rendered output matched the external secret exactly by SHA-256

That hash comparison mattered.

It proved that the final rendered value was not stale safe content, a filename artifact, or an error-path side effect.

It was the byte-exact content of the out-of-sandbox file.

Why the PoC Was Chosen This Way

The strongest proof for a TOCTOU issue must control the timeline.

Simply showing that a symlink can point outside the sandbox would be weaker because pathInSandbox() already rejected an external target when it observed one.

The security claim depended on proving all of these states in order:

• safe at validation time
• unsafe at fetch time
• safe again at render time
• external content still consumed from cache

That is why the reproducer separated template validation, dependency fetch, link restoration, and the next render explicitly.

The PoC did not rely on random timing or repeated guessing.

It drove the vulnerable lifecycle deterministically.

That made the root cause and the impact much easier to defend.

Exploitation Requirements and Scope

This issue requires local filesystem influence.

An attacker needs enough access to create, replace, or retarget the relevant symlink or equivalent linked path during the vulnerable window.

The Consul Template process must also:

• have permission to read the external target
• evaluate a template using the attacker-influenced path
• expose the rendered result somewhere the attacker can recover or influence its use

Those requirements matter.

This was not an unauthenticated remote arbitrary file read from any default deployment.

But within the affected local trust model, the impact was meaningful:

• bypass of the documented sandbox_path restriction
• out-of-sandbox local file disclosure
• possible exposure of secrets readable by the Consul Template process

The risk increases when the process runs with access to sensitive credentials, service configuration, tokens, or private keys.

Severity and Classification

HashiCorp classified the issue as:

• CWE-59: Improper Link Resolution Before File Access
• CVSS 3.1:

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

The published base score is:

4.7 / Medium

That scoring reflects the real constraints:

• local attack vector
• low privileges required to influence the path
• high attack complexity because the link must change during the relevant lifecycle window
• no victim interaction required
• high confidentiality impact if a sensitive process-readable file is fetched

That is a reasonable classification.

The issue is narrow in attacker prerequisites, but the sandbox bypass and resulting file disclosure are both concrete.

Affected Versions

The HashiCorp bulletin lists:

Affected: consul-template up to 0.41.4
Fixed:    consul-template 0.42.0

The fix shipped in the 0.42.0 release on April 15, 2026.

Fix Analysis

The fix was small and directly addressed the broken binding.

Instead of validating the resolved target and then building the dependency from the raw input, the patched code returns the resolved path and gives that path to NewFileQuery():

resolvedPath, err := resolveSandboxedPath(
    sandboxPath,
    strings.TrimSpace(s),
)
if err != nil {
    return "", err
}
 
d, err := dep.NewFileQuery(resolvedPath)

The security property changed from:

• validate resolved target
• discard resolved target
• fetch through raw path later

to:

• validate resolved target
• retain resolved target
• fetch through that validated path

That closes the reported symlink-retargeting path because changing the original link no longer changes the path stored by the dependency.

The patch also added a focused regression test covering the exact sequence:

• safe symlink during validation
• external symlink during fetch
• safe symlink restored before the next call
• cached external secret must not be returned

That is the kind of remediation you want for this bug:

• fix the broken validation/use binding
• preserve the sandbox behavior
• add a regression test for the full race lifecycle

Disclosure

I reported this issue privately to HashiCorp Security on March 20, 2026.

The report included:

• source-level root cause analysis
• the validation-to-fetch TOCTOU sequence
• a standalone deterministic reproducer
• runtime output
• SHA-256 evidence showing the rendered data matched the external secret
• affected revision details

HashiCorp fixed the issue in 0.42.0 and published HCSEC-2026-12 on May 12, 2026.

IBM published a corresponding security bulletin for the same CVE.

Both official bulletins acknowledged the report as:

Mohamed Abdelaal (0xmrma)

What This Bug Actually Teaches

The key lesson is simple:

validating a path is not enough if the later file operation can resolve that path to a different object

That rule applies far beyond Consul Template.

It matters anywhere code does:

• sandbox checks
• upload destination checks
• archive extraction
• local secret reads
• temporary-file handling
• privilege-separated file operations

The deeper security property is not:

"the path string looked safe once"

It is:

the object used by the sensitive operation must be the object that passed validation

In this case, Consul Template validated one resolution and fetched another.

That gap was enough.

Key Points

• sandbox_path was an explicit local-file security boundary
• pathInSandbox() resolved and validated the symlink target correctly
• the resolved target was discarded after validation
• FileQuery retained the original attacker-influenced path
• dependency fetch later resolved that path again through os.ReadFile
• restoring the safe link did not remove the already-cached external content
• the PoC proved byte-exact out-of-sandbox disclosure with SHA-256
• version 0.42.0 fixed the bug by binding the dependency to the resolved, validated path

Final Words

This vulnerability was not about bypassing a string-prefix check.

It was about time and identity.

Consul Template checked where the link pointed during template evaluation. The dependency fetch later asked the filesystem the same question again. An attacker could change the answer between those two moments.

That is why this became CVE-2026-5061.

Fixed in consul-template 0.42.0.