1Seal

**Name of the Vulnerable Software and Affected Versions** nimiq-blockchain versions prior to 1.4.0 **Description** In the network-libp2p discovery component, the system accepts signed PeerContact updates from untrusted peers and stores them in a peer contact book. Because there is no validation to ensure the addresses list is not empty, an attacker can insert a signed peer contact with an empty addresses list. When the `known peers()` function in `PeerContactBook` attempts to build an address book, it calls `addresses.first().expect()`, which triggers a panic if the list is empty. Consequently, any call to the 'get address book' endpoint via RPC or web client can cause the node or RPC task to crash. **Recommendations** Update to version 1.4.0.

**Name of the Vulnerable Software and Affected Versions** apko versions prior to 1.2.7 **Description** The `DiscoverKeys()` function in `pkg/apk/apk/implementation.go` performs an unconditional type-assertion of JWKS (JSON Web Key Set) keys as `*rsa.PublicKey` without verifying the key type. If a repository JWKS endpoint returns a non-RSA key, such as an Elliptic Curve (EC) key, the unchecked assertion causes a panic and crashes the application. This affects any workflow that initializes the APK database and fetches repository keys. **Recommendations** Update to version 1.2.7.

**Name of the Vulnerable Software and Affected Versions** apko versions 0.14.8 through 1.2.4 **Description** A crafted .apk file can install a `TypeSymlink` tar entry with a target pointing outside the build root. Subsequent directory-creation or file-write entries in the same or later archive can traverse this symlink to access host paths that the build user has permission to write to. The issue stems from the `sanitizePath` helper in `pkg/apk/fs/rwosfs.go`, which only rejected lexical `..` traversal and failed to resolve or refuse symlinks. This affects disk-backed `DirFS` methods that pass caller-supplied paths to symlink-following standard library calls, including `ReadFile()`, `WriteFile()`, `Chmod()`, `Chown()`, `Chtimes()`, `MkdirAll()`, `Mkdir()`, and `Mknod()`. The primary reachable primitive during tar extraction is the `MkdirAll()` / `Mkdir()` / `WriteFile()` chain via `apko build-cpio` and disk-backed consumers like `melange`. **Recommendations** Update to version 1.2.5.

**Name of the Vulnerable Software and Affected Versions** apko (affected versions not specified) **Description** apko verifies the signature on 'APKINDEX.tar.gz' but fails to compare individually downloaded '.apk' packages against the checksum recorded in the signed index. Although the checksum is parsed via `ChecksumString()` and the downloaded package control hash is computed, these values are not compared within the `getPackageImpl()` function. This allows mismatched packages to be silently accepted. An attacker capable of substituting download responses, such as through a compromised mirror, HTTP repository, or poisoned CDN cache, could install arbitrary packages into built images. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** gnutls versions prior to 3.8.13-1.1 **Description** No detailed information was provided regarding the nature of the security issues fixed in this package. **Recommendations** Update to version 3.8.13-1.1.

**Name of the Vulnerable Software and Affected Versions** tough versions prior to 0.22.0 **Description** Remote authenticated users with delegated signing authority can bypass TUF specification integrity checks for delegated targets metadata and poison the local metadata cache. This occurs because the `load delegations()` function does not apply the same validation checks regarding expiration, hash, and length enforcement as the top-level targets metadata path. **Recommendations** Upgrade to version 0.22.0.

**Name of the Vulnerable Software and Affected Versions** awslabs/tough versions prior to 0.22.0 **Description** Improper verification of cryptographic signature uniqueness in delegated role validation allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature. This can cause the client to accept forged delegated role metadata. **Recommendations** Upgrade to tough-v0.22.0 / tuftool-v0.15.0.

**Name of the Vulnerable Software and Affected Versions** awslabs/tough versions prior to 0.22.0 **Description** Incomplete path traversal fixes allow remote authenticated users with delegated signing authority to write files outside intended output directories. This occurs because write paths trust the joined destination path without post-resolution containment verification. The issue can be triggered via absolute target names in 'copy target/link target', symlinked parent directories in 'save target', or symlinked metadata filenames in the `SignedRole::write` function. **Recommendations** Upgrade to version 0.22.0.

**Name of the Vulnerable Software and Affected Versions** melange versions 0.32.0 through 0.43.3 **Description** When using the opt-in flag '--persist-lint-results' via 'melange lint' or 'melange build', the software constructs output file paths by joining the '--out-dir' parameter with `arch` and `pkgname` values read from the .PKGINFO control file of the APK. Because these values are not validated for path separators or '..' sequences, an attacker providing a malicious APK to a lint or build pipeline could cause the system to write a JSON lint report to an arbitrary .json path reachable by the process. This can lead to the overwriting of other JSON artifacts on the filesystem. This issue only affects deployments where the '--persist-lint-results' flag is explicitly enabled. **Recommendations** Update to version 0.43.4. As a temporary workaround, do not pass the '--persist-lint-results' flag when linting or building APKs with untrusted .PKGINFO contents. Run the software as a low-privileged user and confine writes to an isolated directory to limit impact.

**Name of the Vulnerable Software and Affected Versions** melange versions 0.32.0 through 0.43.3 **Description** An attacker capable of influencing a configuration file, such as in build-as-a-service or pull-request-driven CI scenarios, can manipulate the `pipeline[].uses` variable to include absolute paths or `../` sequences. The `compilePipeline()` function in `pkg/build/compile.go` fails to validate this variable before passing it to `filepath.Join()`, allowing the process to read arbitrary YAML-parseable files outside the designated pipeline directory. Since the loaded file is interpreted as a pipeline and its `runs:` block is executed via `/bin/sh -c` within the build sandbox, this enables the execution of unauthorized shell commands from out-of-tree files, bypassing standard review boundaries. **Recommendations** Update to version 0.43.4. Only run `melange build` against configuration files from trusted sources. In CI systems processing user-supplied configurations, implement manual review of `pipeline[].uses` values and reject any containing `..` or leading `/`.

**Name of the Vulnerable Software and Affected Versions** OpenTelemetry dotnet versions 1.13.1 through 1.15.1 **Description** When exporting telemetry to a back-end or collector over gRPC or HTTP using the OpenTelemetry Protocol (OTLP) format, unsuccessful requests (HTTP 4xx or 5xx) result in the response being read into memory without an upper bound on the number of bytes consumed. This can lead to memory exhaustion and a denial-of-service condition in the consuming application if the configured back-end or collector endpoint is attacker-controlled or if a network attacker performs a Man-in-the-Middle (MitM) attack to return an extremely large response body. **Recommendations** Update to version 1.15.2.

**Name of the Vulnerable Software and Affected Versions** Tekton Pipelines versions 0.43.0 through 1.11.0 **Description** Trusted resources verification policies match a resource source string `refSource.URI` against `spec.resources[].pattern` using the `regexp.MatchString` function. Because this function reports a match if the pattern is found anywhere in the string, unanchored patterns can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. This may lead to an unintended policy match and alter the applicable verification modes or keys. **Recommendations** Update Tekton Pipelines to a version later than 1.11.0.

**Name of the Vulnerable Software and Affected Versions** Istio versions prior to 1.28.6 Istio versions prior to 1.29.2 **Description** When a RequestAuthentication resource is created with a `jwksUri` pointing to an internal service, istiod performs an unauthenticated HTTP GET request to that URL without filtering localhost or link-local IP addresses. This behavior can lead to the distribution of sensitive data to Envoy proxies through the xDS configuration. **Recommendations** Update to version 1.28.6. Update to version 1.29.2. Deploy a `ValidatingAdmissionPolicy` to prevent the creation of RequestAuthentication resources containing suspicious `jwksUri` field values, such as localhost, 127.0.0.0/8, 169.254.0.0/16, and their IPv6 equivalents.

**Name of the Vulnerable Software and Affected Versions** Kyverno versions prior to 1.16.4 **Description** The apiCall servicecall helper implicitly injects an 'Authorization: Bearer ...' header using the kyverno controller serviceaccount token when a policy does not explicitly set an Authorization header. Since the variable `context.apiCall.service.url` is policy-controlled, this can lead to a confused deputy scenario where the serviceaccount token is sent to an attacker-controlled endpoint. This issue is scoped to ClusterPolicy and global context usage, as namespaced policies are blocked from servicecall usage by the `urlPath` gate in the `pkg/engine/apicall/apiCall.go` file. An attacker with the ability to create or update a ClusterPolicy or create a GlobalContextEntry can choose the request URL and headers to exfiltrate the token. **Recommendations** Update to version 1.16.4. Set an explicit Authorization header in servicecall policies to prevent implicit token injection. Avoid using servicecall to arbitrary urls in policies.

**Name of the Vulnerable Software and Affected Versions** nimiq/core-rs-albatross versions prior to 1.3.0 **Description** An untrusted peer can cause a validator to crash. This occurs when a signed tendermint proposal message is published where the `signer` is equal to `validators.num validators()`. The `ProposalSender::send()` function uses a greater-than operator instead of a greater-than-or-equal-to operator for the signer bounds check. This allows the equality case to proceed to the `validators.get validator by slot band(signer)` function, which triggers a panic due to an out-of-bounds index before signature verification occurs. **Recommendations** Update to version 1.3.0.

**Name of the Vulnerable Software and Affected Versions** nimiq/core-rs-albatross versions prior to 1.3.0 **Description** An unauthenticated p2p peer can cause the `RequestMacroChain` message handler task to panic. This occurs when a `RequestMacroChain` message is sent where the first locator hash on the victim's main chain is a micro block hash instead of a macro block hash. The `RequestMacroChain::handle` handler selects the locator based only on whether it is on the main chain, then calls `get macro blocks()` and panics via `.unwrap()` when the selected hash is not a macro block (`BlockchainError::BlockIsNotMacro`). **Recommendations** Update to version 1.3.0.

**Name of the Vulnerable Software and Affected Versions** Step CA versions 0.24.0 through 0.30.0-rc3 **Description** An attacker can trigger an index out-of-bounds panic in Step CA by sending a crafted attestation key (AK) certificate with an empty Extended Key Usage (EKU) extension during TPM device attestation. During TPM device attestation, Step CA validates that the AK certificate contains the tcg-kp-AIKCertificate Extended Key Usage OID. A crafted certificate could include an EKU extension that decodes to an empty sequence, causing the code to panic when accessing the first element of the empty slice. This vulnerability is only reachable when a device-attest-01 ACME challenge with TPM attestation is configured. **Recommendations** Upgrade to version 0.30.0-rc3 or newer. If unable to upgrade, disable or remove any ACME provisioners that use TPM device attestation (device-attest-01).

**Name of the Vulnerable Software and Affected Versions** versions prior to 2.3 **Description** When verifying a certificate chain with excluded DNS constraints, these constraints are not correctly applied to wildcard DNS Subject Alternative Names (SANs) that differ in case. This impacts the validation of trusted certificate chains issued by a root Certificate Authority (CA) in the system or specified root certificate pool. **Recommendations** Update to a version prior to 2.3.

Name of the Vulnerable Software and Affected Versions OpenTelemetry-Go versions 1.36.0 through 1.40.0 Description The OpenTelemetry-Go implementation is susceptible to a remote request amplification issue due to the way it handles multi-value baggage headers. Specifically, the `extractMultiBaggage` function in `propagation/baggage.go` parses each `baggage` header field-value independently and aggregates the results. An attacker can exploit this by sending numerous `baggage` header lines, even if each individual value is within the 8192-byte limit, leading to increased CPU usage and memory allocations. This can result in higher latency and potential denial-of-service conditions. The vulnerability is related to the parsing of headers received in HTTP requests. The vulnerable function is `extractMultiBaggage`. Recommendations Update to version 1.41.0 or later.

Name of the Vulnerable Software and Affected Versions distribution versions 3.0.x and earlier, versions 2.8.x and earlier when redis blob descriptor cache and delete are both enabled Description distribution, a toolkit for managing container content, is susceptible to a confidentiality issue. When `storage.cache.blobdescriptor: redis` and `storage.delete.enabled: true` are both enabled, a deleted blob can become readable again in `repo a` after an explicit delete due to stale repo-scoped membership in the redis cache. The delete process clears the shared digest descriptor but fails to remove the repository-specific membership, allowing a subsequent `Stat` or `Get` request from `repo b` to repopulate the descriptor and restore access in `repo a`. This creates a revocation gap at the repository boundary, potentially exposing previously deleted content. The issue involves the interaction between `linkedBlobStore.Delete`, `blobAccessController.Clear`, `cachedBlobStatter.Clear`, and `repositoryScopedRedisBlobDescriptorService.Clear` functions. The vulnerability allows an attacker to regain access to content in `repo a` after it has been explicitly deleted, by leveraging the shared descriptor repopulation from `repo b`. Recommendations For versions 3.0.x and earlier, and versions 2.8.x and earlier when redis blob descriptor cache and delete are both enabled, ensure that the redis invalidation process revokes repo-scoped state along with the backend link deletion. This includes removing the digest from the repository membership set and deleting the repo-scoped descriptor hash to prevent peer-repository warming from restoring access in the repository that initiated the deletion.