| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: flush dirty data before zeroing a range
smb3_zero_range() emulates FALLOC_FL_ZERO_RANGE by invalidating the
page cache over the target range with truncate_pagecache_range() and
then issuing FSCTL_SET_ZERO_DATA to the server.
Dirty data was only flushed conditionally, when the range reached or
extended EOF. For a purely interior zero range that does not reach
EOF, no flush happened, so a dirty folio overlapping the range could
be written back to the server after the FSCTL and refill the range
that was just zeroed with stale data.
Fix this by unconditionally flushing and waiting for dirty data in the
range before invalidating the page cache and issuing
FSCTL_SET_ZERO_DATA, exactly as was done for smb3_punch_hole() in
commit d7d2adcd022b ("smb/client: flush dirty data before punching a
hole"); the two paths are structurally identical here.
This is observed as generic/363 randomly reading stale data where a
zeroed range is expected against Windows Server. |
| Archive::Tar versions before 3.08 for Perl extract hardlinks to attacker controlled paths outside the extraction directory.
_make_special_file() passes the tar header's linkname to link() without validating it against absolute paths or .. segments, creating a hardlink that shares the victim file's inode.
A subsequent write through the extracted name modifies the victim file, and the post-extraction chmod, chown, and utime block in _extract_file() (guarded only against symlinks via -l) applies the tar header's mode, owner, and timestamps to the shared inode during extraction alone. |
| Archive::Tar versions before 3.08 for Perl extract symlinks with attacker controlled targets outside the extraction directory.
_make_special_file() passes the tar header's linkname to symlink() without validating it against absolute paths or .. segments. The secure-extract mode check that guards regular file extraction does not cover the symlink target.
A subsequent open through the extracted name reads or writes the attacker chosen path. |
| A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions < V11.0), SIPROTEC 5 6MD85 (CP300) (All versions < V11.0), SIPROTEC 5 6MD86 (CP300) (All versions < V11.0), SIPROTEC 5 6MD89 (CP300) (All versions < V11.0), SIPROTEC 5 6MD89 (CP300) V9.6x (All versions < V11.0), SIPROTEC 5 6MU85 (CP300) (All versions < V11.0), SIPROTEC 5 7KE85 (CP300) (All versions < V11.0), SIPROTEC 5 7SA82 (CP100) (All versions < V8.91), SIPROTEC 5 7SA82 (CP150) (All versions < V11.0), SIPROTEC 5 7SA86 (CP300) (All versions < V11.0), SIPROTEC 5 7SA87 (CP300) (All versions < V11.0), SIPROTEC 5 7SD82 (CP100) (All versions < V8.91), SIPROTEC 5 7SD82 (CP150) (All versions < V11.0), SIPROTEC 5 7SD86 (CP300) (All versions < V11.0), SIPROTEC 5 7SD87 (CP300) (All versions < V11.0), SIPROTEC 5 7SJ81 (CP100) (All versions < V8.91), SIPROTEC 5 7SJ81 (CP150) (All versions < V11.0), SIPROTEC 5 7SJ82 (CP100) (All versions < V8.91), SIPROTEC 5 7SJ82 (CP150) (All versions < V11.0), SIPROTEC 5 7SJ85 (CP300) (All versions < V11.0), SIPROTEC 5 7SJ86 (CP300) (All versions < V11.0), SIPROTEC 5 7SK82 (CP100) (All versions < V8.91), SIPROTEC 5 7SK82 (CP150) (All versions < V11.0), SIPROTEC 5 7SK85 (CP300) (All versions < V11.0), SIPROTEC 5 7SL82 (CP100) (All versions < V8.91), SIPROTEC 5 7SL82 (CP150) (All versions < V11.0), SIPROTEC 5 7SL86 (CP300) (All versions < V11.0), SIPROTEC 5 7SL87 (CP300) (All versions < V11.0), SIPROTEC 5 7SS85 (CP300) (All versions < V11.0), SIPROTEC 5 7ST85 (CP300) (All versions < V11.0), SIPROTEC 5 7ST86 (CP300) (All versions < V11.0), SIPROTEC 5 7SX82 (CP150) (All versions < V11.0), SIPROTEC 5 7SX85 (CP300) (All versions < V11.0), SIPROTEC 5 7SY82 (CP150) (All versions < V11.0), SIPROTEC 5 7UM85 (CP300) (All versions < V11.0), SIPROTEC 5 7UT82 (CP100) (All versions < V8.91), SIPROTEC 5 7UT82 (CP150) (All versions < V11.0), SIPROTEC 5 7UT85 (CP300) (All versions < V11.0), SIPROTEC 5 7UT86 (CP300) (All versions < V11.0), SIPROTEC 5 7UT87 (CP300) (All versions < V11.0), SIPROTEC 5 7VE85 (CP300) (All versions < V11.0), SIPROTEC 5 7VK87 (CP300) (All versions < V11.0), SIPROTEC 5 7VU85 (CP300) (All versions < V11.0), SIPROTEC 5 Compact 7SX800 (CP050) (All versions < V11.0). The affected devices include session identifiers in URL requests for certain functionalities. This could allow an attacker to retrieve sensitive session data from browser history, logs, or other storage mechanisms, potentially leading to unauthorized access. |
| compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.22.0 until 0.31.0, compose-lint follows a sibling .env symbolic link outside the project without applying its normal containment check. From 0.28.0, the same gap also affects an include project_directory link outside the project. A pull request can reference a variable from the linked file, causing substitution to place runner file or process-environment data into finding messages written to logs, JSON, SARIF artifacts, and Code Scanning alerts. Reading /proc/self/environ can expose the remainder of the linter process environment because NUL-separated entries are treated as one value, although disclosure requires a workflow that processes untrusted changes with useful environment data and GitHub normally withholds secrets from fork pull requests. The pass or fail result is not changed. This issue is fixed in version 0.31.0. |
| compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.2.0 until 0.32.0, compose-lint automatically follows a .compose-lint.yml policy-file symbolic link outside the project and includes part of the target line when that external file fails YAML parsing. A pull request can point the policy file at a runner credential file, causing about 30 characters around an attacker-uncontrolled parse position to appear in standard error, JSON errors, and SARIF tool execution notifications uploaded by the GitHub Action. The run exits with an error and the attacker cannot select the exact disclosed line, but public logs or Code Scanning output can reveal part of the target. This issue is fixed in version 0.32.0. |
| compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.2.0 until 0.25.0, compose-lint follows a project-controlled symbolic link used as the Compose file outside the project. The same issue affects compose.override.yml and a COMPOSE_FILE entry from 0.22.0, and an env_file target from 0.23.0. If an external Compose-related target fails YAML parsing, the error quotes an attacker-uncontrolled line into standard error, JSON errors, and SARIF notifications, while an external env_file can expose credential-like key names through CL-0020 and CL-0021 findings. The attacker selects the target path but not the exact parser-failure line, values from env_file are not printed, and the pass or fail result is unchanged. This issue is fixed in version 0.25.0. |
| Nuxt UI is an intuitive Vue UI library powered by Reka UI and Tailwind CSS. Prior to 4.8.1, the server-rendered form element produced by UForm in src/runtime/components/Form.vue omits the method and action attributes and relies solely on the hydrated @submit.prevent handler to stop native submission. UAuthForm composes UForm and can render named credential fields, including an input with type password, inside the same markup. If a user submits before Vue hydration completes, or when the client bundle is blocked or unavailable, the browser performs its default GET submission and serializes the named fields into the current URL query string. The credentials can then appear in the address bar, browser history, reverse-proxy, CDN, or WAF request logs, and Referer headers sent with same-origin subresource requests. This issue is fixed in version 4.8.1. |
| Improper link resolution before file access ('link following') in .NET allows an authorized attacker to elevate privileges locally. |
| Improper link resolution before file access ('link following') in .NET allows an authorized attacker to elevate privileges locally. |
| Improper Link Resolution Before File Access Vulnerability in Hitachi Dynamic Link Manager for Linux.
This issue affects Hitachi Dynamic Link Manager for Linux: from 6.1.1.-00 before 9.0.5-00. |
| Link Following Vulnerability in Hitachi Dynamic Link Manager for Windows.
This issue affects Hitachi Dynamic Link Manager for Windows: from 5.0.0-03 before 9.0.4-01. |
| Node Version Manager (nvm) is a POSIX-compliant shell function for managing multiple node.js versions. In versions 0.2.0 through 0.40.8, nvm does not check whether `.nvmrc` is a symbolic link. A repository or archive that ships `.nvmrc` as a symlink to another file (for example `../../.npmrc`, or `/proc/self/environ` on Linux) makes a plain `nvm use`, `nvm install`, `nvm which`, `nvm exec`, `nvm run`, or `nvm-exec` read that file and print its contents in the invalid-`.nvmrc` message (even with `--silent`) or, for a one-line file, in the `Found ... with version <...>` message; with the README's zsh `load-nvmrc` or bash `cdnvm` hook installed, entering the directory is enough. nvm sends the content nowhere; the attacker learns it only where they can see the victim's output, such as a CI log for a contributed branch. Version 0.41.0 still follows a symlinked `.nvmrc`, so deliberate links to another version file keep working, but never prints its content, and accepts it only if it contains a version or the name of an existing alias; the README's bash `cdnvm` hook, which read `.nvmrc` itself, now gets the version from nvm, so users of that hook must also update their copy of it. |
| Node Version Manager (nvm) is a POSIX-compliant shell function for managing multiple node.js versions. In versions 0.40.0 through 0.40.8, `nvm use --save` and `nvm install --save` (or `-w`) write the resolved version to `$PWD/.nvmrc` with `tee`, which follows a symbolic link. A repository that commits `.nvmrc` as a symlink to a path outside itself (git recreates the link on clone) therefore makes `--save` truncate any file the user can write, such as a shell startup file or `~/.ssh/authorized_keys`, and replace its contents with the version string, or create the target of a dangling link; the link itself is left unchanged, so `git status` stays clean. The attacker does not control the content written, so this is data loss, not code execution. Version 0.41.0 refuses, with a warning, to write when `.nvmrc` in the current directory is a symlink, dangling or not, rather than writing through it or replacing it. |
| A flaw was found in operator-foundry. The path-containment check, designed to restrict file access within a build context, only performs string-based validation. It fails to resolve symbolic links (symlinks), allowing an attacker to create a symlink within the build context that points to files or directories outside of it. This could enable unauthorized access to files beyond the intended confinement. |
| LXC is a userspace interface for the Linux kernel containment features used to create and manage system containers. In LXC 7.0.0 and earlier, lxc-copy and the public liblxc clone() API can follow attacker-controlled symbolic links while updating /etc/hostname in a copied container root filesystem. The affected surfaces are lxc-copy and liblxc's public lxc_container::clone() API. The privileged cloning process must run as root. The source rootfs must be attacker-controlled or less trusted. A symlink can be placed at etc/hostname or in an intermediate component. The clone operation preserves the symlink before updating the hostname. The vulnerable write truncates and overwrites an existing file outside the destination rootfs. When root clones an untrusted container without LXC_CLONE_KEEPNAME, the copied symlink can resolve outside the destination rootfs and cause the privileged process to overwrite an existing host file with the destination container name. Unprivileged use and managers with independent cloning implementations are not affected. LXC_CLONE_KEEPNAME avoids the hostname update and therefore the affected write. |
| Jan from 0.8.5 before 0.8.8 contains a workspace guard bypass vulnerability in the agent-tools gate.rs that allows attackers to write files outside the workspace via dangling symlinks. Attackers supplying a malicious repository can use prompt injection to make the write or edit tools follow symlinks, creating files like ~/.ssh/authorized_keys on the host. |
| Powerlevel10k before 1.20.19 contains a symlink following vulnerability in _p9k_dump_instant_prompt that allows local attackers to overwrite victim-writable files via a predictable temporary path. Attackers can pre-plant symlinks at p10k-instant-prompt-output-<user>-<pid> in TMPDIR, guessing the victim's shell PID, so shell startup truncates and overwrites targeted files. |
| nnn through 5.3 contains an insecure file handling vulnerability that allows local attackers to redirect writes because main() accepts an existing NNN_FIFO path without verifying it is a FIFO. Attackers can pre-create the documented predictable /tmp/nnn.fifo path as a symlink or readable regular file, causing victim-writable files to be overwritten or leaking the victim's browsed paths. |
| ruTorrent before 5.3.20 contains a path traversal vulnerability in the datadir plugin that allows authenticated users to escape the topDirectory jail because correctDirectory() does not resolve symbolic links. Attackers can submit a datadir path through a symlink under their top directory to create directories and move torrent data to locations writable by the web server or rtorrent. |
