| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A Denial of Service (DoS) vulnerability in Palo Alto Networks PAN-OS software causes the firewall to unexpectedly reboot when processing a specially crafted LLDP frame sent by an unauthenticated adjacent attacker. Repeated attempts to initiate this condition causes the firewall to enter maintenance mode.
This issue does not apply to Cloud NGFWs or Prisma Access software. |
| A problem with a detection mechanism in the Palo Alto Networks Cortex XDR agent on Windows devices enables a user with Windows non-administrative privileges to disable the agent. This vulnerability can also be leveraged by malware to disable the Cortex XDR agent and then perform malicious activity. |
| loona is an experimental, HTTP/1.1 and HTTP/2 implementation in Rust on top of io-uring. `loona-hpack` suffers from the same vulnerability as the original `hpack` as documented in issue #11. All users who try to decode untrusted input using the Decoder are vulnerable to this exploit. This issue has been addressed in release version 0.4.3. All users are advised to upgrade. There are no known workarounds for this vulnerability. |
| Improper check for unusual or exceptional conditions in the Linux kernel-mode driver for some Intel(R) 800 Series Ethernet before version 1.17.2 may allow an authenticated user to potentially enable escalation of privilege via local access. |
| A vulnerability has been identified in SIPROTEC 4 6MD61 (All versions), SIPROTEC 4 6MD63 (All versions), SIPROTEC 4 6MD66 (All versions), SIPROTEC 4 6MD665 (All versions), SIPROTEC 4 7SA522 (All versions), SIPROTEC 4 7SA6 (All versions < V4.78), SIPROTEC 4 7SD5 (All versions < V4.78), SIPROTEC 4 7SD610 (All versions < V4.78), SIPROTEC 4 7SJ61 (All versions), SIPROTEC 4 7SJ62 (All versions), SIPROTEC 4 7SJ63 (All versions), SIPROTEC 4 7SJ64 (All versions), SIPROTEC 4 7SJ66 (All versions), SIPROTEC 4 7SS52 (All versions), SIPROTEC 4 7ST6 (All versions), SIPROTEC 4 7UM61 (All versions), SIPROTEC 4 7UM62 (All versions), SIPROTEC 4 7UT612 (All versions), SIPROTEC 4 7UT613 (All versions), SIPROTEC 4 7UT63 (All versions), SIPROTEC 4 7VE6 (All versions), SIPROTEC 4 7VK61 (All versions), SIPROTEC 4 7VU683 (All versions), SIPROTEC 4 Compact 7RW80 (All versions), SIPROTEC 4 Compact 7SD80 (All versions), SIPROTEC 4 Compact 7SJ80 (All versions), SIPROTEC 4 Compact 7SJ81 (All versions), SIPROTEC 4 Compact 7SK80 (All versions), SIPROTEC 4 Compact 7SK81 (All versions). Affected devices do not properly handle interrupted operations of file transfer. This could allow an unauthenticated remote attacker to cause a denial of service condition. To restore normal operations, the devices need to be restarted. |
| golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above. |
| Improper conditions check for some Intel(R) Arc™ GPU may allow an authenticated user to potentially enable denial of service via local access. |
| Improper conditions check for the Intel(R) Optane(TM) PMem management software before versions CR_MGMT_02.00.00.4052, CR_MGMT_03.00.00.0538 within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an authenticated user combined with a high complexity attack may enable [cvss_threat_loss_factor]. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires active user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Volto is a ReactJS-based frontend for the Plone Content Management System. Versions 16.34.0 and below, 17.0.0 through 17.22.1, 18.0.0 through 18.27.1, and 19.0.0-alpha.1 through 19.0.0-alpha.5, an anonymous user could cause the NodeJS server part of Volto to quit with an error when visiting a specific URL. This issue is fixed in versions 16.34.1, 17.22.2, 18.27.2 and 19.0.0-alpha.6. |
| A Local Privilege Escalation vulnerability exists in the affected product. The vulnerability requires a local, low privileged threat actor to replace certain files during update and exists due to a failure to perform proper security checks before installation. |
| OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. In version 4.5.0, using a specially crafted tee-supplicant binary running in REE userspace, an attacker can trigger a panic in a TA that uses the libutee Secure Storage API. Many functions in libutee, specifically those which make up the Secure Storage API, will panic if a system call returns an unexpected return code. This behavior is mandated by the TEE Internal Core API specification. However, in OP-TEE’s implementation, return codes of secure storage operations are passed through unsanitized from the REE tee-supplicant, through the Linux kernel tee-driver, through the OP-TEE kernel, back to libutee. Thus, an attacker with access to REE userspace, and the ability to stop tee-supplicant and replace it with their own process (generally trivial for a root user, and depending on the way permissions are set up, potentially available even to less privileged users) can run a malicious tee-supplicant process that responds to storage requests with unexpected response codes, triggering a panic in the requesting TA. This is particularly dangerous for TAs built with `TA_FLAG_SINGLE_INSTANCE` (corresponding to `gpd.ta.singleInstance` and `TA_FLAG_INSTANCE_KEEP_ALIVE` (corresponding to `gpd.ta.keepAlive`). The behavior of these TAs may depend on memory that is preserved between sessions, and the ability of an attacker to panic the TA and reload it with a clean memory space can compromise the behavior of those TAs. A critical example of this is the optee_ftpm TA. It uses the kept alive memory to hold PCR values, which crucially must be non-resettable. An attacker who can trigger a panic in the fTPM TA can reset the PCRs, and then extend them PCRs with whatever they choose, falsifying boot measurements, accessing sealed data, and potentially more. The impact of this issue depends significantly on the behavior of affected TAs. For some, it could manifest as a denial of service, while for others, like the fTPM TA, it can result in the disclosure of sensitive data. Anyone running the fTPM TA is affected, but similar attacks may be possible on other TAs that leverage the Secure Storage API. A fix is available in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f. |
| The sequence of packets received by a Networking server are not correctly checked.
An attacker could exploit this vulnerability to send specially crafted messages to force the application to stop. |
| matrix-appservice-irc is a Node.js IRC bridge for the Matrix messaging protocol. The fix for GHSA-wm4w-7h2q-3pf7 / CVE-2024-32000 included in matrix-appservice-irc 2.0.0 relied on the Matrix homeserver-provided timestamp to determine whether a user has access to the event they're replying to when determining whether or not to include a truncated version of the original event in the IRC message. Since this value is controlled by external entities, a malicious Matrix homeserver joined to a room in which a matrix-appservice-irc bridge instance (before version 2.0.1) is present can fabricate the timestamp with the intent of tricking the bridge into leaking room messages the homeserver should not have access to. matrix-appservice-irc 2.0.1 drops the reliance on `origin_server_ts` when determining whether or not an event should be visible to a user, instead tracking the event timestamps internally. As a workaround, it's possible to limit the amount of information leaked by setting a reply template that doesn't contain the original message. |
| An issue in skteco.com Central Control Attendance Machine web management platform v.3.0 allows an attacker to obtain sensitive information via a crafted script to the csl/user component. |
| quic-go is an implementation of the QUIC protocol in Go. In versions prior to 0.49.0, 0.54.1, and 0.55.0, a misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. This was observed in the wild with certain server implementations. quic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. Versions 0.49.0, 0.54.1, and 0.55.0 discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames. |
| Improper conditions check in Linux kernel mode driver for some Intel(R) Ethernet Network Controllers and Adapters E810 Series before version 28.3 may allow an authenticated user to potentially enable denial of service via local access. |
| matrix-hookshot is a Matrix bot for connecting to external services like GitHub, GitLab, JIRA, and more. When Hookshot 6 version 6.0.1 or below, or Hookshot 5 version 5.4.1 or below, is configured with GitHub support, it is vulnerable to a Denial of Service (DoS) whereby it can crash on restart due to a missing check. The impact is greater to you untrusted users can add their own GitHub organizations to Hookshot in order to connect their room to a repository. This vulnerability is fixed in 6.0.2 and 5.4.2. |
| Improper check for unusual or exceptional conditions in Intel(R) TDX Module firmware before version 1.5.06 may allow a privileged user to potentially enable information disclosure via local access. |
| Polkadot Frontier is an Ethereum and EVM compatibility layer for Polkadot and Substrate. The extrinsic note_min_gas_price_target is an inherent extrinsic, meaning only the block producer can call it. To ensure correctness, the ProvideInherent trait should be implemented for each inherent, which includes the check_inherent call. This allows other nodes to verify if the input (in this case, the target value) is correct. However, prior to commit a754b3d, the check_inherent function has not been implemented for note_min_gas_price_target. This lets the block producer set the target value without verification. The target is then used to set the MinGasPrice, which has an upper and lower bound defined in the on_initialize hook. The block producer can set the target to the upper bound. Which also increases the upper and lower bounds for the next block. Over time, this could result in continuously raising the gas price, making contract execution too expensive and ineffective for users. An attacker could use this flaw to manipulate the gas price, potentially leading to significantly inflated transaction fees. Such manipulation could render contract execution prohibitively expensive for users, effectively resulting in a denial-of-service condition for the network. This is fixed in version a754b3d. |
| Volto is a React based frontend for the Plone Content Management System. In versions from 19.0.0-alpha.1 to before 19.0.0-alpha.4, 18.0.0 to before 18.24.0, 17.0.0 to before 17.22.1, and prior to 16.34.0, an anonymous user could cause the NodeJS server part of Volto to quit with an error when visiting a specific URL. The problem has been patched in versions 16.34.0, 17.22.1, 18.24.0, and 19.0.0-alpha.4. To mitigate downtime, have setup automatically restart processes that quit with an error. |
