CVE-2026-87912
A missing S3 bucket ownership verification in the AWS Security Agent plugin in Amazon aws-agents-for-devsecops before 1.1.0 might allow remo
CVSS
5.9
Medio
EPSS
0.4%
p37
KEV
—
Exploit Today
11
0-100
Publicado: 10 sept 2026 · Última mod.: 10 sept 2026 · CWE-283 · CWE-341
0.2%EPSS · 30 días0.4%
2026-09-212026-10-19
A missing S3 bucket ownership verification in the AWS Security Agent plugin in Amazon aws-agents-for-devsecops before 1.1.0 might allow remote attackers to obtain the private source archive of a scanned workspace, including credentials and infrastructure state contained in that archive, via a pre-registered storage bucket whose name is derived from a publicly known account identifier. To remediate this issue, users should upgrade to version 1.1.0. Users should also verify that the scan output bucket in their account is owned by their own account, because upgrading does not release a bucket name that a third party has already registered.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-1129116.3 MED—
———filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. This issue is fixed in version 4.2.1.5hCVE-2026-837917.8 ALT19.6%
——6Improper authorization in Windows Virtual Input allows an authorized attacker to elevate privileges locally.4dCVE-2026-1102377.3 ALT3.7%
——1Vifm 0.8.1-beta through 0.14.4 reuses a pre-existing IPC FIFO in the shared temporary directory without checking ownership, allowing local users to execute commands as another user. Attackers can pre-create a world-writable vifm-ipc-vifm FIFO and write IPC packets with -c and ! shell commands that execute with the victim's privileges.4dCVE-2026-93853—10.2%
——3Unverified ownership in Barman snapshot backup deletion allows a principal who can write the backup catalog to cause Barman to delete unrelated cloud snapshots. When a snapshot backup is deleted, either explicitly or by retention policy enforcement, Barman reads the snapshot identifiers from the backup.info file and passes them to the cloud provider's delete API using Barman's own credentials, without verifying that the snapshots belong to that backup. An attacker who can overwrite backup.info but lacks snapshot delete permissions can substitute the identifiers of other snapshots, causing Barman to delete any snapshot its cloud identity can reach on AWS, Microsoft Azure, or Google Cloud. Exploitation requires a deployment where the principal that writes the backup catalog is separate from the identity Barman uses to delete snapshots. Barman versions from 3.4.0 (Google Cloud), 3.6.0 (Azure), and 3.7.0 (AWS) up to and including 3.20.0 are affected. The issue is fixed in Barman 3.20.1.21dCVE-2026-944569.1 CRÍ43.1%
——13Postiz generates security-sensitive credentials using `Math.random()` instead of a cryptographically secure source. The same helper is used for OAuth access tokens, authorization codes, client secrets, organization API keys, and PKCE verifiers, meaning these credentials depend entirely on V8’s deterministic xorshift128+ PRNG state.
An unauthenticated OAuth dynamic client registration endpoint exposes freshly generated client credentials, giving attackers enough consecutive PRNG output to reconstruct that internal state. Once recovered, they can deterministically derive past and future values produced by the same generator, potentially compromising credentials belonging to other users and organizations.28dCVE-2025-248906.8 MED7.9%
——2gitoxide is an implementation of git written in Rust. Prior to 0.13.3, the gix-sec crate on Windows incorrectly treats repositories controlled by another user as trusted when an administrator runs a dependent program with an unfiltered elevated token. In gix-sec/src/identity.rs, gix_sec::identity::is_path_owned_by_current_user obtains folder_owner and token_owner, but its administrator-specific IsWellKnownSid and CheckTokenMembership checks examine the running token rather than confirming the directory owner. This bypasses safe.directory-style protection for repositories owned and configured by a limited user, allowing repository configuration or hooks to execute commands with the administrator's privileges when an affected operation is performed. Exploitation requires Windows, an elevated administrator, a program that relies on gix-sec trust results, and interaction with a repository controlled by another user. An unelevated UAC process is not affected, and cloning is not affected because repository configuration and hooks are not copied. This issue is fixed in version 0.13.3.6d