[Bug] The `current` junction folder cannot be accessed over SSH since KB5074105

[ZhangTianrong]

Bug Report

Current Behavior

The shims pointing to executables in the current directory can run directly on the host, but over SSH connections, they complain

Shim: Could not determine if target is a GUI app. Assuming console.
Shim: Could not create process with command '"<$HOME/scoop/apps/some-app/current/some-exe>" <args>'

and when the executables are run with the path in the current folder,

The path cannot be traversed because it contains an untrusted mount point.

Running the executables in the non-junction folder (i.e. the one with version number) however doesn't encounter this problem. It is likely that since recent updates, junctions are no longer accessible via SSH.

Expected Behavior

Like before, running the shim will automatically run the app of the current version whether it's on the host directly or over SSH.

Additional context/output

It is very likely junctions are no longer accessible over SSH even when marked as trusted (at least not by default) but junctions are a very important part of scoop for version management.

Possible Solution

I have tried resetting permission as mentioned in #5238 but the problem persists. The cause and temporary solution seem to be

In case someone runs into this issue now and stumbles upon this github issue:

The KB5074105 preview update seems to break junctions over ssh (tested with VSCode remote), even if marked as trusted by the script above. Only uninstalling the update helped so far.

Feedback hub link: https://aka.ms/AAzhjzy

Originally posted by @seritools in #5238

The KB can be removed by running

wusa /uninstall /kb:5074105

and restart.

System details

Windows version: [e.g. 7, 8, 10, 11] 11

OS architecture: [e.g. 32bit, 64bit, arm64] 64bit

PowerShell version: [output of "$($PSVersionTable.PSVersion)"] 7.5.4

Additional software: [(optional) e.g. ConEmu, Git]

Scoop Configuration

{
  "last_update": "2026-02-05T22:27:02.5599184-05:00",
  "aria2-warning-enabled": false,
  "shim": "kiennq",
  "debug": false,
  "aria2-options": "--disable-ipv6",
  "scoop_repo": "https://github.com/ScoopInstaller/Scoop",
  "scoop_branch": "master"
}

[seritools]

Update: They released KB5077181 which also contains this breaking change. great

[jenny923432]

I'm seeing this issue now on the regular non-preview version of Win11 and uninstalling both mentioned updates doesn't fix it. I'm also seeing

PS C:\Users\gal> scoop which ffmpeg
WARN  'ffmpeg' not found, not a scoop shim, or a broken shim.

PS C:\Users\gal> which ffmpeg
C:/Users/gal/scoop/shims/ffmpeg.exe

[hsbt]

Thank you for fileing this. I also faced this issue.

I tried to eable all types of symbolic link evaluations, but this issue is still available unfotunately.

fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1

[cesaryuan]

This issue is very annoying. Is there anyone has solved it yet (uninstalling the update no longer works either)?

[CampinCarl]

I did some testing and I think Microsoft's RedirectionGuard security feature is the culprit here?

Here's a Microsoft blog post explaining the feature.
redirectionguard-mitigating-unsafe-junction-traversal-in-windows

Here's the SSH Daemon on my system (Windows 11) enabling it.

PS C:\> Get-NtProcessMitigations -ProcessId 6020

<PROCESS 6020 - sshd.exe>
  ImagePath: \Device\HarddiskVolume3\Windows\System32\OpenSSH\sshd.exe
  Win32ImagePath: C:\Windows\System32\OpenSSH\sshd.exe
  CommandLine: C:\WINDOWS\System32\OpenSSH\sshd.exe   <- SSH Daemon

(Content clipped for brevity)

[REDIRECTION TRUST]
  EnforceRedirectionTrust: True   <- Process enables RedirectionGuard
  AuditRedirectionTrust: False

From the article, a process will only trust junction traversal in these conditions.

When Redirection Guard is enabled by a process, the process will only follow “trusted” junctions, which are junctions that are one of the following:

1. Were created by an Administrator OR
2. Do not contain the privilege metadata (indicating the junction was last modified prior to the mitigation being available).

You can test this yourself by resetting a Scoop app, e.g., scoop reset git, from an administrator command prompt (which fixes the issue because you're an administrator) and from a standard command prompt (which breaks it again).

This means you can scoop reset * from an administrator command prompt to fix all of your apps, but this is brittle because you'll need to do it anytime you update apps or install new apps. It's also a blunt instrument, because users might have installed (or reset) apps with shim collisions in a particular order such that a particular command "wins", and a wildcard reset might break that? It might be possible to tweak the PS scripts from the other issue thread to work around this though (#5238).

I haven't been able to find a way to toggle RedirectionGuard off for sshd at runtime, and I haven't found any documentation from Microsoft to suggest we can override the behavior for this process. I'm hoping this comment might help someone with better Google/LLM fu find it though.

[seritools]

@CampinCarl I did run the PS script from that other issue as admin, and even then, immediately afterwards, without installing anything else, it was still not working. Did the script work for you at all or just the reset command?

[CampinCarl]

I haven't tested the PS script myself to be honest, as scoop reset app worked for what I needed at the moment.

I suspect the script isn't working because of the way Microsoft set up Reparse Points (Junctions) to store the "privilege metadata" the blog post I linked refers to, specifically an "admin-only alternate data stream"

When junctions are created or modified, the privilege level of the creator/modifier is stored in an admin-only alternate data stream with the file.

I couldn't find any alternate data streams on my current junctions with tools like dir /r or NirSoft's AlternateStreamView. I'm wondering if the acl commands in the script somehow persist the metadata the blog post refers to, or if it's as simple as the ACL setting the owner of the reparse point to a non-administrator? I don't know, I'm still testing.

Hope this helps.

[CampinCarl]

I found a workaround! It's possible to disable the RedirectionGuard security feature for just the sshd.exe process by modifying the Registry. I figure this is probably safe for my use case, as I'm enforcing SSH key access exclusively, but you should consider the security implications for your system and use your best judgement.

Here's a sample Registry Entries file that disables the RedirectionGuard feature for sshd.exe.

Caution

Always be careful when modifying the Registry! Make a backup first!

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sshd.exe]
"MitigationOptions"=hex:00,00,00,00,00,00,00,00,00,10,00,00,00,00,00,00,00,00,10

If you just want to test this for yourself, you're probably good to stop reading here.

---

The relevant part for our purposes is the 0x10 byte in the tenth position, specifically the high-order nibble (the 1). The trailing 0x10 value may or may not be there on your system; I couldn't figure out what it's for.

"MitigationOptions"=hex:00,00,00,00,00,00,00,00,00,10,00,00,00,00,00,00,00,00,10
                                                   ^                          ^
         This `1` disables EnforceRedirectionTrust /                          |
                                                                              |
                 This was set by default on my system, not sure what it does? /

According to ChatGPT/Gemini/etc. the MitigationOptions Registry Key used here is an array of 2-bit configuration "slots", one per mitigation, packed into bytes. Apparently each 2-bit slot should work like this:

Binary	Meaning
00	Use system default
01	Enforce mitigation
10	Disable mitigation
11	Audit (log but don't block)

However, based on my testing, any 2-bit value at this position other than zero (0) disables RedirectionGuard.

Hexadecimal	Binary	Meaning
0x00	00 00 00 00	Use system default
0x10	00 01 00 00	Disable mitigation
0x20	00 10 00 00	Disable mitigation
0x30	00 11 00 00	Disable mitigation

Keep in mind that these are 2-bit slots, so binary 01 00 00 00 / hex 0x40 is the next slot over and therefore doesn't work.

Unfortunately, I couldn't find any documentation on precisely why this works beyond what the LLMs I used were able to infer, so it's possible this could break at some point.

Apparently it should be possible (someday?) to use the Set-ProcessMitigation PowerShell cmdlet for this purpose, but Microsoft hasn't added support for the RedirectionGuard feature yet (likely because it's so new). That's why you need to use Get-NtProcessMitigations to view the setting in the first place, i.e., Get-ProcessMitigation doesn't support it yet.

[seritools]

After three attempts of reinstalling the 2026-03 security update (classic Windows), I managed to do that and can confirm that this indeed works around the issue, thanks!

[nickhutchinson]

I can't find any source that convincingly describes the serialisation of the MitigationOptions registry value. That said, the recent OpenSSH-for-Windows change that enabled Redirection Guard for sshd and ssh-agent looks to be here: https://github.com/PowerShell/openssh-portable/pull/808/changes, and suggests byte 18 is the relevant piece, not byte 9.

[CampinCarl]

Thanks @nickhutchinson, nice find!

I wasn't sure what that final byte did, and since my testing with the slot in byte 9 worked I just stopped there. Turns out zeroing out the entire value also works and is probably more correct here versus what I found (especially given that pull request as documentation!). That is, zeroing it out the value undoes what the install-sshd.ps1 script did.

Here's a revised, zeroed-out Registry Entries file for convenience.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sshd.exe]
"MitigationOptions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

Hope this helps.

---

As to why both positions work, Gemini thinks that the byte 9 position is the system-level setting and the byte 18 position is application-specific. but again, I can't find anything substantive. I suspect it could be set up this way so that running the install script doesn't clobber something the user/administrator explicitly set.

In other words — if, 1) Microsoft adds a toggle to the UI and/or PowerShell cmdlets; and 2) a user explicitly disables Redirection Guard; then 3) installing the OpenSSH Daemon (which runs this script) won't override the user's choice. If this presumption is correct, the original registry entries file I shared is still useful until Microsoft adds a toggle.

---

More digging around, it looks like Microsoft previously used a REG_QWORD for MitigationOptions, but adding the Redirection Guard feature required switching to REG_BINARY for additional space? On my system, only ssh-agent.exe, sshd.exe, wpr.exe, and wprui.exe have the value set this way (everything else is a QWORD).

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<Executable>]
"MitigationOptions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,10