| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| comrak is a CommonMark + GFM compatible Markdown parser and renderer written in rust. A Comrak AST can be constructed manually by a program instead of parsing a Markdown document with `parse_document`. This AST can then be converted to HTML via `html::format_document_with_plugins`. However, the HTML formatting code assumes that the AST is well-formed. For example, many AST notes contain `[u8]` fields which the formatting code assumes is valid UTF-8 data. Several bugs can be triggered if this is not the case. Version 0.17.0 contains adjustments to the AST, storing strings instead of unvalidated byte arrays. Users are advised to upgrade. Users unable to upgrade may manually validate UTF-8 correctness of all data when assigning to `&[u8]` and `Vec<u8>` fields in the AST. This issue is also tracked as `GHSL-2023-049`. |
| An injection issue was addressed with improved input validation. This issue is fixed in macOS Sonoma 14.4, macOS Monterey 12.7.4, macOS Ventura 13.6.5. An app may be able to elevate privileges. |
| An injection issue was addressed with improved input validation. This issue is fixed in macOS Sonoma 14.4, macOS Monterey 12.7.4, macOS Ventura 13.6.5. An app may be able to elevate privileges. |
| TypedArrays can be fallible and lacked proper exception handling. This could lead to abuse in other APIs which expect TypedArrays to always succeed. This vulnerability affects Firefox < 121. |
| Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to an Incorrect Check of Function Return Value bug Squid is vulnerable to a Denial of Service attack against its Helper process management. This bug is fixed by Squid version 6.5. Users are advised to upgrade. There are no known workarounds for this vulnerability. |
| Vim is an open source command line text editor. A floating point exception may occur when calculating the line offset for overlong lines and smooth scrolling is enabled and the cpo-settings include the 'n' flag. This may happen when a window border is present and when the wrapped line continues on the next physical line directly in the window border because the 'cpo' setting includes the 'n' flag. Only users with non-default settings are affected and the exception should only result in a crash. This issue has been addressed in commit `cb0b99f0` which has been included in release version 9.0.2107. Users are advised to upgrade. There are no known workarounds for this vulnerability. |
| ** UNSUPPORTED WHEN ASSIGNED ** When integrating Apache Axis 1.x in an application, it may not have been obvious that looking up a service through "ServiceFactory.getService" allows potentially dangerous lookup mechanisms such as LDAP. When passing untrusted input to this API method, this could expose the application to DoS, SSRF and even attacks leading to RCE.
As Axis 1 has been EOL we recommend you migrate to a different SOAP engine, such as Apache Axis 2/Java. As a workaround, you may review your code to verify no untrusted or unsanitized input is passed to "ServiceFactory.getService", or by applying the patch from https://github.com/apache/axis-axis1-java/commit/7e66753427466590d6def0125e448d2791723210 . The Apache Axis project does not expect to create an Axis 1.x release fixing this problem, though contributors that would like to work towards this are welcome. |
| The vulnerability is caused by improper check for check if RDLENGTH does not overflow the buffer in response from DNS server. |
| Moby) is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*.
Swarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.
The `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.
Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.
When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.
The `overlay` driver dynamically and lazily defines the kernel configuration for the VXLAN network on each node as containers are attached and detached. Routes and encryption parameters are only defined for destination nodes that participate in the network. The iptables rules that prevent encrypted overlay networks from accepting unencrypted packets are not created until a peer is available with which to communicate.
Encrypted overlay networks silently accept cleartext VXLAN datagrams that are tagged with the VNI of an encrypted overlay network. As a result, it is possible to inject arbitrary Ethernet frames into the encrypted overlay network by encapsulating them in VXLAN datagrams. The implications of this can be quite dire, and GHSA-vwm3-crmr-xfxw should be referenced for a deeper exploration.
Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.
Some workarounds are available. In multi-node clusters, deploy a global ‘pause’ container for each encrypted overlay network, on every node. For a single-node cluster, do not use overlay networks of any sort. Bridge networks provide the same connectivity on a single node and have no multi-node features. The Swarm ingress feature is implemented using an overlay network, but can be disabled by publishing ports in `host` mode instead of `ingress` mode (allowing the use of an external load balancer), and removing the `ingress` network. If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec. |
| Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*.
Swarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.
The `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.
Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.
When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.
An iptables rule designates outgoing VXLAN datagrams with a VNI that corresponds to an encrypted overlay network for IPsec encapsulation.
Encrypted overlay networks on affected platforms silently transmit unencrypted data. As a result, `overlay` networks may appear to be functional, passing traffic as expected, but without any of the expected confidentiality or data integrity guarantees.
It is possible for an attacker sitting in a trusted position on the network to read all of the application traffic that is moving across the overlay network, resulting in unexpected secrets or user data disclosure. Thus, because many database protocols, internal APIs, etc. are not protected by a second layer of encryption, a user may use Swarm encrypted overlay networks to provide confidentiality, which due to this vulnerability this is no longer guaranteed.
Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.
Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to outgoing traffic at the Internet boundary in order to prevent unintentionally leaking unencrypted traffic over the Internet, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster. |
| Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby, is commonly referred to as *Docker*.
Swarm Mode, which is compiled in and delivered by default in dockerd and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.
The overlay network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.
Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.
When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the u32 iptables extension provided by the xt_u32 kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.
Two iptables rules serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the INPUT filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded.
The injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container’s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network.
Patches are available in Moby releases 23.0.3 and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.
Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to incoming traffic at the Internet boundary to prevent all VXLAN packet injection, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster. |
| A flaw was found in the Ceph RGW configuration with Beast as the front end handling client requests. An unauthenticated attacker could crash the Ceph RGW server by sending valid HTTP headers and terminating the connection, resulting in a remote denial of service for Ceph RGW clients. |
| An issue was discovered on Mercusys MW325R EU V3 MW325R(EU)_V3_1.11.0 221019 devices. A WAN attacker can make the admin interface unreachable/invisible via an unauthenticated HTTP request. Verification of the data sent by the user does not occur. The web server does not crash, but the admin interface becomes invisible, because the files necessary to display the content are no longer available. A reboot of the router is typically required to restore the correct behavior. |
| 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 Input Validation vulnerability in ABB AC500 V2 PM5xx allows Client-Server Protocol Manipulation.This issue affects AC500 V2: from 2.0.0 before 2.8.6.
|
| Failure to Sanitize Special Elements into a Different Plane (Special Element Injection) in GitHub repository thorsten/phpmyfaq prior to 3.1.12. |
| vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules. Prior to version 3.9.15, vm2 was not properly handling host objects passed to `Error.prepareStackTrace` in case of unhandled async errors. A threat actor could bypass the sandbox protections to gain remote code execution rights on the host running the sandbox. This vulnerability was patched in the release of version 3.9.15 of vm2. There are no known workarounds. |
| An Improper Handling of Exceptional Conditions vulnerability in Juniper Networks Junos OS and Junos OS Evolved allows an adjacent unauthenticated attacker to cause a Denial of Service (DoS), which causes the l2cpd process to crash by sending a specific TLV.
The l2cpd process is responsible for layer 2 control protocols, such as STP, RSTP, MSTP, VSTP, ERP, and LLDP. The impact of the l2cpd crash is reinitialization of STP protocols (RSTP, MSTP or VSTP), and MVRP and ERP, leading to a Denial of Service. Continued receipt and processing of this specific TLV will create a sustained Denial of Service (DoS) condition.
This issue affects:
Junos OS:
all versions before 20.4R3-S9,
from 21.2 before 21.2R3-S7,
from 21.3 before 21.3R3-S5,
from 21.4 before 21.4R3-S4,
from 22.1 before 22.1R3-S4,
from 22.2 before 22.2R3-S2,
from 22.3 before 22.3R2-S2, 22.3R3-S1,
from 22.4 before 22.4R2-S2, 22.4R3,
from 23.2 before 23.2R1-S1, 23.2R2;
Junos OS Evolved:
all versions before 21.2R3-S7,
from 21.3 before 21.3R3-S5-EVO,
from 21.4 before 21.4R3-S5-EVO,
from 22.1 before 22.1R3-S4-EVO,
from 22.2 before 22.2R3-S2-EVO,
from 22.3 before 22.3R2-S2-EVO, 22.3R3-S1-EVO,
from 22.4 before 22.4R2-S2-EVO, 22.4R3-EVO,
from 23.2 before 23.2R1-S1-EVO, 23.2R2-EVO. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in packet processing of Juniper Networks Junos OS Evolved may allow a network-based unauthenticated attacker to crash the device (vmcore) by sending a specific TCP packet over an established TCP session with MD5 authentication enabled, destined to an accessible port on the device, resulting in a Denial of Service (DoS). The receipt of this packet must occur within a specific timing window outside the attacker's control (i.e., race condition).
Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition.
This issue only affects dual RE systems with Nonstop Active Routing (NSR) enabled.
Exploitation can only occur over TCP sessions with MD5 authentication enabled (e.g., BGP with MD5 authentication).
This issue affects Junos OS Evolved:
* All versions before 21.2R3-S8-EVO,
* from 21.4-EVO before 21.4R3-S6-EVO,
* from 22.1-EVO before 22.1R3-S4-EVO,
* from 22.2-EVO before 22.2R3-S4-EVO,
* from 22.3-EVO before 22.3R3-S3-EVO,
* from 22.4-EVO before 22.4R2-S2-EVO, 22.4R3-EVO. |
| An Improper Handling of Exceptional Conditions vulnerability in the Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an attacker sending a specific malformed BGP update message to cause the session to reset, resulting in a Denial of Service (DoS). Continued receipt and processing of these malformed BGP update messages will create a sustained Denial of Service (DoS) condition.
Upon receipt of a BGP update message over an established BGP session containing a specifically malformed tunnel encapsulation attribute, when segment routing is enabled, internal processing of the malformed attributes within the update results in improper parsing of remaining attributes, leading to session reset:
BGP SEND Notification code 3 (Update Message Error) subcode 1 (invalid attribute list)
Only systems with segment routing enabled are vulnerable to this issue.
This issue affects eBGP and iBGP, in both IPv4 and IPv6 implementations, and requires a remote attacker to have at least one established BGP session.
This issue affects:
Junos OS:
* All versions before 21.4R3-S8,
* from 22.2 before 22.2R3-S4,
* from 22.3 before 22.3R3-S3,
* from 22.4 before 22.4R3-S3,
* from 23.2 before 23.2R2-S1,
* from 23.4 before 23.4R1-S2, 23.4R2.
Junos OS Evolved:
* All versions before 21.4R3-S8-EVO,
* from 22.2-EVO before 22.2R3-S4-EVO,
* from 22.3-EVO before 22.3R3-S3-EVO,
* from 22.4-EVO before 22.4R3-S3-EVO,
* from 23.2-EVO before 23.2R2-S1-EVO,
* from 23.4-EVO before 23.4R1-S2-EVO, 23.4R2-EVO. |
