VulnerableCode Package Details - pkg:rpm/redhat/openshift-pipelines-client@1.15.0-11496?arch=el8

Vulnerabilities affecting this package (5)

Vulnerability	Summary	Fixed by
VCID-aj2b-56uj-gkar Aliases: CVE-2023-45288 GHSA-4v7x-pqxf-cx7m	net/http, x/net/http2: close connections when receiving too many headers An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.	There are no reported fixed by versions.
VCID-bq1t-9nnj-mkes Aliases: CVE-2024-28180 GHSA-c5q2-7r4c-mv6g	Go JOSE vulnerable to Improper Handling of Highly Compressed Data (Data Amplification) ### Impact An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting. ### Patches The problem is fixed in the following packages and versions: - github.com/go-jose/go-jose/v4 version 4.0.1 - github.com/go-jose/go-jose/v3 version 3.0.3 - gopkg.in/go-jose/go-jose.v2 version 2.6.3 The problem will not be fixed in the following package because the package is archived: - gopkg.in/square/go-jose.v2	There are no reported fixed by versions.
VCID-jwrn-5t32-3fbq Aliases: CVE-2024-29903 GHSA-95pr-fxf5-86gv	Cosign malicious artifacts can cause machine-wide DoS 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. As an example, these lines demonstrate the problem: https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L70 This `Get()` method gets the manifest of the image, allocates a slice equal to the length of the layers in the manifest, loops through the layers and adds a new signature to the slice. The exact issue is Cosign allocates excessive memory on the lines that creates a slice of the same length as the manifests. ## Remediation Update to the latest version of Cosign, where the number of attestations, signatures and manifests has been limited to a reasonable value. ## Cosign PoC In the case of this API (also referenced above): https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L70 … The first line can contain a length that is safe for the system and will not throw a runtime panic or be blocked by other safety mechanisms. For the sake of argument, let’s say that the length of `m, err := s.Manifest()` is the max allowed (by the machine without throwing OOM panics) manifests minus 1. When Cosign then allocates a new slice on this line: `signatures := make([]oci.Signature, 0, len(m.Layers))`, Cosign will allocate more memory than is available and the machine will be denied of service, causing Cosign and all other services on the machine to be unavailable. To illustrate the issue here, we run a modified version of `TestSignedImageIndex()` in `pkg/oci/remote`: https://github.com/sigstore/cosign/blob/14795db16417579fac0c00c11e166868d7976b61/pkg/oci/remote/index_test.go#L31-L57 Here, `wantLayers` is the number of manifests from these lines: https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L60 To test this, we want to make `wantLayers` high enough to not cause a memory on its own but still trigger the machine-wide OOM when a slice gets create with the same length. On my local machine, it would take hours to create a slice of layers that fulfils that criteria, so instead I modify the Cosign production code to reflect a long list of manifests: ```golang // Get implements oci.Signatures func (s *sigs) Get() ([]oci.Signature, error) { m, err := s.Manifest() if err != nil { return nil, err } // Here we imitate a long list of manifests ms := make([]byte, 2600000000) // imitate a long list of manifests signatures := make([]oci.Signature, 0, len(ms)) panic("Done") //signatures := make([]oci.Signature, 0, len(m.Layers)) for _, desc := range m.Layers { ``` With this modified code, if we can cause an OOM without triggering the `panic("Done")`, we have succeeded.	There are no reported fixed by versions.
VCID-q1ze-sun1-xkah Aliases: CVE-2024-29902 GHSA-88jx-383q-w4qc	Cosign malicious attachments can cause system-wide denial of service ### Summary A remote image with a malicious attachment can cause denial of service of the host machine running Cosign. This can impact other services on the machine that rely on having memory available such as a Redis database which can result in data loss. It can also impact the availability of other services on the machine that will not be available for the duration of the machine denial. ### Details The root cause of this issue is that Cosign reads the attachment from a remote image entirely into memory without checking the size of the attachment first. As such, a large attachment can make Cosign read a large attachment into memory; If the attachments size is larger than the machine has memory available, the machine will be denied of service. The Go runtime will make a `SIGKILL` after a few seconds of system-wide denial. The root cause is that Cosign reads the contents of the attachments entirely into memory on line 238 below: https://github.com/sigstore/cosign/blob/9bc3ee309bf35d2f6e17f5d23f231a3d8bf580bc/pkg/oci/remote/remote.go#L228-L239 ...and prior to that, neither Cosign nor go-containerregistry checks the size of the attachment and enforces a max cap. In the case of a remote layer of `f attached`, go-containerregistry will invoke this API: https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/pkg/v1/remote/layer.go#L36-L40 ```golang func (rl remoteLayer) Compressed() (io.ReadCloser, error) { // We don't want to log binary layers -- this can break terminals. ctx := redact.NewContext(rl.ctx, "omitting binary blobs from logs") return rl.fetcher.fetchBlob(ctx, verify.SizeUnknown, rl.digest) } ``` Notice that the second argument to `rl.fetcher.fetchBlob` is `verify.SizeUnknown` which results in not using the `io.LimitReader` in `verify.ReadCloser`: https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/internal/verify/verify.go#L82-L100 ```golang func ReadCloser(r io.ReadCloser, size int64, h v1.Hash) (io.ReadCloser, error) { w, err := v1.Hasher(h.Algorithm) if err != nil { return nil, err } r2 := io.TeeReader(r, w) // pass all writes to the hasher. if size != SizeUnknown { r2 = io.LimitReader(r2, size) // if we know the size, limit to that size. } return &and.ReadCloser{ Reader: &verifyReader{ inner: r2, hasher: w, expected: h, wantSize: size, }, CloseFunc: r.Close, }, nil } ``` ### Impact This issue can allow a supply-chain escalation from a compromised registry to the Cosign user: If an attacher has compromised a registry or the account of an image vendor, they can include a malicious attachment and hurt the image consumer. ### Remediation Update to the latest version of Cosign, which limits the number of attachments. An environment variable can override this value.	There are no reported fixed by versions.
VCID-sajm-cnn5-jqac Aliases: CVE-2024-28110 GHSA-5pf6-2qwx-pxm2	Go SDK for CloudEvents's use of WithRoundTripper to create a Client leaks credentials ### Impact _What kind of vulnerability is it? Who is impacted?_ Using cloudevents.WithRoundTripper to create a cloudevents.Client with an authenticated http.RoundTripper causes the go-sdk to leak credentials to arbitrary endpoints. The relevant code is [here](https://github.com/cloudevents/sdk-go/blob/67e389964131d55d65cd14b4eb32d57a47312695/v2/protocol/http/protocol.go#L104-L110) (also inline, emphasis added): <pre>if p.Client == nil { p.Client = http.DefaultClient } if p.roundTripper != nil { p.Client.Transport = p.roundTripper } </pre> When the transport is populated with an authenticated transport such as: - [oauth2.Transport](https://pkg.go.dev/golang.org/x/oauth2#Transport) - [idtoken.NewClient(...).Transport](https://pkg.go.dev/google.golang.org/api/idtoken#NewClient) ... then http.DefaultClient is modified with the authenticated transport and will start to send Authorization tokens to any endpoint it is used to contact! Found and patched by: @tcnghia and @mattmoor ### Patches v.2.15.2	There are no reported fixed by versions.

Next non-vulnerable version	None.
Latest non-vulnerable version	None.
Risk	4.0

Date	Actor	Action	Vulnerability	Source	VulnerableCode Version
2026-04-01T13:49:15.526102+00:00	RedHat Importer	Affected by	VCID-sajm-cnn5-jqac	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2024-28110.json	38.0.0
2026-04-01T13:49:12.666270+00:00	RedHat Importer	Affected by	VCID-bq1t-9nnj-mkes	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2024-28180.json	38.0.0
2026-04-01T13:48:30.992011+00:00	RedHat Importer	Affected by	VCID-aj2b-56uj-gkar	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2023-45288.json	38.0.0
2026-04-01T13:48:24.482810+00:00	RedHat Importer	Affected by	VCID-q1ze-sun1-xkah	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2024-29902.json	38.0.0
2026-04-01T13:48:24.454879+00:00	RedHat Importer	Affected by	VCID-jwrn-5t32-3fbq	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2024-29903.json	38.0.0