CVE-2026-32282

What it actually does

This is a local time-of-check/time-of-use race condition in Go's Linux implementation of Root.Chmod. The API checks that a requested path is within the intended root and rejects symlinks that escape that root, but during the small window between validation and the chmod operation, an attacker with sufficient local privileges and write access to the target path can replace the checked file with a symbolic link. Because Linux fchmodat silently ignores AT_SYMLINK_NOFOLLOW in this case, the chmod may be applied to the symlink target rather than the originally checked file, including a file outside the intended root. Successful exploitation can change permissions on unintended files, potentially affecting confidentiality, integrity, or availability depending on which file permissions are modified.

Why it matters to the business

The main risk is unauthorized permission changes on Linux systems running affected Go-built software that uses Root.Chmod on paths an attacker can influence. In practical terms, this could let a local attacker weaken file protections, expose sensitive data, disrupt application operation, or enable follow-on privilege escalation if security-relevant files become writable or readable. The issue has a moderate CVSS score of 6.4, requires local high-privilege access and precise race timing, has low EPSS activity, is not in CISA KEV, and has no known exploit maturity, so broad internet-scale exploitation is unlikely; however, the impact can be serious in multi-user systems, container tooling, sandboxing workflows, build systems, package managers, or services that perform permission changes inside attacker-writable directory trees.

How an attack unfolds

An attacker first needs local access with the ability to manipulate files inside a directory tree processed by affected Go code using Root.Chmod. The attacker prepares a normal file or path that passes the Root.Chmod validation check, then repeatedly swaps that path with a symlink pointing to a chosen file outside the intended root while the chmod operation is being performed. If the swap occurs after the safety check but before the kernel chmod operation, the chmod may affect the symlink target rather than the originally validated file. The attacker then benefits from the changed permissions, such as reading a file that should remain private, modifying a file that should remain protected, or causing services to fail because permissions were made too restrictive. Exploitation is timing-sensitive and local, but automated race loops may improve reliability when the vulnerable operation can be triggered repeatedly.

How to fix it

Upgrade affected Go toolchains, runtimes, and rebuilt applications to a version that contains the vendor fix once available from the Go project or downstream distributor. Because no fixed versions were provided in the input, track official Go security advisories and distribution package updates for CVE-2026-32282, then rebuild and redeploy statically linked Go applications after updating the toolchain. As compensating controls, avoid calling Root.Chmod on directory trees writable by untrusted users, prevent untrusted users from replacing chmod targets during privileged operations, use file-descriptor-based workflows where possible, perform operations in directories not shared with attackers, and enforce least privilege so affected processes cannot chmod high-value files outside the intended root. For container or sandbox tooling, ensure host-sensitive paths are not reachable as symlink targets from attacker-controlled workspaces and consider isolating permission-changing operations in a restricted mount namespace.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems and Go-built applications that use a Go version containing the affected Root.Chmod implementation, then review source code and dependencies for use of Root.Chmod on paths that can be influenced by local users, build jobs, containers, archives, plugins, or untrusted workloads. After applying a vendor fix, verify the installed Go toolchain version and rebuild artifacts, because statically compiled Go binaries retain vulnerable standard-library code until rebuilt. Functional validation should include a regression test that attempts to replace a Root.Chmod target with a symlink to a file outside the root during the chmod operation and confirms that the external target's permissions are not changed. Also validate that operational mitigations remove attacker write access to directories being chmodded by privileged processes.

Typical attack path

1. Identify Go-built software on Linux that uses Root.Chmod or a dependent library path that invokes Root.Chmod on attacker-influenced files.
2. Gain local access or control over a writable directory tree processed by the affected chmod logic.
3. Create a benign file or path that will pass the Root.Chmod root-boundary and symlink checks.
4. Trigger the vulnerable chmod operation repeatedly, if possible.
5. Race the operation by replacing the validated file with a symbolic link to a target outside the root after validation but before chmod executes.
6. Observe whether permissions on the external target changed.
7. Use the modified permissions to read, modify, delete, or disrupt files that should not have been reachable through the root-restricted operation.

How to detect it

There is no reliable network-level signature for this vulnerability because exploitation is local and race-based. To assess possible prior exploitation, review Linux audit logs, endpoint detection telemetry, file integrity monitoring, and application logs from software that performs Go-based root-restricted chmod operations. Look for unexpected chmod activity on files outside the application's intended working root, especially when preceded by rapid file replacement, symlink creation, rename, or unlink activity in attacker-writable directories. Useful log sources include auditd records for chmod/fchmodat, symlink, rename, unlink, and file attribute changes; EDR file event timelines; shell history and process execution logs showing race-loop scripts; CI/build runner job logs; container runtime logs; and file integrity alerts showing permission changes on sensitive files. Investigate any permission changes that coincide with untrusted job execution, archive extraction, package processing, or sandbox/container workloads. Because no public exploit indicators or actor-specific tradecraft were provided, detection should focus on behavioral evidence: high-frequency symlink swaps, chmod calls by Go-built processes, and sensitive files receiving unexpected mode changes.

• syscall=fchmodat
• syscall=chmod
• SYSCALL=chmod
• SYSCALL=fchmodat
• PATH item=* nametype=CREATE
• nametype=DELETE
• nametype=NORMAL
• ln -s
• renameat
• renameat2
• unlinkat
• AT_SYMLINK_NOFOLLOW
• unexpected file mode change outside configured root
• rapid symlink creation and deletion in writable directory
• chmod operation followed by permission change on symlink target

What your security team should do

• Prioritize systems where Go-built Linux software performs privileged file permission changes in attacker-writable directories, such as build workers, CI runners, package processing systems, container tooling, sandbox managers, and multi-user servers.
• Track official Go and Linux distribution advisories for the first fixed release, then update Go toolchains and rebuild affected Go binaries rather than only patching the compiler package.
• Review internally developed and third-party Go code for Root.Chmod use and determine whether any caller operates on untrusted or concurrently mutable paths.
• Add hardening around permission-changing workflows: remove untrusted write access, use temporary directories with strict ownership, avoid shared writable paths, and run chmod operations with the minimum privileges required.
• Monitor for unexpected permission changes on sensitive files and directories, especially around times when affected Go applications processed untrusted files or directories.
• Do not treat the low EPSS score and absence from KEV as a reason to ignore the issue in high-risk local or multi-tenant environments; exploitation requires local access but can have high impact if privileged files are affected.