CVE Watch16 de out. de 2026

CVE-2026-102740

The AsyncHttpClient library allows Java applications to execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 2.

CVSS

5.8

Média

EPSS

0.1%

KEV

—

Exploit Today

0-100

Publicado: 15 de out. de 2026 · Última mod.: 16 de out. de 2026 · CWE-61 · CWE-379 · CWE-732

EPSS · 30d

0.1%EPSS · 30 dias0.1%

2026-10-162026-11-06

Descrição técnica

The AsyncHttpClient library allows Java applications to execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 2.16.1 and 3.0.12, PropertiesBasedResumableProcessor stores resumable download state at the predictable shared path $java.io.tmpdir/ahc/ResumableAsyncHandler.properties with default permissions and link-following file operations. A local user who can read the shared store can see download URLs, including embedded user information or query tokens. A local user who can write within or pre-create the affected shared store directory can plant a symbolic link that the client follows when saving state, truncating and overwriting a target file writable by the client process. The filesystem path is used when ResumableAsyncHandler decorates another AsyncHandler, while the no-argument constructors use a no-op processor and are unaffected. This issue is fixed in versions 2.16.1 and 3.0.12.

Referências oficiais

CVEs relacionados

CVECVSSEPSSKEVRExploitTítuloMod.

CVE-2026-1240393.3 BAI

—

——0Gitleaks through 8.30.1 contains an incorrect permission assignment vulnerability that allows local users to read scan reports because cmd/root.go creates the --report-path file with os.Create and default permissions. Unless --redact is passed, other local users on shared hosts or CI runners can read plaintext secrets and matching lines to obtain discovered credentials.14h CVE-2026-1239747.8 ALT

—

——0In all versions of PyTorch's TorchServe, a predictable extraction directory in /tmp lets a local user swap the model handler and run code as the TorchServe service account leading to local privilege escalation.13h CVE-2026-1239628.4 ALT

—

——0In FreedomBox before 26.15, unprivileged user accounts can read/write files for which they lack permissions by setting the authorized_keys file to be a symlink. NOTE: FreedomBox is a Debian Pure Blend, which means that it distributes its software through Debian repositories.12h CVE-2026-1129105.3 MÉD

5.3%

——2filelock is a platform-independent file lock for Python. From 3.10.0 until 4.2.1, filelock on Windows ignores the mode argument for WindowsFileLock files and the ReadWriteLock SQLite database. A lock created with mode=0o600 receives the parent directory's inheritable ACL because _open_non_reparse_fd and _nt_open do not create an owner-only security descriptor. Another local account with inherited access can read holder metadata or the lock database, modify those files where the ACL permits writes, or take the byte-range lock after release and delay later acquisitions. UnixFileLock is not affected, and mutual exclusion between cooperating processes continues to hold. This issue is fixed in version 4.2.1.13h CVE-2026-1129085.3 MÉD

1.9%

——1filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1, StrictSoftFileLock and AsyncStrictSoftFileLock on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. This issue is fixed in version 4.2.1.13h 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.2d