Latest News

## Summary The legacy TUF client `pkg/tuf/client.go`, which supports caching target files to disk, constructs a filesystem path by joining a cache base directory with a target name sourced from signed target metadata, but it does not validate that the resulting path stays within the cache base directory. Note that this should only affect clients that are directly using the TUF client in sigstore/sigstore or are using an older version of Cosign. As this TUF client implementation is deprecated, users should migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf as soon as possible. Note that this does not affect users of the public Sigstore deployment, where TUF metadata is validated by a quorum of trusted collaborators. ## Impact A malicious TUF repository can trigger arbitrary file overwriting, limited to the permissions that the calling process has. ## Workarounds Users can disable disk caching for the legacy client by setting `SIGSTORE_NO_CACHE=true` in the envi...

### Summary A user with the ability to launch a container with a custom image (e.g a member of the ‘incus’ group) can use directory traversal or symbolic links in the templating functionality to achieve host arbitrary file read, and host arbitrary file write, ultimately resulting in arbitrary command execution on the host. This can also be exploited in IncusOS. ### Details When using an image with a `metadata.yaml` containing templates, both the source and target paths are not checked for symbolic links or directory traversal. [1] [2] For example, the following `metadata.yaml` snippet can read an arbitrary file from the host root filesystem as root, and place it inside the container: ``` templates: /shadow: when: - start template: ../../../../../../../../etc/shadow ``` Additionally, the path of the target of the template is not checked or opened safely, and can therefore contain symbolic links pointing outside the container root filesystem. For example: ``` template...

### Summary A user with the ability to launch a container with a custom YAML configuration (e.g a member of the ‘incus’ group) can create an environment variable containing newlines, which can be used to add additional configuration items in the container’s `lxc.conf` due to the newline injection. This can allow adding arbitrary lifecycle hooks, ultimately resulting in arbitrary command execution on the host. ### Details When passing environment variables in the config block of a new container, values are not checked for the presence of newlines [1], which can result in newline injection inside the generated container `lxc.conf`. This can be used to set arbitrary additional configuration items, such as `lxc.hook.pre-start`. By exploiting this, a user with the ability to launch a container with an arbitrary config can achieve arbitrary command execution as root on the host. Exploiting this issue on IncusOS requires a slight modification of the payload to change to a different writable...

Is your child’s data safe? Google settles for $8.25M over claims it tracked kids under 13 without parental…

In this week's newsletter, Bill hammers home the old adage, "Know your environment" — even throughout alert fatigue.

## Summary `/api/v1/index/retrieve` supports retrieving a public key via a user-provided URL, allowing attackers to trigger SSRF to arbitrary internal services. Since the SSRF only can trigger GET requests, the request cannot mutate state. The response from the GET request is not returned to the caller so data exfiltration is not possible. A malicious actor could attempt to probe an internal network through [Blind SSRF](https://portswigger.net/web-security/ssrf/blind). ## Impact * SSRF to cloud metadata (169.254.169.254) * SSRF to internal Kubernetes APIs * SSRF to any service accessible from Fulcio's network ## Patches Upgrade to v1.5.0. Note that this is a breaking change to the search API and fully disables lookups by URL. If you require this feature, please reach out and we can discuss alternatives. ## Workarounds Disable the search endpoint with `--enable_retrieve_api=false`.

## Summary Rekor’s cose v0.0.1 entry implementation can panic on attacker-controlled input when canonicalizing a proposed entry with an empty `spec.message`. `validate()` returns nil (success) when `message` is empty, leaving `sign1Msg` uninitialized, and `Canonicalize()` later dereferences `v.sign1Msg.Payload`. ## Impact A malformed proposed entry of the `cose/v0.0.1` type can cause a panic on a thread within the Rekor process. The thread is recovered so the client receives a 500 error message and service still continues, so the availability impact of this is minimal. ## Patches Upgrade to v1.5.0 ## Workarounds None

Invalid memory access in Sentencepiece versions less than 0.2.1 when using a vulnerable model file, which is not created in the normal training procedure.

The orjson.dumps function in orjson thru 3.11.4 does not limit recursion for deeply nested JSON documents.

I am reporting a code injection vulnerability in Orval’s mock generation pipeline affecting @orval/mock in both the 7.x and 8.x series. This issue is related in impact to the previously reported enum x-enumDescriptions (https://github.com/advisories/GHSA-h526-wf6g-67jv), but it affects a different code path in the faker-based mock generator rather than @orval/core. The vulnerability allows untrusted OpenAPI specifications to inject arbitrary TypeScript/JavaScript into generated mock files via the const keyword on schema properties. These const values are interpolated into the mock scalar generator (getMockScalar in packages/mock/src/faker/getters/scalar.ts) without proper escaping or type-safe serialization, which results in attacker-controlled code being emitted into both interface definitions and faker/MSW handlers. I have confirmed that this occurs on orval@7.19.0 and orval@8.0.2 with mock: true, and that the generated mocks contain executable payloads such as require('child_proces...