CVE Watch15 de out. de 2026

CVE-2026-55498

FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 3.15.0, FileRise public sha

CVSS

4.8

Média

EPSS

0.3%

p26

KEV

—

Exploit Today

0-100

Publicado: 14 de out. de 2026 · Última mod.: 15 de out. de 2026 · CWE-59

EPSS · 30d

0.3%EPSS · 30 dias0.3%

2026-10-152026-11-06

Descrição técnica

FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 3.15.0, FileRise public shared-folder links with subfolder browsing enabled can follow a symbolic link inside the shared folder to a sibling directory under the upload root. An unauthenticated holder of a valid share token can use shared-folder listing, direct download, or ZIP creation to access files outside the folder that was actually shared. The flaw occurs because the affected shared-folder paths resolve symlinks without enforcing the original shared folder as the real-path boundary. This issue is fixed in version 3.15.0.

Referências oficiais

CVEs relacionados

CVECVSSEPSSKEVRExploitTítuloMod.

CVE-2026-1082626.5 MÉD

—

——0DDEV is an open-source tool for running local web development environments for PHP and Node.js. From 1.25.2 until 1.25.4, Untar in pkg/archive/archive.go validates an absolute tar symlink target after rebasing it beneath dest, but creates the symlink with the raw absolute Linkname. A crafted archive can therefore plant a host-absolute symlink and use a following regular-file entry to write outside the extraction directory. The flaw is reachable through remote add-on retrieval and database or file imports, and overwriting shell startup files, Git hooks, or cron entries can lead to code execution in the DDEV user's context. Unzip is not affected. This issue is fixed in version 1.25.4.15h CVE-2026-1238427.1 ALT

—

——0In JetBrains IntelliJ IDEA before 2026.3 arbitrary file write was possible via symlinks when extracting plugin archives13h CVE-2026-1238417.8 ALT

—

——0In JetBrains IntelliJ IDEA before 2026.3 code execution was possible via symlinks in an imported settings archive4h CVE-2026-1238368.8 ALT

—

——0In JetBrains Datalore before 2026.4 workspace collaborators could obtain the owner's SSH private key via Git backup13h CVE-2026-1230376.7 MÉD

1.4%

——0A flaw was found in the ansible-core user module. When generate_ssh_key is enabled, User.ssh_key_gen() guards the key files against symlinks but checks the ~/.ssh directory only with os.path.exists(). An unprivileged user on a managed node who replaces their ~/.ssh with a symlink to an existing root-writable directory causes the privileged module to write the generated key pair through the symlink and then chown both files to that user. Because such files can be dropped into directories processed by schedulers (e.g. /etc/cron.daily) or dynamic MOTD (/etc/update-motd.d), the user can escalate to root on the managed node. This is an incomplete fix of CVE-2024-9902.14h CVE-2026-100395—

4.3%

——1LXC 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.1d