| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| If the value passed to os.path.expandvars() is user-controlled a
performance degradation is possible when expanding environment
variables. |
| Plex Media Server (PMS) through 1.42.2.10156 allows retrieval of a permanent access token via a /myplex/account call with a transient access token. |
| In Plex Media Server (PMS) through 1.42.2.10156, ability to access /myplex/account with a device token is not properly aligned with whether the device is currently associated with an account. |
| In the plex.tv backend for Plex Media Server (PMS) through 2025-12-31, a non-server device token can retrieve other tokens (intended for unrelated access) via clients.plex.tv/devices.xml. |
| In the plex.tv backend for Plex Media Server (PMS) through 2025-12-31, a non-server device token can retrieve share tokens (intended for unrelated access) via a shared_servers endpoint. |
| A vulnerability was determined in PluXml up to 5.8.22. Affected is the function FileCookieJar::__destruct of the file core/admin/medias.php of the component Media Management Module. Executing a manipulation of the argument File can lead to deserialization. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. The vendor was informed early about this issue and announced that "[w]e fix this issue in the next version 5.8.23". A patch for it is ready. |
| A vulnerability was found in LigeroSmart up to 6.1.24. This affects an unknown part of the component Environment Variable Handler. Performing a manipulation of the argument REQUEST_URI results in cross site scripting. The attack may be initiated remotely. The exploit has been made public and could be used. Upgrading to version 6.1.26 and 6.3 is able to mitigate this issue. The patch is named 264ac5b2be5b3c673ebd8cb862e673f5d300d9a7. The affected component should be upgraded. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: avoid chain re-validation if possible
Hamza Mahfooz reports cpu soft lock-ups in
nft_chain_validate():
watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547]
[..]
RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]
[..]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_table_validate+0x6b/0xb0 [nf_tables]
nf_tables_validate+0x8b/0xa0 [nf_tables]
nf_tables_commit+0x1df/0x1eb0 [nf_tables]
[..]
Currently nf_tables will traverse the entire table (chain graph), starting
from the entry points (base chains), exploring all possible paths
(chain jumps). But there are cases where we could avoid revalidation.
Consider:
1 input -> j2 -> j3
2 input -> j2 -> j3
3 input -> j1 -> j2 -> j3
Then the second rule does not need to revalidate j2, and, by extension j3,
because this was already checked during validation of the first rule.
We need to validate it only for rule 3.
This is needed because chain loop detection also ensures we do not exceed
the jump stack: Just because we know that j2 is cycle free, its last jump
might now exceed the allowed stack size. We also need to update all
reachable chains with the new largest observed call depth.
Care has to be taken to revalidate even if the chain depth won't be an
issue: chain validation also ensures that expressions are not called from
invalid base chains. For example, the masquerade expression can only be
called from NAT postrouting base chains.
Therefore we also need to keep record of the base chain context (type,
hooknum) and revalidate if the chain becomes reachable from a different
hook location. |
| Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Nuvation Energy Multi-Stack Controller (MSC) allows OS Command Injection.This issue affects Multi-Stack Controller (MSC): before 2.5.1. |
| Unintended Proxy or Intermediary vulnerability in Nuvation Energy Multi-Stack Controller (MSC) allows Network Boundary Bridging.This issue affects Multi-Stack Controller (MSC): through and including release 2.5.1. |
| Insufficiently Protected Credentials vulnerability in Nuvation Energy Multi-Stack Controller (MSC) allows Signature Spoofing by Key Theft.This issue affects Multi-Stack Controller (MSC): through 2.5.1. |
| Authentication Bypass Using an Alternate Path or Channel vulnerability in Nuvation Energy Multi-Stack Controller (MSC) allows Authentication Bypass.This issue affects Multi-Stack Controller (MSC): from 2.3.8 before 2.5.1. |
| Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Nuvation Energy Multi-Stack Controller (MSC) allows OS Command Injection.This issue affects Multi-Stack Controller (MSC): from 2.3.8 before 2.5.1. |
| Out of bounds read in V8 in Google Chrome prior to 134.0.6998.35 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High) |
| Improper Limitation of a Pathname to a Restricted Directory in DevTools in Google Chrome on Windows prior to 134.0.6998.35 allowed an attacker who convinced a user to install a malicious extension to bypass file access restrictions via a crafted Chrome Extension. (Chromium security severity: Medium) |
| Out of bounds read in Media in Google Chrome prior to 134.0.6998.35 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Medium) |
| Prototype pollution in Kibana leads to arbitrary code execution via a crafted file upload and specifically crafted HTTP requests.
In Kibana versions >= 8.15.0 and < 8.17.1, this is exploitable by users with the Viewer role. In Kibana versions 8.17.1 and 8.17.2 , this is only exploitable by users that have roles that contain all the following privileges: fleet-all, integrations-all, actions:execute-advanced-connectors |
| A vulnerability in the interprocess communication (IPC) channel of Cisco Secure Client for Windows could allow an authenticated, local attacker to perform a DLL hijacking attack on an affected device if the Secure Firewall Posture Engine, formerly HostScan, is installed on Cisco Secure Client.
This vulnerability is due to insufficient validation of resources that are loaded by the application at run time. An attacker could exploit this vulnerability by sending a crafted IPC message to a specific Cisco Secure Client process. A successful exploit could allow the attacker to execute arbitrary code on the affected machine with SYSTEM privileges. To exploit this vulnerability, the attacker must have valid user credentials on the Windows system. |
| Jinja is an extensible templating engine. Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6. |
| Improper access control in SecSettingsIntelligence prior to SMR Mar-2025 Release 1 allows local attackers to launch privileged activities. User interaction is required for triggering this vulnerability. |
