ghsa

HashiCorp Vault and Vault Enterprise allowed the enumeration of users via the LDAP auth method. Fixed in 1.5.6 and 1.6.1.

HashiCorp Consul and Consul Enterprise 1.2.0 up to 1.8.5 allowed operators with operator:read ACL permissions to read the Connect CA private key configuration. Fixed in 1.6.10, 1.7.10, and 1.8.6.

HashiCorp Consul Enterprise versions 1.7.0 up to 1.7.8 and 1.8.0 up to 1.8.4 includes a namespace replication bug which can be triggered to cause denial of service via infinite Raft writes. Fixed in 1.7.9 and 1.8.5.

### Impact In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from `runc exec`) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through `runc run` ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b"). Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b are arguably more dangerous in practice because they allow for a breakout from inside a container as opposed to requiring a user execute a malicious image. The reason attacks 1 and 3a are scored higher is because being able to socially engineer users is treated as a given for UI:R ...

### Impact A malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic. ### Patches The issue has been fixed in v0.12.5 ### Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the `#syntax` line on your Dockerfile, or with `--frontend` flag when using `buildctl build` command. ### References

### Impact Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. ### Patches The issue has been fixed in v0.12.5 ### Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with `--mount=type=cache,source=...` options. ### References https://www.openwall.com/lists/oss-security/2019/05/28/1

### Impact A malicious BuildKit frontend or Dockerfile using `RUN --mount` could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. ### Patches The issue has been fixed in v0.12.5 ### Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing `RUN --mount` feature. ### References

### Impact In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. It was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special `security.insecure` entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request. ### Patches The issue has been fixed in v0.12.5 . ### Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the `#syntax` line on your Dockerfile, or with `--frontend` flag when using `buildctl build` command. ### References

### Summary A ReDoS vulnerability occurs when nodemailer tries to parse img files with the parameter `attachDataUrls` set, causing the stuck of event loop. Another flaw was found when nodemailer tries to parse an attachments with a embedded file, causing the stuck of event loop. ### Details Regex: /^data:((?:[^;]*;)*(?:[^,]*)),(.*)$/ Path: compile -> getAttachments -> _processDataUrl Regex: /(<img\b[^>]* src\s*=[\s"']*)(data:([^;]+);[^"'>\s]+)/ Path: _convertDataImages ### PoC https://gist.github.com/francoatmega/890dd5053375333e40c6fdbcc8c58df6 https://gist.github.com/francoatmega/9aab042b0b24968d7b7039818e8b2698 ### Impact ReDoS causes the event loop to stuck a specially crafted evil email can cause this problem.

### Impact It is possible to craft an OCI tar archive that, when stereoscope attempts to unarchive the contents, will result in writing to paths outside of the unarchive temporary directory. Specifically, use of `github.com/anchore/stereoscope/pkg/file.UntarToDirectory()` function, the `github.com/anchore/stereoscope/pkg/image/oci.TarballImageProvider` struct, or the higher level `github.com/anchore/stereoscope/pkg/image.Image.Read()` function express this vulnerability. ### Patches Patched in v0.0.1 ### Workarounds If you are using the OCI archive as input into stereoscope then you can switch to using an [OCI layout](https://github.com/opencontainers/image-spec/blob/main/image-layout.md) by unarchiving the tar archive and provide the unarchived directory to stereoscope. ### References - Patch PR https://github.com/anchore/stereoscope/pull/214