1Seal

A signature verification bypass exists in the `verifyImages()` function. The issue occurs because cached verification results are keyed by the image reference string, such as a tag, instead of being bound to the verified digest. Consequently, cache hits allow the system to skip signature and attestation checks. An attacker capable of submitting workloads and modifying a registry tag can populate the cache with a signed image, change the tag to point to a different image, and trick the system into admitting the workload while using `mutateDigest` to pin the unverified digest.

An unbounded decompression issue exists in the `extractStatement()` function. Remote attackers can cause a denial of service by supplying highly compressed attestation layers via registry referrer artifacts. When these gzip predicate layers are decompressed, they can exceed the `maxPayloadSize`, leading to Out-of-Memory (OOM) kills of the admission controller.

An unbounded decompression issue exists in the `FetchSignatureBlob()` function. Attackers who control registry referrers or signatures can provide highly compressed notary signature layers. These small gzip layers can decompress beyond the `maxPayloadSize` variable, leading to memory exhaustion, Out-of-Memory (OOM) kills of the admission controller, and a resulting denial of service.

An unbounded memory allocation issue exists where attackers can exhaust JVM memory by declaring a large uncompressed length in compressed input. By providing crafted bytes to the `uncompress()`, `uncompressString()`, `SnappyInputStream`, or `SnappyFramedInputStream` functions, an attacker can force allocations up to 2 GB, leading to an OutOfMemoryError and a denial of service.

A Name Constraints bypass exists when a trailing dot is used in `rfc822Name` and URI. Name Constraints are a mechanism used in certificates to restrict the scope of names for which a Certificate Authority is trusted to issue certificates.

During the monolithic blob upload flow, the software follows a registry-controlled `Location` header and reuses the `Authorization` header from the initial `POST` request for the subsequent `PUT` request. If a malicious registry returns a cross-host `Location`, the caller's credentials can be sent to an attacker-controlled endpoint. This issue occurs within the `blobStore.completePushAfterInitialPost()` function located in `registry/remote/repository.go`. This can lead to a credential leak and client-side Server-Side Request Forgery (SSRF), where the server is tricked into making requests to an unintended destination.

An issue exists in the UDP DNS filter when configured with local or remote resolution for names exactly 255 octets long. A query with such a name causes abnormal process termination due to an invalid runtime precondition requiring the query name to be strictly less than 255 octets, which contradicts the DNS specification rfc1035#section-2.3.4 allowing names up to 255 octets.

A remote, unauthenticated BLE peer can trigger a 2-byte out-of-bounds write in the Bluetooth host during L2CAP LE CoC SDU reassembly. This occurs when the application enables segmentation via `chan ops.alloc buf` and the selected RX pool has a `user data size` smaller than 2 bytes. In this scenario, the segmentation counter stored in the `net buf` user data area is written out of bounds within the `l2cap chan le recv seg()` function. This can lead to heap corruption or fatal errors.

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.

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.

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`.

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.

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.

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.

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.

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.

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.

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.

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.

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.