Stashed symlink makes unstash impossible

[salomj]

Jenkins and plugins versions report

Environment

Jenkins: v2.541.3
OS: Ubuntu 22.04.5 LTS
Java: openjdk version "21.0.10" 2026-01-20

What Operating System are you using (both controller, and any agents involved in the problem)?

cat /etc/os-release

PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

java -version

openjdk version "21.0.10" 2026-01-20
OpenJDK Runtime Environment (build 21.0.10+7-Ubuntu-122.04)
OpenJDK 64-Bit Server VM (build 21.0.10+7-Ubuntu-122.04, mixed mode, sharing)

Reproduction steps

1. Create a folder with a symlink
2. Stash the symlink
3. Unstash

This occurs in our node projects which use lerna, as lerna refers to other packages in the project utilizing symlinks in the node_modules folder. We stash the node_modules folder in order to speed up the builds.

Expected Results

Either of the following:

1. Stash should not be able to stash symlinks.
   • Maybe provide a warning and ignore symlinks.
2. Unstash of symlinks is allowed
   • Maybe rework Stash to not have an archive with the security vulnerability.
   • Maybe verify that the symlinks don't have the security vulnerability when extracted.
   • Maybe allow archives to extract symlinks in archives that were created by Jenkins and known to not have symlinks with the security vulnerability.

Actual Results

An exception is thrown: identifying content removed and surrounded in <>.

java.io.IOException: Tar install.tar.gz attempts to write to file with symlink in path: node_modules/<path/to/other/lerna/package>/CHANGELOG.md
	at Jenkins v2.541.3//hudson.FilePath.readFromTar(FilePath.java:3092)
Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to <agent.server.address>
		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1916)
		at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:384)
		at hudson.remoting.Channel.call(Channel.java:1108)
		at hudson.FilePath.act(FilePath.java:1217)
		at hudson.FilePath.act(FilePath.java:1206)
		at hudson.FilePath.untar(FilePath.java:618)
		at PluginClassLoader for workflow-api//org.jenkinsci.plugins.workflow.flow.StashManager.unstash(StashManager.java:162)
		at PluginClassLoader for workflow-basic-steps//org.jenkinsci.plugins.workflow.support.steps.stash.UnstashStep$Execution.run(UnstashStep.java:78)
		at PluginClassLoader for workflow-basic-steps//org.jenkinsci.plugins.workflow.support.steps.stash.UnstashStep$Execution.run(UnstashStep.java:65)
		at PluginClassLoader for workflow-step-api//org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:49)
		at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
Also:   org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: 0bebd5c1-5087-422b-9669-135ed238a3ad
Caused: java.io.IOException: Failed to extract install.tar.gz
	at Jenkins v2.541.3//hudson.FilePath.readFromTar(FilePath.java:3121)
	at Jenkins v2.541.3//hudson.FilePath.readFromTar(FilePath.java:3057)
	at Jenkins v2.541.3//hudson.FilePath$UntarRemote.invoke(FilePath.java:637)
	at Jenkins v2.541.3//hudson.FilePath$UntarRemote.invoke(FilePath.java:624)
	at Jenkins v2.541.3//hudson.FilePath$FileCallableWrapper.call(FilePath.java:3631)
	at hudson.remoting.UserRequest.perform(UserRequest.java:225)
	at hudson.remoting.UserRequest.perform(UserRequest.java:50)
	at hudson.remoting.Request$2.run(Request.java:391)
	at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:81)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)

Anything else?

This broke because of this security update: https://www.jenkins.io/security/advisory/2026-03-18/#SECURITY-3657

Are you interested in contributing a fix?

No response

[MilanTyagi2004]

Hi @salomj,

I’d like to take this issue.

From what I understand, this behavior is a side-effect of the fix introduced in SECURITY-3657, where Jenkins now blocks extraction of archives if a symlink exists anywhere in the path to prevent arbitrary file write vulnerabilities .

Problem Breakdown

• stash allows symlinks to be archived.
• unstash fails because extraction now rejects any path containing symlinks.
• This breaks valid workflows (e.g., Lerna / node_modules) where symlinks are expected and safe.

Proposed Approach

I’m considering the following directions:

1. Handle symlinks during stash (preferred)

   • Detect symlinks while creating the stash archive

   • Either:

     • Skip them with a warning, or
     • Store metadata instead of raw symlinks

2. Safe extraction validation

   • Allow symlinks only if:

     • They resolve within the workspace
     • They don’t escape the target directory

   • This preserves security guarantees while allowing valid use cases

3. Optional configuration (fallback)

   • Introduce a flag like allowSafeSymlinks
   • Default remains secure, but users can opt-in for controlled environments

Goal

Maintain the security guarantees introduced by SECURITY-3657 while restoring compatibility for common development workflows that rely on symlinks.

Let me know if this direction sounds good, or if you’d prefer a stricter approach (e.g., always skipping symlinks during stash).

I can start with a PR once aligned.

[daniel-beck]

Thanks for your report.

Create a folder with a symlink
Stash the symlink
Unstash

It's not quite as simple as that, but still too simple 😞

node('a1') {
    sh 'rm -rf top/ ; mkdir -p top/sub top/sub2 ; ln -s ../sub2 top/sub/subsub ; date > top/sub2/file'
    stash includes: 'top/**', name: 'foo'
    unstash 'foo'
}

causes

java.io.IOException: Tar foo.tar.gz attempts to write to file with symlink in path: top/sub/subsub/file
	at Jenkins v2.557//hudson.FilePath.readFromTar(FilePath.java:3092)

which seems unexpected; this may be a bug in the code for archive creation. Declaring an entry to be a symlink and then collecting its children seems wrong.

[daniel-beck]

The archive code does not pass LinkOption.NOFOLLOW_LINKS to Dirscanner.Glob, so it follows symlinks -- an option the security fix does not handle well.

I see two options forward:

• Look into restricting the write-through check to only fail on symlinks leaving the root.
• (Perhaps optionally) change the behavior of stashing to not collect files through symlinks. That seems like a weird thing to do. But this could break some existing use cases that rely on symlinks to collect files to archive. OTOH, the unarchival would look really odd then it seems?

[timja]

1. Look into restricting the write-through check to only fail on symlinks leaving the root.
   Seems sensible.

2. change the behavior of stashing to not collect files through symlinks
   Agreed that it sounds sensible but is more risky if people are depending on that.

[salomj]

2. Safe extraction validation

   • Allow symlinks only if:

     • They resolve within the workspace
     • They don’t escape the target directory

   • This preserves security guarantees while allowing valid use cases

I believe this to be the ideal approach, but I'm willing to accept any solution that doesn't break unstash.

[MilanTyagi2004]

@salomj i will start working on this.