CVE-2026-39822

What it actually does

This is a Unix-specific path traversal / sandbox escape flaw in code that uses Go's os.Root-style file access boundary. When the final component of a requested path is a symbolic link and the path ends with a trailing slash, the open operation can follow that symlink outside the intended root directory. A local authenticated attacker, or attacker who can influence filesystem contents and requested paths, may cause the application to read, modify, or operate on files outside the constrained root. The CVSS vector indicates local access, low complexity, low privileges required, no user interaction, and potentially high confidentiality, integrity, and availability impact.

Why it matters to the business

Applications that rely on os.Root as a filesystem containment boundary may unintentionally expose host files outside the intended directory. In practical terms, this can lead to unauthorized disclosure of sensitive files, tampering with application or system data, or disruption if critical files are modified or removed. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity reported, and has a low stable EPSS score, but the potential impact is high where untrusted users can create symlinks or control paths passed to affected file-opening logic.

How an attack unfolds

An attacker first gains the ability to interact with an application feature that writes files, extracts archives, mounts workspaces, processes uploaded content, or otherwise allows symlinks to exist inside a directory that the application treats as a restricted root. The attacker creates or introduces a symbolic link inside that root pointing to a sensitive location outside it, such as a system directory, application configuration directory, credential store, or another user's data. They then cause the application to open that symlink as the final path component with a trailing slash. Because the affected logic improperly follows the final symlink despite the root boundary, the application opens the target outside the intended root. The attacker can then use the application's privileges to read, write, enumerate, delete, or otherwise affect files that should have been inaccessible.

How to fix it

Upgrade to a vendor-fixed Go toolchain/runtime or downstream package version as soon as one is available, then rebuild and redeploy all applications that include the affected filesystem logic. Because no exact fixed versions were provided in the input, track the upstream Go security advisory and distribution/package-manager advisories for the corrected release. As compensating controls, avoid passing attacker-controlled paths directly to os.Root open operations, reject paths whose final component is a symlink, normalize and validate paths before use, reject trailing-slash access to untrusted final path components, disable or strip symlinks during archive extraction or upload processing, and perform explicit post-open verification that the resolved file remains within the intended root. On Unix systems, additionally restrict write permissions inside trusted roots and run affected applications with least-privilege OS accounts to reduce blast radius.

How to confirm the fix worked

Confirm that all affected applications have been rebuilt with a patched Go version or fixed downstream dependency. On Unix test systems, create a restricted root directory, place a symlink inside it pointing to a known directory outside the root, and attempt to open the symlink as the final path component with a trailing slash through the application code path. A fixed implementation should reject the operation or otherwise prevent access outside the root. Validate that archive upload, workspace, plugin, backup, and file-management features reject symlinks or enforce root containment. Use software composition analysis, build metadata, container image inspection, and Go module/toolchain inventory to identify binaries built with vulnerable versions once fixed-version data is available.

Typical attack path

1. Identify an application on Unix that uses affected os.Root-style filesystem confinement.
2. Obtain low-privileged local access or access to an application workflow that accepts user-controlled files, directories, archives, or path names.
3. Place or cause creation of a symbolic link inside the restricted root directory that points outside the root.
4. Submit or trigger a file operation where the symlink is the final path component and the path ends with a trailing slash.
5. Abuse the escaped file handle to access or manipulate files outside the intended root with the application's privileges.
6. Use the unauthorized access for data theft, configuration tampering, privilege escalation support, or service disruption.

How to detect it

There are no universal product-wide indicators of compromise because exploitation depends on application-specific paths and logging. To assess prior exploitation, review application audit logs, file access logs, endpoint telemetry, and shell history for creation of symbolic links inside directories intended to be restricted roots, especially symlinks pointing to sensitive locations outside those roots. Correlate symlink creation events with subsequent application file-open, read, write, delete, archive extraction, backup, or file-management actions where the requested path ends in a trailing slash. On Linux, use EDR, auditd, osquery, or filesystem metadata to identify symlinks under application-controlled roots whose targets are absolute paths or contain upward traversal. Investigate any access by affected application processes to files they normally should not touch, such as system configuration, secrets, SSH material, service credentials, application configuration outside the working directory, or other users' data. If named threat actors or exploit tooling become associated with this issue later, add those indicators to hunts, but no such actor context was provided here.

What your security team should do

• Inventory Unix-hosted applications written in Go or embedding Go components that use os.Root or equivalent root-confined file access.
• Prioritize review of applications that process untrusted uploads, archives, build workspaces, plugins, user home directories, shared project folders, or any user-writable filesystem content.
• Track upstream and OS/vendor advisories for the fixed Go release, then rebuild and redeploy affected binaries rather than only patching the host package.
• Add regression tests for final-component symlinks with trailing slashes to all security-sensitive file access code.
• Temporarily block or strip symlinks in untrusted content ingestion paths until patched.
• Harden runtime permissions so application service accounts cannot read or write sensitive host paths that are not required for operation.
• Hunt for suspicious symlink creation inside application-controlled roots and correlated file operations that reference trailing-slash paths.
• Treat exploitation likelihood as currently low based on EPSS, KEV, and exploit-maturity signals, but remediate promptly where the application uses filesystem confinement as a security boundary.