| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Insertion of sensitive information into log file in Windows ETL Channel allows an authorized attacker to disclose information locally. |
| Improper link resolution before file access ('link following') in XBox Gaming Services allows an authorized attacker to elevate privileges locally. |
| Insertion of sensitive information into log file in Windows Failover Cluster allows an authorized attacker to disclose information locally. |
| Insertion of sensitive information into log file in Active Directory Federation Services allows an unauthorized attacker to disclose information locally. |
| Improper link resolution before file access ('link following') in .NET allows an authorized attacker to elevate privileges locally. |
| A remote code execution vulnerability exists in Microsoft Windows that could allow remote code execution if a .LNK file is processed.
An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
The attacker could present to the user a removable drive, or remote share, that contains a malicious .LNK file and an associated malicious binary. When the user opens this drive(or remote share) in Windows Explorer, or any other application that parses the .LNK file, the malicious binary will execute code of the attacker’s choice, on the target system.
The security update addresses the vulnerability by correcting the processing of shortcut LNK references. |
| Mastodon is a free, open-source social network server based on ActivityPub. Prior to versions 4.3.19, 4.4.13, 4.5.6, Mastodon is vulnerable to web cache poisoning via `Rails.cache. When AUTHORIZED_FETCH is enabled, the ActivityPub endpoints for pinned posts and featured hashtags have contents that depend on the account that signed the HTTP request. However, these contents are stored in an internal cache and reused with no regards to the signing actor. As a result, an empty response generated for a blocked user account may be served to requests from legitimate non-blocked actors, or conversely, content intended for non-blocked actors may be returned to blocked actors. This issue has been patched in versions 4.3.19, 4.4.13, 4.5.6. |
| Tanium addressed an arbitrary file deletion vulnerability in end-user-cx. |
| Dell PowerScale OneFS versions 9.4.0.x through 9.7.0.x contains an insertion of sensitive information into log file vulnerability. A low privileged local attacker could potentially exploit this vulnerability, leading to sensitive information disclosure, escalation of privileges. |
| Dell PowerScale OneFS versions 9.4.0.x through 9.7.0.x contains an UNIX symbolic link (symlink) following vulnerability. A local high privileged attacker could potentially exploit this vulnerability, leading to denial of service, information tampering. |
|
Dell PowerScale OneFS 9.5.0.x, contains an insertion of sensitive information into log file vulnerability in SNMPv3. A low privileges user could potentially exploit this vulnerability, leading to information disclosure.
|
| Dell PowerScale OneFS versions 8.2.2.x through 9.8.0.1 contains a UNIX symbolic link (symlink) following vulnerability. A local high privileged attacker could potentially exploit this vulnerability, leading to denial of service, information tampering. |
| Dell PowerScale OneFS versions 8.2.0.x through 9.3.0.x, contain a weak password requirement vulnerability. An administrator may create an account with no password. A remote attacker may potentially exploit this leading to a user account compromise. |
|
Dell PowerScale OneFS, versions 8.2.x through 9.3.x contain a weak encoding for a password. A malicious local privileged attacker may potentially exploit this vulnerability, leading to information disclosure.
|
| Dell PowerScale OneFS versions 8.2.2.x through 9.7.0.x contains an UNIX symbolic link (symlink) following vulnerability. A local high privileged attacker could potentially exploit this vulnerability, leading to denial of service, information tampering. |
| Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects. |
| Improper link resolution before file access ('link following') in Windows Installer allows an authorized attacker to elevate privileges locally. |
| Deserialization of untrusted data in Microsoft High Performance Compute Pack (HPC) allows an unauthorized attacker to execute code over a network. |
| In Infoblox NIOS through 9.0.7, insecure deserialization can result in remote code execution. |
| The BSV Blockchain SDK is a unified TypeScript SDK for developing scalable apps on the BSV Blockchain. Prior to version 2.0.0, a cryptographic vulnerability in the TypeScript SDK's BRC-104 authentication implementation caused incorrect signature data preparation, resulting in signature incompatibility between SDK implementations and potential authentication bypass scenarios. The vulnerability was located in the `Peer.ts` file of the TypeScript SDK, specifically in the `processInitialRequest` and `processInitialResponse` methods where signature data is prepared for BRC-104 mutual authentication. The TypeScript SDK incorrectly prepared signature data by concatenating base64-encoded nonce strings (`message.initialNonce + sessionNonce`) then decoding the concatenated base64 string (`base64ToBytes(concatenatedString)`). This produced ~32-34 bytes of signature data instead of the correct 64 bytes. BRC-104 authentication relies on cryptographic signatures to establish mutual trust between peers. When signature data preparation is incorrect, signatures generated by the TypeScript SDK don't match those expected by Go/Python SDKs; cross-implementation authentication fails; and an attacker could potentially exploit this to bypass authentication checks. The fix in version 2.0.0 ensures all SDKs now produce identical cryptographic signatures, restoring proper mutual authentication across implementations. |
