Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory.

redhat_unpatched go-yaml: go-yaml: Unpatched vulnerabilities

The remote Redhat Enterprise Linux 8 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2023:1275 advisory.

  - golang: net/http: improper sanitization of Transfer-Encoding header (CVE-2022-1705)

  - golang: net/http/httputil: ReverseProxy should not forward unparseable query parameters (CVE-2022-2880)

  - go-yaml: Improve heuristics preventing CPU/memory abuse by parsing malicious or large YAML documents     (CVE-2022-3064)

  - golang: net/http: handle server errors after sending GOAWAY (CVE-2022-27664)

  - golang: crypto/tls: session tickets lack random ticket_age_add (CVE-2022-30629)

  - golang: io/fs: stack exhaustion in Glob (CVE-2022-30630)

  - golang: path/filepath: stack exhaustion in Glob (CVE-2022-30632)

  - golang: encoding/gob: stack exhaustion in Decoder.Decode (CVE-2022-30635)

  - golang: net/http/httputil: NewSingleHostReverseProxy - omit X-Forwarded-For not working (CVE-2022-32148)

  - golang: math/big: decoding big.Float and big.Rat types can panic if the encoded message is too short,     potentially allowing a denial of service (CVE-2022-32189)

  - golang: regexp/syntax: limit memory used by parsing regexps (CVE-2022-41715)

  - golang: net/http: excessive memory growth in a Go server accepting HTTP/2 requests (CVE-2022-41717)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Redhat Enterprise Linux 9 host has a package installed that is affected by a vulnerability as referenced in the RHSA-2023:1014 advisory.

  - go-yaml: Improve heuristics preventing CPU/memory abuse by parsing malicious or large YAML documents     (CVE-2022-3064)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote Oracle Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2023-6939 advisory.

  - Text nodes not in the HTML namespace are incorrectly literally rendered, causing text which should be     escaped to not be. This could lead to an XSS attack. (CVE-2023-3978)

  - Not all valid JavaScript whitespace characters are considered to be whitespace. Templates containing     whitespace characters outside of the character set \t\n\f\r\u0020\u2028\u2029 in JavaScript contexts     that also contain actions may not be properly sanitized during execution. (CVE-2023-24540)

  - A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient     to cause a denial of service from a small number of small requests. (CVE-2022-41723)

  - Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them     as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template     action within a Javascript template literal, the contents of the action can be used to terminate the     literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather     complex, and themselves can do string interpolation, the decision was made to simply disallow Go template     actions from being used inside of them (e.g. var a = {{.}}), since there is no obviously safe way to     allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse     returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is     currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous     behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will     now be escaped. This should be used with caution. (CVE-2023-24538)

  - containerd is an open source container runtime. A bug was found in containerd prior to versions 1.6.18 and     1.5.18 where supplementary groups are not set up properly inside a container. If an attacker has direct     access to a container and manipulates their supplementary group access, they may be able to use     supplementary group access to bypass primary group restrictions in some cases, potentially gaining access     to sensitive information or gaining the ability to execute code in that container. Downstream applications     that use the containerd client library may be affected as well. This bug has been fixed in containerd     v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue.
    Users who rely on a downstream application that uses containerd's client library should check that     application for a separate advisory and instructions. As a workaround, ensure that the `USER $USERNAME`     Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to     `ENTRYPOINT [su, -, user]` to allow `su` to properly set up supplementary groups. (CVE-2023-25173)

  - runc through 1.1.4 has Incorrect Access Control leading to Escalation of Privileges, related to     libcontainer/rootfs_linux.go. To exploit this, an attacker must be able to spawn two containers with     custom volume-mount configurations, and be able to run custom images. NOTE: this issue exists because of a     CVE-2019-19921 regression. (CVE-2023-27561)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

  - Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing     very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the     total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed,     leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased     pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3.
    ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage     collector. The combination of these factors can permit an attacker to cause an program that parses     multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service.
    This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http     package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix,     ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many     fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits     on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit     may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with     NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with     ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with     the environment variable GODEBUG=multipartmaxheaders=. (CVE-2023-24536)

  - runc is a CLI tool for spawning and running containers according to the OCI specification. In affected     versions it was found that rootless runc makes `/sys/fs/cgroup` writable in following conditons: 1. when     runc is executed inside the user namespace, and the `config.json` does not specify the cgroup namespace to     be unshared (e.g.., `(docker|podman|nerdctl) run --cgroupns=host`, with Rootless Docker/Podman/nerdctl) or     2. when runc is executed outside the user namespace, and `/sys` is mounted with `rbind, ro` (e.g., `runc     spec --rootless`; this condition is very rare). A container may gain the write access to user-owned cgroup     hierarchy `/sys/fs/cgroup/user.slice/...` on the host . Other users's cgroup hierarchies are not affected.
    Users are advised to upgrade to version 1.1.5. Users unable to upgrade may unshare the cgroup namespace     (`(docker|podman|nerdctl) run --cgroupns=private)`. This is the default behavior of Docker/Podman/nerdctl     on cgroup v2 hosts. or add `/sys/fs/cgroup` to `maskedPaths`. (CVE-2023-25809)

  - The HTTP/1 client does not fully validate the contents of the Host header. A maliciously crafted Host     header can inject additional headers or entire requests. With fix, the HTTP/1 client now refuses to send     requests containing an invalid Request.Host or Request.URL.Host value. (CVE-2023-29406)

  - Large handshake records may cause panics in crypto/tls. Both clients and servers may send large TLS     handshake records which cause servers and clients, respectively, to panic when attempting to construct     responses. This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption     (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client     certificates (by setting Config.ClientAuth >= RequestClientCert). (CVE-2022-41724)

  - Calling any of the Parse functions on Go source code which contains //line directives with very large line     numbers can cause an infinite loop due to integer overflow. (CVE-2023-24537)

  - runc is a CLI tool for spawning and running containers according to the OCI specification. It was found     that AppArmor can be bypassed when `/proc` inside the container is symlinked with a specific mount     configuration. This issue has been fixed in runc version 1.1.5, by prohibiting symlinked `/proc`. See PR     #3785 for details. users are advised to upgrade. Users unable to upgrade should avoid using an untrusted     container image. (CVE-2023-28642)

  - Templates containing actions in unquoted HTML attributes (e.g. attr={{.}}) executed with empty input can     result in output with unexpected results when parsed due to HTML normalization rules. This may allow     injection of arbitrary attributes into tags. (CVE-2023-29400)

  - HTTP and MIME header parsing can allocate large amounts of memory, even when parsing small inputs,     potentially leading to a denial of service. Certain unusual patterns of input data can cause the common     function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold     the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large     amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service.
    With fix, header parsing now correctly allocates only the memory required to hold parsed headers.
    (CVE-2023-24534)

  - Angle brackets (<>) are not considered dangerous characters when inserted into CSS contexts. Templates     containing multiple actions separated by a '/' character can result in unexpectedly closing the CSS     context and allowing for injection of unexpected HTML, if executed with untrusted input. (CVE-2023-24539)

  - A denial of service is possible from excessive resource consumption in net/http and mime/multipart.
    Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory     and disk files. This also affects form parsing in the net/http package with the Request methods FormFile,     FormValue, ParseMultipartForm, and PostFormValue. ReadForm takes a maxMemory parameter, and is documented     as storing up to maxMemory bytes +10MB (reserved for non-file parts) in memory. File parts which cannot     be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file     parts is excessively large and can potentially open a denial of service vector on its own. However,     ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead,     part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In     addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small     request body to create a large number of disk temporary files. With fix, ReadForm now properly accounts     for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory     bytes of memory consumption. Users should still be aware that this limit is high and may still be     hazardous. In addition, ReadForm now creates at most one on-disk temporary file, combining multiple form     parts into a single temporary file. The mime/multipart.File interface type's documentation states, If     stored on disk, the File's underlying concrete type will be an *os.File.. This is no longer the case when     a form contains more than one file part, due to this coalescing of parts into a single file. The previous     behavior of using distinct files for each form part may be reenabled with the environment variable     GODEBUG=multipartfiles=distinct. Users should be aware that multipart.ReadForm and the http.Request     methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the     size of form data with http.MaxBytesReader. (CVE-2022-41725)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Oracle Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2023-6938 advisory.

  - The HTTP/1 client does not fully validate the contents of the Host header. A maliciously crafted Host     header can inject additional headers or entire requests. With fix, the HTTP/1 client now refuses to send     requests containing an invalid Request.Host or Request.URL.Host value. (CVE-2023-29406)

  - A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient     to cause a denial of service from a small number of small requests. (CVE-2022-41723)

  - Text nodes not in the HTML namespace are incorrectly literally rendered, causing text which should be     escaped to not be. This could lead to an XSS attack. (CVE-2023-3978)

  - runc is a CLI tool for spawning and running containers according to the OCI specification. In affected     versions it was found that rootless runc makes `/sys/fs/cgroup` writable in following conditons: 1. when     runc is executed inside the user namespace, and the `config.json` does not specify the cgroup namespace to     be unshared (e.g.., `(docker|podman|nerdctl) run --cgroupns=host`, with Rootless Docker/Podman/nerdctl) or     2. when runc is executed outside the user namespace, and `/sys` is mounted with `rbind, ro` (e.g., `runc     spec --rootless`; this condition is very rare). A container may gain the write access to user-owned cgroup     hierarchy `/sys/fs/cgroup/user.slice/...` on the host . Other users's cgroup hierarchies are not affected.
    Users are advised to upgrade to version 1.1.5. Users unable to upgrade may unshare the cgroup namespace     (`(docker|podman|nerdctl) run --cgroupns=private)`. This is the default behavior of Docker/Podman/nerdctl     on cgroup v2 hosts. or add `/sys/fs/cgroup` to `maskedPaths`. (CVE-2023-25809)

  - Templates containing actions in unquoted HTML attributes (e.g. attr={{.}}) executed with empty input can     result in output with unexpected results when parsed due to HTML normalization rules. This may allow     injection of arbitrary attributes into tags. (CVE-2023-29400)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

  - HTTP and MIME header parsing can allocate large amounts of memory, even when parsing small inputs,     potentially leading to a denial of service. Certain unusual patterns of input data can cause the common     function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold     the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large     amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service.
    With fix, header parsing now correctly allocates only the memory required to hold parsed headers.
    (CVE-2023-24534)

  - Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing     very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the     total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed,     leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased     pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3.
    ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage     collector. The combination of these factors can permit an attacker to cause an program that parses     multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service.
    This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http     package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix,     ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many     fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits     on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit     may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with     NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with     ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with     the environment variable GODEBUG=multipartmaxheaders=. (CVE-2023-24536)

  - Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them     as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template     action within a Javascript template literal, the contents of the action can be used to terminate the     literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather     complex, and themselves can do string interpolation, the decision was made to simply disallow Go template     actions from being used inside of them (e.g. var a = {{.}}), since there is no obviously safe way to     allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse     returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is     currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous     behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will     now be escaped. This should be used with caution. (CVE-2023-24538)

  - Large handshake records may cause panics in crypto/tls. Both clients and servers may send large TLS     handshake records which cause servers and clients, respectively, to panic when attempting to construct     responses. This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption     (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client     certificates (by setting Config.ClientAuth >= RequestClientCert). (CVE-2022-41724)

  - A denial of service is possible from excessive resource consumption in net/http and mime/multipart.
    Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory     and disk files. This also affects form parsing in the net/http package with the Request methods FormFile,     FormValue, ParseMultipartForm, and PostFormValue. ReadForm takes a maxMemory parameter, and is documented     as storing up to maxMemory bytes +10MB (reserved for non-file parts) in memory. File parts which cannot     be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file     parts is excessively large and can potentially open a denial of service vector on its own. However,     ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead,     part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In     addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small     request body to create a large number of disk temporary files. With fix, ReadForm now properly accounts     for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory     bytes of memory consumption. Users should still be aware that this limit is high and may still be     hazardous. In addition, ReadForm now creates at most one on-disk temporary file, combining multiple form     parts into a single temporary file. The mime/multipart.File interface type's documentation states, If     stored on disk, the File's underlying concrete type will be an *os.File.. This is no longer the case when     a form contains more than one file part, due to this coalescing of parts into a single file. The previous     behavior of using distinct files for each form part may be reenabled with the environment variable     GODEBUG=multipartfiles=distinct. Users should be aware that multipart.ReadForm and the http.Request     methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the     size of form data with http.MaxBytesReader. (CVE-2022-41725)

  - Not all valid JavaScript whitespace characters are considered to be whitespace. Templates containing     whitespace characters outside of the character set \t\n\f\r\u0020\u2028\u2029 in JavaScript contexts     that also contain actions may not be properly sanitized during execution. (CVE-2023-24540)

  - runc through 1.1.4 has Incorrect Access Control leading to Escalation of Privileges, related to     libcontainer/rootfs_linux.go. To exploit this, an attacker must be able to spawn two containers with     custom volume-mount configurations, and be able to run custom images. NOTE: this issue exists because of a     CVE-2019-19921 regression. (CVE-2023-27561)

  - Calling any of the Parse functions on Go source code which contains //line directives with very large line     numbers can cause an infinite loop due to integer overflow. (CVE-2023-24537)

  - Angle brackets (<>) are not considered dangerous characters when inserted into CSS contexts. Templates     containing multiple actions separated by a '/' character can result in unexpectedly closing the CSS     context and allowing for injection of unexpected HTML, if executed with untrusted input. (CVE-2023-24539)

  - runc is a CLI tool for spawning and running containers according to the OCI specification. It was found     that AppArmor can be bypassed when `/proc` inside the container is symlinked with a specific mount     configuration. This issue has been fixed in runc version 1.1.5, by prohibiting symlinked `/proc`. See PR     #3785 for details. users are advised to upgrade. Users unable to upgrade should avoid using an untrusted     container image. (CVE-2023-28642)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Redhat Enterprise Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2023:6938 advisory.

  - go-yaml: Improve heuristics preventing CPU/memory abuse by parsing malicious or large YAML documents     (CVE-2022-3064)

  - net/http, golang.org/x/net/http2: avoid quadratic complexity in HPACK decoding (CVE-2022-41723)

  - golang: crypto/tls: large handshake records may cause panics (CVE-2022-41724)

  - golang: net/http, mime/multipart: denial of service from excessive resource consumption (CVE-2022-41725)

  - golang.org/x/net/html: Cross site scripting (CVE-2023-3978)

  - golang: net/http, net/textproto: denial of service from excessive memory allocation (CVE-2023-24534)

  - golang: net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption     (CVE-2023-24536)

  - golang: go/parser: Infinite loop in parsing (CVE-2023-24537)

  - golang: html/template: backticks not treated as string delimiters (CVE-2023-24538)

  - golang: html/template: improper sanitization of CSS values (CVE-2023-24539)

  - golang: html/template: improper handling of JavaScript whitespace (CVE-2023-24540)

  - runc: Rootless runc makes `/sys/fs/cgroup` writable (CVE-2023-25809)

  - runc: volume mount race condition (regression of CVE-2019-19921) (CVE-2023-27561)

  - runc: AppArmor can be bypassed when `/proc` inside the container is symlinked with a specific mount     configuration (CVE-2023-28642)

  - golang: html/template: improper handling of empty HTML attributes (CVE-2023-29400)

  - golang: net/http: insufficient sanitization of Host header (CVE-2023-29406)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Redhat Enterprise Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2023:6939 advisory.

  - go-yaml: Improve heuristics preventing CPU/memory abuse by parsing malicious or large YAML documents     (CVE-2022-3064)

  - net/http, golang.org/x/net/http2: avoid quadratic complexity in HPACK decoding (CVE-2022-41723)

  - golang: crypto/tls: large handshake records may cause panics (CVE-2022-41724)

  - golang: net/http, mime/multipart: denial of service from excessive resource consumption (CVE-2022-41725)

  - golang.org/x/net/html: Cross site scripting (CVE-2023-3978)

  - golang: net/http, net/textproto: denial of service from excessive memory allocation (CVE-2023-24534)

  - golang: net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption     (CVE-2023-24536)

  - golang: go/parser: Infinite loop in parsing (CVE-2023-24537)

  - golang: html/template: backticks not treated as string delimiters (CVE-2023-24538)

  - golang: html/template: improper sanitization of CSS values (CVE-2023-24539)

  - golang: html/template: improper handling of JavaScript whitespace (CVE-2023-24540)

  - containerd: Supplementary groups are not set up properly (CVE-2023-25173)

  - runc: Rootless runc makes `/sys/fs/cgroup` writable (CVE-2023-25809)

  - runc: volume mount race condition (regression of CVE-2019-19921) (CVE-2023-27561)

  - runc: AppArmor can be bypassed when `/proc` inside the container is symlinked with a specific mount     configuration (CVE-2023-28642)

  - golang: html/template: improper handling of empty HTML attributes (CVE-2023-29400)

  - golang: net/http: insufficient sanitization of Host header (CVE-2023-29406)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 39 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2023-e16469fdec advisory.

  - An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server     connections contain a cache of HTTP header keys sent by the client. While the total number of entries in     this cache is capped, an attacker sending very large keys can cause the server to allocate approximately     64 MiB per open connection. (CVE-2022-41717)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 39 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2023-b9c1d0e4c5 advisory.

  - HashiCorp Consul and Consul Enterprise up to 1.11.8, 1.12.4, and 1.13.1 do not check for multiple SAN URI     values in a CSR on the internal RPC endpoint, enabling leverage of privileged access to bypass service     mesh intentions. Fixed in 1.11.9, 1.12.5, and 1.13.2. (CVE-2022-40716)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

  - containerd is an open source container runtime. A bug was found in containerd prior to versions 1.6.18 and     1.5.18 where supplementary groups are not set up properly inside a container. If an attacker has direct     access to a container and manipulates their supplementary group access, they may be able to use     supplementary group access to bypass primary group restrictions in some cases, potentially gaining access     to sensitive information or gaining the ability to execute code in that container. Downstream applications     that use the containerd client library may be affected as well. This bug has been fixed in containerd     v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue.
    Users who rely on a downstream application that uses containerd's client library should check that     application for a separate advisory and instructions. As a workaround, ensure that the `USER $USERNAME`     Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to     `ENTRYPOINT [su, -, user]` to allow `su` to properly set up supplementary groups. (CVE-2023-25173)

  - BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and     repeatable manner. In affected versions when the user sends a build request that contains a Git URL that     contains credentials and the build creates a provenance attestation describing that build, these     credentials could be visible from the provenance attestation. Git URL can be passed in two ways: 1)     Invoking build directly from a URL with credentials. 2) If the client sends additional version control     system (VCS) info hint parameters on builds from a local source. Usually, that would mean reading the     origin URL from `.git/config` file. When a build is performed under specific conditions where credentials     were passed to BuildKit they may be visible to everyone who has access to provenance attestation.
    Provenance attestations and VCS info hints were added in version v0.11.0. Previous versions are not     vulnerable. In v0.10, when building directly from Git URL, the same URL could be visible in `BuildInfo`     structure that is a predecessor of Provenance attestations. Previous versions are not vulnerable. This bug     has been fixed in v0.11.4. Users are advised to upgrade. Users unable to upgrade may disable VCS info     hints by setting `BUILDX_GIT_INFO=0`. `buildctl` does not set VCS hints based on `.git` directory, and     values would need to be passed manually with `--opt`. (CVE-2023-26054)

  - Consul and Consul Enterprise allowed an authenticated user with service:write permissions to trigger a     workflow that causes Consul server and client agents to crash under certain circumstances. This     vulnerability was fixed in Consul 1.14.5. (CVE-2023-0845)

  - 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. (CVE-2023-28840)

  - 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.
    (CVE-2023-28841)

  - 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.
    (CVE-2023-28842)

  - HashiCorp Consul 1.8.1 up to 1.11.8, 1.12.4, and 1.13.1 do not properly validate the node or segment names     prior to interpolation and usage in JWT claim assertions with the auto config RPC. Fixed in 1.11.9,     1.12.5, and 1.13.2. (CVE-2021-41803)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Redhat Enterprise Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2023:6346 advisory.

  - go-yaml: Improve heuristics preventing CPU/memory abuse by parsing malicious or large YAML documents     (CVE-2022-3064)

  - net/http, golang.org/x/net/http2: avoid quadratic complexity in HPACK decoding (CVE-2022-41723)

  - golang: net/http, mime/multipart: denial of service from excessive resource consumption (CVE-2022-41725)

  - golang: net/http, net/textproto: denial of service from excessive memory allocation (CVE-2023-24534)

  - golang: net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption     (CVE-2023-24536)

  - golang: html/template: backticks not treated as string delimiters (CVE-2023-24538)

  - golang: html/template: improper sanitization of CSS values (CVE-2023-24539)

  - golang: html/template: improper handling of JavaScript whitespace (CVE-2023-24540)

  - golang: html/template: improper handling of empty HTML attributes (CVE-2023-29400)

  - golang: net/http: insufficient sanitization of Host header (CVE-2023-29406)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 37 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2023-af2e3d1c18 advisory.

  - An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server     connections contain a cache of HTTP header keys sent by the client. While the total number of entries in     this cache is capped, an attacker sending very large keys can cause the server to allocate approximately     64 MiB per open connection. (CVE-2022-41717)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 37 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2023-cf3551046d advisory.

  - HashiCorp Consul and Consul Enterprise up to 1.11.8, 1.12.4, and 1.13.1 do not check for multiple SAN URI     values in a CSR on the internal RPC endpoint, enabling leverage of privileged access to bypass service     mesh intentions. Fixed in 1.11.9, 1.12.5, and 1.13.2. (CVE-2022-40716)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

  - containerd is an open source container runtime. A bug was found in containerd prior to versions 1.6.18 and     1.5.18 where supplementary groups are not set up properly inside a container. If an attacker has direct     access to a container and manipulates their supplementary group access, they may be able to use     supplementary group access to bypass primary group restrictions in some cases, potentially gaining access     to sensitive information or gaining the ability to execute code in that container. Downstream applications     that use the containerd client library may be affected as well. This bug has been fixed in containerd     v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue.
    Users who rely on a downstream application that uses containerd's client library should check that     application for a separate advisory and instructions. As a workaround, ensure that the `USER $USERNAME`     Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to     `ENTRYPOINT [su, -, user]` to allow `su` to properly set up supplementary groups. (CVE-2023-25173)

  - BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and     repeatable manner. In affected versions when the user sends a build request that contains a Git URL that     contains credentials and the build creates a provenance attestation describing that build, these     credentials could be visible from the provenance attestation. Git URL can be passed in two ways: 1)     Invoking build directly from a URL with credentials. 2) If the client sends additional version control     system (VCS) info hint parameters on builds from a local source. Usually, that would mean reading the     origin URL from `.git/config` file. When a build is performed under specific conditions where credentials     were passed to BuildKit they may be visible to everyone who has access to provenance attestation.
    Provenance attestations and VCS info hints were added in version v0.11.0. Previous versions are not     vulnerable. In v0.10, when building directly from Git URL, the same URL could be visible in `BuildInfo`     structure that is a predecessor of Provenance attestations. Previous versions are not vulnerable. This bug     has been fixed in v0.11.4. Users are advised to upgrade. Users unable to upgrade may disable VCS info     hints by setting `BUILDX_GIT_INFO=0`. `buildctl` does not set VCS hints based on `.git` directory, and     values would need to be passed manually with `--opt`. (CVE-2023-26054)

  - Consul and Consul Enterprise allowed an authenticated user with service:write permissions to trigger a     workflow that causes Consul server and client agents to crash under certain circumstances. This     vulnerability was fixed in Consul 1.14.5. (CVE-2023-0845)

  - 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. (CVE-2023-28840)

  - 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.
    (CVE-2023-28841)

  - 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.
    (CVE-2023-28842)

  - HashiCorp Consul 1.8.1 up to 1.11.8, 1.12.4, and 1.13.1 do not properly validate the node or segment names     prior to interpolation and usage in JWT claim assertions with the auto config RPC. Fixed in 1.11.9,     1.12.5, and 1.13.2. (CVE-2021-41803)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 38 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2023-e82fd2abcb advisory.

  - An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server     connections contain a cache of HTTP header keys sent by the client. While the total number of entries in     this cache is capped, an attacker sending very large keys can cause the server to allocate approximately     64 MiB per open connection. (CVE-2022-41717)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 38 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2023-9f5f1ef40a advisory.

  - HashiCorp Consul and Consul Enterprise up to 1.11.8, 1.12.4, and 1.13.1 do not check for multiple SAN URI     values in a CSR on the internal RPC endpoint, enabling leverage of privileged access to bypass service     mesh intentions. Fixed in 1.11.9, 1.12.5, and 1.13.2. (CVE-2022-40716)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

  - containerd is an open source container runtime. A bug was found in containerd prior to versions 1.6.18 and     1.5.18 where supplementary groups are not set up properly inside a container. If an attacker has direct     access to a container and manipulates their supplementary group access, they may be able to use     supplementary group access to bypass primary group restrictions in some cases, potentially gaining access     to sensitive information or gaining the ability to execute code in that container. Downstream applications     that use the containerd client library may be affected as well. This bug has been fixed in containerd     v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue.
    Users who rely on a downstream application that uses containerd's client library should check that     application for a separate advisory and instructions. As a workaround, ensure that the `USER $USERNAME`     Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to     `ENTRYPOINT [su, -, user]` to allow `su` to properly set up supplementary groups. (CVE-2023-25173)

  - BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and     repeatable manner. In affected versions when the user sends a build request that contains a Git URL that     contains credentials and the build creates a provenance attestation describing that build, these     credentials could be visible from the provenance attestation. Git URL can be passed in two ways: 1)     Invoking build directly from a URL with credentials. 2) If the client sends additional version control     system (VCS) info hint parameters on builds from a local source. Usually, that would mean reading the     origin URL from `.git/config` file. When a build is performed under specific conditions where credentials     were passed to BuildKit they may be visible to everyone who has access to provenance attestation.
    Provenance attestations and VCS info hints were added in version v0.11.0. Previous versions are not     vulnerable. In v0.10, when building directly from Git URL, the same URL could be visible in `BuildInfo`     structure that is a predecessor of Provenance attestations. Previous versions are not vulnerable. This bug     has been fixed in v0.11.4. Users are advised to upgrade. Users unable to upgrade may disable VCS info     hints by setting `BUILDX_GIT_INFO=0`. `buildctl` does not set VCS hints based on `.git` directory, and     values would need to be passed manually with `--opt`. (CVE-2023-26054)

  - Consul and Consul Enterprise allowed an authenticated user with service:write permissions to trigger a     workflow that causes Consul server and client agents to crash under certain circumstances. This     vulnerability was fixed in Consul 1.14.5. (CVE-2023-0845)

  - 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. (CVE-2023-28840)

  - 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.
    (CVE-2023-28841)

  - 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.
    (CVE-2023-28842)

  - HashiCorp Consul 1.8.1 up to 1.11.8, 1.12.4, and 1.13.1 do not properly validate the node or segment names     prior to interpolation and usage in JWT claim assertions with the auto config RPC. Fixed in 1.11.9,     1.12.5, and 1.13.2. (CVE-2021-41803)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Ubuntu 16.04 ESM host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6287-1 advisory.

  - Due to unbounded alias chasing, a maliciously crafted YAML file can cause the system to consume     significant system resources. If parsing user input, this may be used as a denial of service vector.
    (CVE-2021-4235)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Debian 10 host has a package installed that is affected by multiple vulnerabilities as referenced in the dla-3479 advisory.

  - Due to unbounded alias chasing, a maliciously crafted YAML file can cause the system to consume     significant system resources. If parsing user input, this may be used as a denial of service vector.
    (CVE-2021-4235)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 38 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2023-8c02aee138 advisory.

  - An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server     connections contain a cache of HTTP header keys sent by the client. While the total number of entries in     this cache is capped, an attacker sending very large keys can cause the server to allocate approximately     64 MiB per open connection. (CVE-2022-41717)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

  - A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient     to cause a denial of service from a small number of small requests. (CVE-2022-41723)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 36 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2023-abb47e24d8 advisory.

  - An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server     connections contain a cache of HTTP header keys sent by the client. While the total number of entries in     this cache is capped, an attacker sending very large keys can cause the server to allocate approximately     64 MiB per open connection. (CVE-2022-41717)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

  - A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient     to cause a denial of service from a small number of small requests. (CVE-2022-41723)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 37 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2023-ca444fdecf advisory.

  - An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server     connections contain a cache of HTTP header keys sent by the client. While the total number of entries in     this cache is capped, an attacker sending very large keys can cause the server to allocate approximately     64 MiB per open connection. (CVE-2022-41717)

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

  - A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient     to cause a denial of service from a small number of small requests. (CVE-2022-41723)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 36 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2023-a4baceec07 advisory.

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote Fedora 37 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2023-11dafed208 advisory.

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote Fedora 38 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2023-5312f6200c advisory.

  - Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory. (CVE-2022-3064)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
194308	RHEL 8 : Red Hat OpenStack Platform (etcd) (RHSA-2023:1275)	Nessus	Red Hat Local Security Checks	high
194225	RHEL 9 : Red Hat OpenStack Platform 17.0 (etcd) (RHSA-2023:1014)	Nessus	Red Hat Local Security Checks	high
186122	Oracle Linux 8 : container-tools:ol8 (ELSA-2023-6939)	Nessus	Oracle Linux Local Security Checks	critical
186113	Oracle Linux 8 : container-tools:4.0 (ELSA-2023-6938)	Nessus	Oracle Linux Local Security Checks	critical
185685	RHEL 8 : container-tools:4.0 (RHSA-2023:6938)	Nessus	Red Hat Local Security Checks	critical
185675	RHEL 8 : container-tools:rhel8 (RHSA-2023:6939)	Nessus	Red Hat Local Security Checks	critical
185337	Fedora 39 : exercism (2023-e16469fdec)	Nessus	Fedora Local Security Checks	high
185286	Fedora 39 : moby-engine (2023-b9c1d0e4c5)	Nessus	Fedora Local Security Checks	high
185100	RHEL 9 : toolbox (RHSA-2023:6346)	Nessus	Red Hat Local Security Checks	critical
180496	Fedora 37 : exercism (2023-af2e3d1c18)	Nessus	Fedora Local Security Checks	high
180494	Fedora 37 : moby-engine (2023-cf3551046d)	Nessus	Fedora Local Security Checks	high
180493	Fedora 38 : exercism (2023-e82fd2abcb)	Nessus	Fedora Local Security Checks	high
180265	Fedora 38 : moby-engine (2023-9f5f1ef40a)	Nessus	Fedora Local Security Checks	high
179734	Ubuntu 16.04 ESM / 18.04 ESM / 20.04 LTS : Go yaml vulnerabilities (USN-6287-1)	Nessus	Ubuntu Local Security Checks	high
178004	Debian DLA-3479-1 : golang-yaml.v2 - LTS security update	Nessus	Debian Local Security Checks	high
173405	Fedora 38 : gmailctl (2023-8c02aee138)	Nessus	Fedora Local Security Checks	high
173394	Fedora 36 : gmailctl (2023-abb47e24d8)	Nessus	Fedora Local Security Checks	high
173393	Fedora 37 : gmailctl (2023-ca444fdecf)	Nessus	Fedora Local Security Checks	high
172556	Fedora 36 : manifest-tool (2023-a4baceec07)	Nessus	Fedora Local Security Checks	high
172551	Fedora 37 : manifest-tool (2023-11dafed208)	Nessus	Fedora Local Security Checks	high
172454	Fedora 38 : manifest-tool (2023-5312f6200c)	Nessus	Fedora Local Security Checks	high

Detections

Analytics

CVE-2022-3064

high

Tenable Plugins

Coming Soon

high

high

critical

critical

critical

critical

high

high

critical

high

high

high

high

high

high

high

high

high

high

high

high