Davidkorczynski

**Name of the Vulnerable Software and Affected Versions** Ruby JSON versions 2.14.0 through 2.15.2 Ruby JSON versions 2.17.1 through 2.17.1.2 Ruby JSON versions 2.19.0 through 2.19.2 **Description** Ruby JSON is a JSON implementation for Ruby. A format string injection issue exists when the `allow duplicate key: false` parsing option is used to parse user-supplied documents. This can lead to denial of service attacks or information disclosure. The `allow duplicate key: false` option is not enabled by default, so users who have not specifically enabled it are not affected. **Recommendations** Ruby JSON versions 2.14.0 through 2.15.2: Update to version 2.15.2.1 or later. Ruby JSON versions 2.17.1 through 2.17.1.2: Update to version 2.17.1.2 or later. Ruby JSON versions 2.19.0 through 2.19.2: Update to version 2.19.2 or later. Avoid using the `allow duplicate key: false` parsing option.

**Name of the Vulnerable Software and Affected Versions** Cosign versions prior to 2.2.4 **Description** Cosign provides code signing and transparency for containers and binaries. Maliciously-crafted software artifacts can cause denial of service of the machine running Cosign, thereby impacting all services on the machine. The root cause is that Cosign creates slices based on the number of signatures, manifests or attestations in untrusted artifacts. As such, the untrusted artifact can control the amount of memory that Cosign allocates. The exact issue is Cosign allocates excessive memory on the lines that creates a slice of the same length as the manifests. **Recommendations** Update to version 2.2.4 or later, where the number of attestations, signatures, and manifests has been limited to a reasonable value. As a temporary workaround, consider restricting the use of untrusted artifacts to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Crossplane versions prior to 1.11.5 Crossplane versions prior to 1.12.3 Crossplane versions prior to 1.13.0 **Description** A high-privileged user could create a Package referencing an arbitrarily large image, which Crossplane would then parse, possibly resulting in exhausting all the available memory and therefore in the container being OOMKilled. The impact is limited due to the high privileges required to create the Package and the eventually consistency nature of the controller. **Recommendations** For versions prior to 1.11.5, update to version 1.11.5 or later. For versions prior to 1.12.3, update to version 1.12.3 or later. For versions prior to 1.13.0, update to version 1.13.0 or later. As a temporary workaround, consider using images from trusted sources and keeping Package editing/creating privileges to administrators only.

**Name of the Vulnerable Software and Affected Versions** Crossplane versions prior to 1.11.5 Crossplane versions prior to 1.12.3 Crossplane versions prior to 1.13.0 **Description** Crossplane's image backend does not validate the byte contents of Crossplane packages, allowing an attacker to tamper with a package without detection. The issue has been fixed in versions 1.11.5, 1.12.3, and 1.13.0. As a workaround, users should only use images from trusted sources and keep package editing/creating privileges restricted to administrators. **Recommendations** For versions prior to 1.11.5, update to version 1.11.5 or later. For versions prior to 1.12.3, update to version 1.12.3 or later. For versions prior to 1.13.0, update to version 1.13.0 or later. As a temporary workaround, consider only using images from trusted sources and restricting package editing/creating privileges to administrators only.

**Name of the Vulnerable Software and Affected Versions** Rekor versions prior to 1.1.1 **Description** Rekor is an open source software supply chain transparency log that may crash due to out of memory (OOM) conditions caused by reading archive metadata files into memory without checking their sizes first. Verification of a JAR file submitted to Rekor can cause an out of memory crash if files within the META-INF directory of the JAR are sufficiently large. Parsing of an APK file submitted to Rekor can cause an out of memory crash if the .SIGN or .PKGINFO files within the APK are sufficiently large. **Recommendations** Update to Rekor version 1.1.1 to resolve the issue. As a temporary workaround, consider restricting the size of files within the META-INF directory of JAR files and the .SIGN and .PKGINFO files within APK files to prevent out of memory crashes. Avoid submitting JAR or APK files with large files in the META-INF directory or .SIGN and .PKGINFO files to Rekor until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** crossplane-runtime versions prior to 1.11.2 crossplane-runtime versions prior to 1.10.3 crossplane-runtime versions prior to 1.9.2 **Description** The issue affects crossplane-runtime, a set of Go libraries used to build Kubernetes controllers in Crossplane and its related stacks. An already highly privileged user able to create or update Compositions can specify an arbitrarily high index in a patch's `ToFieldPath`, which could lead to excessive memory usage once such Composition is selected for a Composite resource. Compositions allow users to specify patches inserting elements into arrays at an arbitrary index. When a Composition is selected for a Composite Resource, patches are evaluated and if a specified index is greater than the current size of the target slice, Crossplane will grow that slice up to the specified index, which could lead to an excessive amount of memory usage and therefore the Pod being OOM-Killed. **Recommendations** To resolve the issue for versions prior to 1.11.2, upgrade to version 1.11.2 or later. To resolve the issue for versions prior to 1.10.3, upgrade to version 1.10.3 or later. To resolve the issue for versions prior to 1.9.2, upgrade to version 1.9.2 or later. As a temporary workaround, restrict write privileges on Compositions to only admin users.

**Name of the Vulnerable Software and Affected Versions** Helm versions prior to 3.10.3 **Description** The issue concerns a NULL Pointer Dereference in the ` repo ` package of Helm, which can lead to a Denial of Service. The ` repo ` package processes the index file of a repository and loads it into structures that Go can work with. Certain index files can cause array data structures to be created, resulting in a memory violation. When such an index file is encountered, the Helm Client will panic, but since Helm is not a long-running service, this panic will not affect future uses of the Helm client. Applications using the ` repo ` package in the Helm SDK to parse an index file can suffer from this issue when the input causes a panic that cannot be recovered from. **Recommendations** For versions prior to 3.10.3, update to version 3.10.3 to resolve the issue. As a temporary workaround, SDK users can validate index files that are correctly formatted before passing them to the ` repo ` functions.