Monthly
Local privilege escalation in the Windows Virtual Input component allows an authenticated, low-privileged attacker to gain elevated rights on affected Windows 10, Windows 11 and Windows Server hosts. Exploitation requires an attacker to already hold a local interactive foothold on the machine (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and to trigger an improper authorization check in the component (CWE-283, Unverified Ownership); no victim interaction is required and attack complexity is low, so escalation is straightforward once local access exists. A vendor patch is available from Microsoft, no public exploit has been identified at time of analysis, and CISA SSVC rates exploitation as none with the flaw judged not automatable, indicating it is not suitable for mass, scalable attacks.
Vifm file manager versions 0.8.1-beta through 0.14.4 reuse an already-existing IPC FIFO named vifm-ipc-vifm in the shared temporary directory without verifying who owns it, so a local attacker who plants a world-writable FIFO can feed it IPC packets containing -c and ! shell commands that then run with the victim's privileges. Reaching the flaw requires a multi-user host with a common temp directory, a local foothold on that host (PR:L), and a victim who subsequently starts vifm (UI:R passive interaction); the independent assessment rates this CVSS:3.1 AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H (7.8 High), while the supplied CVSS 4.0 vector scores 7.0. No public exploit code and no confirmed active exploitation have been identified at time of analysis, and no vendor-released patch has been identified, since the referenced source at v0.14.4 still contains the vulnerable FIFO handling.
Deletion of arbitrary cloud snapshots on AWS, Microsoft Azure, or Google Cloud can be triggered through Barman 3.4.0/3.6.0/3.7.0 (per provider) through 3.20.0, because the snapshot deletion path reads snapshot identifiers from the backup catalog (backup.info) and passes them to the cloud provider's delete API using Barman's own credentials without verifying that those snapshots belong to the backup being removed. An authenticated, low-privileged principal who can overwrite backup.info but does not hold snapshot-delete permissions can substitute the identifiers of unrelated snapshots, causing Barman to delete any snapshot its cloud identity can reach; deletion occurs either on explicit backup deletion or automatically when a retention policy is enforced, so no further admin action is needed once the forged catalog entry exists. Exploitation is conditional, not universal: it requires a deployment in which the principal that writes the backup catalog is separate from the cloud identity Barman uses to delete snapshots, and single-identity deployments are not exploitable (CVSS 4.0 base 7.2). No public exploit code has been identified at time of analysis, and the vendor-released fix is Barman 3.20.1.
Mailbox initialization in Trusted Firmware-M (TF-M) versions 2 through 2.3.0 on PSOC64 and RP2350 platforms fails to validate a pointer supplied by non-secure world code, allowing a low-privileged attacker with physical access to supply a crafted pointer that crosses the TrustZone-M hardware security boundary. Successful exploitation yields full read, write, and denial-of-service capability over the Secure Processing Environment (SPE), collapsing the hardware-enforced isolation TF-M is designed to guarantee - including potential exposure of cryptographic keys, attestation credentials, and secure boot state. No public exploit code exists and this vulnerability is absent from the CISA KEV catalog; the physical attack vector and high complexity substantially constrain opportunistic exploitation, but the full C/I/A scope change makes targeted supply-chain or insider-threat scenarios consequential.
TSPortal versions prior to 30 contain a logic flaw where empty strings are converted to null values, enabling attackers to forge Data Protection Act reports as legitimate user deletion requests. This affects the WikiTide Foundation's Trust and Safety platform and could allow misuse of the reporting system to obscure malicious activity. Public exploit code exists, and no patch is currently available for affected deployments.
Missing authorization validation in Pterodactyl Wings prior to version 1.12.1 allows authenticated nodes to access and manipulate servers across different nodes without proper ownership verification. An attacker with a valid node secret token can retrieve sensitive installation scripts, alter server installation states, and modify transfer statuses for servers they should not have access to. The vulnerability requires network access and valid node credentials but carries high impact due to potential exposure of secrets and cross-node server manipulation.
The Python `filelock` package's opt-in `StrictSoftFileLock` (3.30.0 through <4.2.1) and `SoftReadWriteLock` (4.0.0 through <4.2.1) can adopt a protocol directory (`<path>.filelock`/`claims` or `<path>.rw`/`gen`/`holders`) that another local account created first inside a shared, non-sticky parent directory, letting that account tamper with protocol state and admit two concurrent lock holders. Only local attackers on the same host who win the creation race can exploit it; the default `FileLock` class is not affected, there is no confidentiality impact, and the race/ordering requirement raises attack complexity. No public exploit code was identified at time of analysis, and the issue is fixed in filelock 4.2.1.
Credential and infrastructure state disclosure in AWS Security Agent MCP Server (versions ≤0.1.5) is enabled by the server's failure to verify S3 bucket ownership before uploading scan archives: an attacker who pre-registers the expected bucket name - derived from the target's publicly known AWS account ID - in their own account will silently receive every subsequent scan archive, which may contain long-lived credentials, Terraform or CloudFormation state files, and other sensitive workspace artifacts. The attack requires no privileges on the victim's account and only passive user interaction (the victim running a scan), but does require the attacker to act before the victim's first deployment. No public exploit has been identified and this CVE is not listed in CISA KEV; vendor-released patch 0.2.0 adds ownership verification, though Amazon explicitly notes that patching alone does not reclaim a bucket name already seized by a third party.
Bucket-squatting in the AWS Security Agent Plugin (aws-agents-for-devsecops) before 1.1.0 allows a remote unauthenticated attacker to intercept private workspace source archives uploaded during security scans. Because the S3 bucket name is deterministically derived from the victim's AWS account ID and region - both non-secret and frequently exposed in public ARNs, IAM policy documents, and ECR URIs - a third party can pre-register the predictable name in their own AWS account before the victim's setup runs. When a scan is subsequently triggered, the unpatched plugin uploads source.zip (containing source code, credentials, and infrastructure state) to the attacker-controlled bucket without verifying ownership, silently exfiltrating sensitive data. Vendor-released patch: 1.1.0.
Broken Windows directory-ownership verification in gix-sec (gitoxide's trust enforcement crate) causes all filesystem paths to be unconditionally trusted when the process runs with an unfiltered administrative token, nullifying safe.directory protections. Versions 0.13.2 and earlier of gix-sec contain a logic inversion in is_path_owned_by_current_user: the administrator-specific branch checks the SID of the running process against the Administrators group rather than checking the SID of the target directory, so both IsWellKnownSid and CheckTokenMembership always return true for elevated processes regardless of who actually owns the directory. A local limited-privilege attacker can plant a malicious Git repository (configuring core.sshCommand or hooks) in a shared or system-root location and trigger arbitrary code execution with full administrative rights when any admin-level gitoxide-backed operation encounters that path. No CISA KEV listing is present, but a working proof-of-concept is included in the GHSA advisory.
Local privilege escalation in the Windows Virtual Input component allows an authenticated, low-privileged attacker to gain elevated rights on affected Windows 10, Windows 11 and Windows Server hosts. Exploitation requires an attacker to already hold a local interactive foothold on the machine (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and to trigger an improper authorization check in the component (CWE-283, Unverified Ownership); no victim interaction is required and attack complexity is low, so escalation is straightforward once local access exists. A vendor patch is available from Microsoft, no public exploit has been identified at time of analysis, and CISA SSVC rates exploitation as none with the flaw judged not automatable, indicating it is not suitable for mass, scalable attacks.
Vifm file manager versions 0.8.1-beta through 0.14.4 reuse an already-existing IPC FIFO named vifm-ipc-vifm in the shared temporary directory without verifying who owns it, so a local attacker who plants a world-writable FIFO can feed it IPC packets containing -c and ! shell commands that then run with the victim's privileges. Reaching the flaw requires a multi-user host with a common temp directory, a local foothold on that host (PR:L), and a victim who subsequently starts vifm (UI:R passive interaction); the independent assessment rates this CVSS:3.1 AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H (7.8 High), while the supplied CVSS 4.0 vector scores 7.0. No public exploit code and no confirmed active exploitation have been identified at time of analysis, and no vendor-released patch has been identified, since the referenced source at v0.14.4 still contains the vulnerable FIFO handling.
Deletion of arbitrary cloud snapshots on AWS, Microsoft Azure, or Google Cloud can be triggered through Barman 3.4.0/3.6.0/3.7.0 (per provider) through 3.20.0, because the snapshot deletion path reads snapshot identifiers from the backup catalog (backup.info) and passes them to the cloud provider's delete API using Barman's own credentials without verifying that those snapshots belong to the backup being removed. An authenticated, low-privileged principal who can overwrite backup.info but does not hold snapshot-delete permissions can substitute the identifiers of unrelated snapshots, causing Barman to delete any snapshot its cloud identity can reach; deletion occurs either on explicit backup deletion or automatically when a retention policy is enforced, so no further admin action is needed once the forged catalog entry exists. Exploitation is conditional, not universal: it requires a deployment in which the principal that writes the backup catalog is separate from the cloud identity Barman uses to delete snapshots, and single-identity deployments are not exploitable (CVSS 4.0 base 7.2). No public exploit code has been identified at time of analysis, and the vendor-released fix is Barman 3.20.1.
Mailbox initialization in Trusted Firmware-M (TF-M) versions 2 through 2.3.0 on PSOC64 and RP2350 platforms fails to validate a pointer supplied by non-secure world code, allowing a low-privileged attacker with physical access to supply a crafted pointer that crosses the TrustZone-M hardware security boundary. Successful exploitation yields full read, write, and denial-of-service capability over the Secure Processing Environment (SPE), collapsing the hardware-enforced isolation TF-M is designed to guarantee - including potential exposure of cryptographic keys, attestation credentials, and secure boot state. No public exploit code exists and this vulnerability is absent from the CISA KEV catalog; the physical attack vector and high complexity substantially constrain opportunistic exploitation, but the full C/I/A scope change makes targeted supply-chain or insider-threat scenarios consequential.
TSPortal versions prior to 30 contain a logic flaw where empty strings are converted to null values, enabling attackers to forge Data Protection Act reports as legitimate user deletion requests. This affects the WikiTide Foundation's Trust and Safety platform and could allow misuse of the reporting system to obscure malicious activity. Public exploit code exists, and no patch is currently available for affected deployments.
Missing authorization validation in Pterodactyl Wings prior to version 1.12.1 allows authenticated nodes to access and manipulate servers across different nodes without proper ownership verification. An attacker with a valid node secret token can retrieve sensitive installation scripts, alter server installation states, and modify transfer statuses for servers they should not have access to. The vulnerability requires network access and valid node credentials but carries high impact due to potential exposure of secrets and cross-node server manipulation.
The Python `filelock` package's opt-in `StrictSoftFileLock` (3.30.0 through <4.2.1) and `SoftReadWriteLock` (4.0.0 through <4.2.1) can adopt a protocol directory (`<path>.filelock`/`claims` or `<path>.rw`/`gen`/`holders`) that another local account created first inside a shared, non-sticky parent directory, letting that account tamper with protocol state and admit two concurrent lock holders. Only local attackers on the same host who win the creation race can exploit it; the default `FileLock` class is not affected, there is no confidentiality impact, and the race/ordering requirement raises attack complexity. No public exploit code was identified at time of analysis, and the issue is fixed in filelock 4.2.1.
Credential and infrastructure state disclosure in AWS Security Agent MCP Server (versions ≤0.1.5) is enabled by the server's failure to verify S3 bucket ownership before uploading scan archives: an attacker who pre-registers the expected bucket name - derived from the target's publicly known AWS account ID - in their own account will silently receive every subsequent scan archive, which may contain long-lived credentials, Terraform or CloudFormation state files, and other sensitive workspace artifacts. The attack requires no privileges on the victim's account and only passive user interaction (the victim running a scan), but does require the attacker to act before the victim's first deployment. No public exploit has been identified and this CVE is not listed in CISA KEV; vendor-released patch 0.2.0 adds ownership verification, though Amazon explicitly notes that patching alone does not reclaim a bucket name already seized by a third party.
Bucket-squatting in the AWS Security Agent Plugin (aws-agents-for-devsecops) before 1.1.0 allows a remote unauthenticated attacker to intercept private workspace source archives uploaded during security scans. Because the S3 bucket name is deterministically derived from the victim's AWS account ID and region - both non-secret and frequently exposed in public ARNs, IAM policy documents, and ECR URIs - a third party can pre-register the predictable name in their own AWS account before the victim's setup runs. When a scan is subsequently triggered, the unpatched plugin uploads source.zip (containing source code, credentials, and infrastructure state) to the attacker-controlled bucket without verifying ownership, silently exfiltrating sensitive data. Vendor-released patch: 1.1.0.
Broken Windows directory-ownership verification in gix-sec (gitoxide's trust enforcement crate) causes all filesystem paths to be unconditionally trusted when the process runs with an unfiltered administrative token, nullifying safe.directory protections. Versions 0.13.2 and earlier of gix-sec contain a logic inversion in is_path_owned_by_current_user: the administrator-specific branch checks the SID of the running process against the Administrators group rather than checking the SID of the target directory, so both IsWellKnownSid and CheckTokenMembership always return true for elevated processes regardless of who actually owns the directory. A local limited-privilege attacker can plant a malicious Git repository (configuring core.sshCommand or hooks) in a shared or system-root location and trigger arbitrary code execution with full administrative rights when any admin-level gitoxide-backed operation encounters that path. No CISA KEV listing is present, but a working proof-of-concept is included in the GHSA advisory.