| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| rsync before 3.5.0 contains a path traversal vulnerability that allows remote clients to access files outside the intended module root when use chroot is disabled and the module root path or a component of it is a symlink. The daemon calls chdir() to the module root at session initialization without resolving symlinks via realpath() or equivalent, causing subsequent relative-path operations to reference files relative to the symlink target rather than the intended module root, enabling unauthorized file access. |
| rsync before 3.5.0 contains a path traversal vulnerability that allows a malicious sender to write files outside the intended destination directory tree by crafting relative paths with symlink components in --relative mode. The make_path() function follows symlinks pointing outside the destination tree while creating intermediate directories without verifying that created paths remain within the destination boundary, enabling arbitrary file writes on the receiver's filesystem. |
| rsync before 3.5.0 contains a path confinement bypass vulnerability that allows remote clients to escape the intended inner-module root confinement by constructing paths that resolve outside the chroot boundary when the module root contains a /./ boundary marker. Attackers can exploit improper handling of the /./ notation or forge delta-basis transfers referencing xname paths that cross the /./ boundary to gain unauthorized read or write access to files outside the module's subtree. |
| rsync before 3.5.0 contains an arbitrary file write vulnerability that allows attackers to write files outside the intended destination tree by specifying an absolute path via --temp-dir or --link-dest options. The rename-confinement logic is bypassed when these options resolve to paths outside the destination tree, enabling attacker-controlled values to write files to arbitrary locations accessible to the rsync process. |
| rsync before 3.5.0 contains a time-of-check to time-of-use (TOCTOU) race condition vulnerability in the non-daemon receiver's destination directory handling that allows an attacker who can manipulate destination path parent components to redirect file writes to unintended locations. Attackers can substitute a symlink for a component of the destination path between the path resolution and chdir() call, causing the receiver's working directory to be established outside the intended destination tree so that subsequent relative-path file writes land in unintended filesystem locations. |
| rsync before 3.5.0 contains a symlink race condition vulnerability in the sender's source tree traversal that allows an attacker who can manipulate a parent directory of the source tree to redirect file reads to unintended paths. Attackers can atomically replace a parent directory component with a symlink pointing outside the source root between path resolution and file open operations to disclose file contents outside the intended transfer root. |
| rsync before 3.5.0 contains a symlink race condition vulnerability that allows local attackers to cause rsync to apply arbitrary ACLs or extended attributes to unintended files by substituting a symlink at a predictable destination path between the file write and the subsequent acl_set_file() or lsetxattr() call. Attackers can exploit this timing window to redirect ACL and xattr application through a crafted symlink to files outside the intended destination tree, potentially granting elevated permissions and enabling local privilege escalation. |
| rsync before 3.5.0 contains a symlink race condition vulnerability in the --remove-source-files feature that allows attackers with symlink creation access to cause arbitrary file deletion. Attackers can atomically substitute a symlink for a source file between transfer completion and the unlink() call, causing rsync to delete the symlink target rather than the intended source file. |
| rsync before 3.5.0 contains a symlink race condition vulnerability in the sender's directory scanning logic that allows attackers to cause the sender to enumerate and transfer files outside the module root's intended subtree. Attackers who can create or manipulate symlinks in a path component of the scanned tree can replace a symlink with a directory entry pointing outside the module root between the lstat() call and the subsequent opendir() call, exposing files beyond the intended root in both daemon-mode and non-daemon sender-side scanning. |
| rsync 2.3.3 before 3.5.0 contains a path traversal vulnerability that allows a malicious sender to escape the module root by exploiting symlinks within the module file tree when using --partial-dir or --backup-dir options. Attackers with write access to place a symlink under the module root, or who can exploit a pre-existing trusted symlink, can direct file writes to locations outside the intended module root, achieving arbitrary file write relative to the module root parent. |
| Ninja Tables Pro 5.2.11 contains an embedded malicious code vulnerability introduced via a tampered plugin build served through a decommissioned update server. The tampered build introduced a rogue PHP file (app/Library/updater/NinjaTableDataSync.php) that established a backdoor REST API endpoint, dropped persistent PHP files in mu-plugins and uploads directories, installed a passwordless administrator account, and registered scheduled tasks that survived plugin removal. |
| Fluent Forms Pro 6.2.7 contains an embedded malicious code vulnerability introduced via a tampered plugin build served through a decommissioned update server. The tampered build introduced a rogue PHP file (libs/class-license-sync.php), loaded via a require_once directive added to fluentformpro.php, that established a backdoor REST API endpoint, dropped persistent PHP files in mu-plugins and uploads directories, installed a passwordless administrator account, and registered scheduled tasks that survived plugin removal. |
| SMP security request (from peripheral) does not include the maximum
encryption key size supported. Using a key with less than the maximum keysize
makes brute-forcing the key easier. See V6 in BLERP paper linked below. |
| Cleartext Storage of Sensitive Information in an Environment Variable (CWE-526) in Elastic Cloud on Kubernetes (ECK) can lead to information disclosure via Retrieve Embedded Sensitive Data (CAPEC-37). When ECK reconciles a Fleet Server resource that authenticates to Elasticsearch with a service account token, the token is written into the generated workload specification in cleartext rather than being referenced from the Kubernetes Secret that ECK maintains for the other credentials on the same path. Any principal able to read workload specifications in the affected namespace can therefore read a live Elasticsearch credential, even when Kubernetes RBAC does not grant that principal access to Secrets. |
| In the Linux kernel, the following vulnerability has been resolved:
libceph: fix two unsafe bare decodes in decode_lockers()
decode_lockers() in cls_lock_client.c contains two bare decode operations
that allow a malicious or compromised OSD to trigger slab-out-of-bounds
reads:
1. ceph_decode_32(p) at the num_lockers field has no preceding bounds
check. ceph_start_decoding() accepts struct_len=0 as valid -- the
internal ceph_decode_need(p, end, 0, bad) always passes -- so when an
OSD sends struct_len=0, ceph_start_decoding() returns success with
p == end. The immediately following bare ceph_decode_32(p) then reads
4 bytes past the validated buffer boundary. The garbage value is
passed directly to kzalloc_objs() as the locker count.
The sibling function decode_watchers() in osd_client.c already uses
ceph_decode_32_safe() after its own ceph_start_decoding() call.
decode_lockers() was the only site using the bare variant.
2. ceph_decode_8(p) after the decode_locker() loop has no preceding
bounds check. If an OSD crafts num_lockers such that the loop
advances p exactly to end, the subsequent bare ceph_decode_8(p) reads
one byte past the validated buffer boundary. The result is passed
directly into *type, which is used as a lock type discriminator by
callers, giving an OSD-controlled one-byte OOB read with direct
influence over the lock type field.
Fix both by replacing bare operations with their safe variants:
ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers,
err_inval)
ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type,
err_free_lockers)
The goto targets differ intentionally:
err_inval: is a new label returning -EINVAL directly. It is used for
the pre-allocation failure path where *lockers is not yet allocated
and must not be passed to ceph_free_lockers().
err_free_lockers: is the existing label. It is used for the
post-allocation failure path where *lockers is allocated and must
be freed.
ret is set to -EINVAL before ceph_decode_8_safe() so that
err_free_lockers returns the correct error code on bounds violation.
Without this, err_free_lockers would return a stale ret value (0 from
the successful decode_locker() loop), silently swallowing the error.
-EINVAL is correct for both failure paths. The data received from the
OSD is structurally malformed. -ENOMEM would misrepresent the failure
class to callers and to stable@ backporters triaging error paths.
Attacker model: a malicious or compromised OSD in a multi-tenant Ceph
deployment can trigger this against any kernel client that issues the
lock.get_info class method (e.g. during RBD exclusive lock acquisition).
[ idryomov: trim changelog, formatting ] |
| In the Linux kernel, the following vulnerability has been resolved:
misc: nsm: pin the module while the device is open
misc_open() installs a misc driver's file operations with fops_get(),
which pins file_operations::owner before replacing the file's f_op. The
NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does
not take a module reference on the nsm driver.
If the driver is built as a module, an open file descriptor can therefore
survive rmmod of the module that provides its ioctl callbacks. A later
ioctl through that descriptor can call into unloaded module text.
Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module
while any /dev/nsm file descriptor is open, matching the lifetime
expectation for the installed file operations. |
| In the Linux kernel, the following vulnerability has been resolved:
fs: preserve ACL_DONT_CACHE state in forget_cached_acl()
The ACL_DONT_CACHE state is meant to be a constant state for the inode
for filesystems that want to opt out of posix acl caching.
Commit facd61053cff1 ("fuse: fixes after adapting to new posix acl api")
used this facility to opt out of posix acl caching for fuse inodes with
fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl).
The commit also takes care to gate the forget_all_cached_acls() call in
fuse_set_acl() on fc->posix_acl because there is no need for it, but
there are other placed in fuse code which call forget_all_cached_acls()
unconditional to fc->posix_acl and those cause the loss of the
ACL_DONT_CACHE state.
This is not only a functional bug. Properly timed, a get_acl() from this
fuse filesystem can return a stale cached value, as was observed in tests,
because set_acl() does not invalidate the unintentional acl cache.
We could fix this in fuse, but it actually makes no sense for the vfs
helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so
let it not do that to fix fuse and future users of ACL_DONT_CACHE. |
| IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.8 is affected by a denial of service caused by insecure deserialization. A low-privileged, administrative user could exploit this vulnerability to consume system resources when the restConnector-2.0 feature is enabled. |
| Budibase before 3.40.0 fails to redact datasource credentials stored in STRING typed fields, allowing authenticated users to read MongoDB connection strings and Firebase private keys in plaintext. Attackers with table read permissions can retrieve datasource configurations through the read API to obtain live backend database credentials and service account keys. |
| IBM Storage Scale 5.2.3.0 through 5.2.3.8, and 6.0.0.0 through 6.0.1.0 Secrets may be disclosed in log files in IBM Storage Scale Management GUI The admin password is logged into the GUI log of IBM Storage Scale Systems Deploy and Upgrade from GUI. Secrets may be disclosed in information related to exceptions in IBM Storage Scale Management GUI. |
