#git

### Summary The `ArchiveReader.extractContents()` function used by `cctl image load` and container image load performs no pathname validation before extracting an archive member. This means that a carelessly or maliciously constructed archive can extract a file into any user-writable location on the system using relative pathnames. ### Details The code in question is: https://github.com/apple/containerization/blob/main/Sources/ContainerizationArchive/Reader.swift#L180. ```swift /// Extracts the contents of an archive to the provided directory. /// Currently only handles regular files and directories present in the archive. public func extractContents(to directory: URL) throws { let fm = FileManager.default var foundEntry = false for (entry, data) in self { guard let p = entry.path else { continue } foundEntry = true let type = entry.fileType let target = directory.appending(path: p) switc...

**Summary** An authenticated, low-privilege user (able to create/edit forms) can inject arbitrary HTML/JS into the Craft Control Panel (CP) builder and integrations views. User-controlled form labels and integration metadata are rendered with `dangerouslySetInnerHTML` without sanitization, leading to stored XSS that executes when any admin views the builder/integration screens. **Affected Product** - Ecosystem: Packagist (Craft CMS plugin) - Package: solspace/craft-freeform - Version: <= 5.14.6 (latest observed). Likely all 5.x until patched. **Details** - Root cause: Multiple user-controlled strings (field labels, section labels, integration icons, short names, WYSIWYG previews) are injected into React components using `dangerouslySetInnerHTML` without sanitization. - Evidence: `dangerouslySetInnerHTML` on user-controlled properties in bundled CP JS at [packages/plugin/src/Resources/js/client/client.js](packages/plugin/src/Resources/js/client/client.js#L1). **PoCs** - Label-based X...

The fix applied in CVE-2025-22228 inadvertently broke the timing attack mitigation implemented in DaoAuthenticationProvider. This can allow attackers to infer valid usernames or other authentication behavior via response-time differences under certain configurations.

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

## 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

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

Unprivileged users (for example, those with the database editor role) can create or modify fields in records that contain functions or `futures`. `Futures` are values which are only computed when the value is queried. The query executes in the context of the querying user, rather than the user who originally defined the future. Likewise, fields containing functions or custom-defined logic (`closures`) are executed under the privileges of the invoking user, not the creator. This results in a confused deputy vulnerability: an attacker with limited privileges can define a malicious function or future field that performs privileged actions. When a higher-privileged user (such as a root owner or namespace administrator) executes the function or queries or modifies that record, the function executes with their elevated permissions. ### Impact An attacker who can create or update function/future fields can plant logic that executes with a privileged user’s context. If a privileged user per...