Windows junction escape in Go standard library os can create directories outside the root

On Windows, when the target of Root.Mkdir or Root.MkdirAll is a junction pointing to an empty location, the operation can create a directory at the junction target even when that target is located outside the root. This only applies to operations where the last path component is a junction (path/to/junction, but not path/junction/target).

• Go standard library os: affected from 0 with an upper bound of less than 1.26.9, and from 1.27.0-0 with an upper bound of less than 1.27.2.
• Go standard library internal/syscall/windows: affected from 0 with an upper bound of less than 1.26.9, and from 1.27.0-0 with an upper bound of less than 1.27.2.
• The normalized record sets default_status to unaffected outside the listed affected ranges. The status of branches or release lines not listed is not inferred from this record.

In the Go standard library os package, Windows handling in Root.Mkdir and Root.MkdirAll can resolve a final path component that is a junction instead of keeping the operation inside the root. When that junction points to an empty location outside the root, the API can create a directory at the junction target. The weakness is classified as CWE-1386, an insecure operation on a Windows junction or mount point. The Go vulnerability report lists the os and internal/syscall/windows packages; the lower-level symbol identified is internal/syscall/windows.Mkdirat, while the os package includes related Root file-operation methods. The relevant attacker-controlled input is the path supplied to the API, but whether an attacker can control that path depends on the application and is not established by the record. The described condition applies only when the junction is the final path component, such as path/to/junction, not path/junction/target.

The normalized record characterizes the attack as network-reachable, low complexity, requiring no privileges and no user interaction. That characterization does not prove that every deployment exposes a remotely reachable endpoint; the application must still run on Windows and pass attacker-influenced path data to Root.Mkdir or Root.MkdirAll. The junction must be the final path component and must point to an empty location. The supplied record does not identify a public exploit or a known exploited status, and the Go materials reviewed describe the issue and fixes without providing exploit code or a specific abuse report.

The confirmed technical outcome is directory creation outside the intended root, breaking a filesystem boundary on which an application may rely. If the process has permissions over the junction target, it may modify a location that the application did not intend to manage. Integrity or availability effects are possible when the target is security-sensitive, while confidentiality impact depends on additional application behavior that is not described. No specific privilege-escalation, code-execution, or data-theft path is established by the record.

Applications that use os.Root as a filesystem boundary may create directories outside the intended workspace or storage area. This can weaken isolation between tenants, build jobs, caches, or upload areas when those areas process externally influenced paths. Depending on the Windows permissions of the process, possible consequences include unauthorized file placement, configuration changes, data tampering, or service disruption. These are conditional consequences, not a confirmed breach or a demonstrated theft of specific data.

1. Update the Go 1.26 branch to 1.26.9 and the Go 1.27 branch to 1.27.2, the fixed releases identified by the Go sources for this issue.
2. Rebuild and redeploy affected Windows applications with the updated toolchain, then verify that deployed binaries were not built from an affected range.
3. If an update cannot be applied immediately, temporarily prevent untrusted input from selecting a junction as the final path component and do not treat the existing root boundary as sufficient protection for this condition. This is a precaution derived from the trigger, not a vendor-confirmed workaround.
4. For release branches outside the stated ranges, check the applicable CNA or vendor guidance rather than assuming that a fix for one branch applies to every other branch.

1. Inventory Windows applications built with Go and record the toolchain and version used for the deployed builds.
2. Review source code and dependencies for use of os.Root, especially Root.Mkdir, Root.MkdirAll, and related Root operations that receive paths from users or other untrusted sources.
3. Inspect directories that can contain junctions, focusing on a junction in the final path component that points to an empty location outside the intended root.
4. After updating and rebuilding, run application regression tests to verify that the affected APIs no longer resolve a final-component junction outside the root.
5. Monitoring directory creation outside expected boundaries is a precaution, not a known indicator from this record. The absence of matching log evidence does not prove that a system is safe.