#vulnerability

Gitea does not properly verify authorization when canceling scheduled auto-merges via the web interface. A user with read access to pull requests may be able to cancel auto-merges scheduled by other users.

Gitea does not properly validate repository ownership when deleting Git LFS locks. A user with write access to one repository may be able to delete LFS locks belonging to other repositories.

Gitea does not properly validate project ownership in organization project operations. A user with project write access in one organization may be able to modify projects belonging to a different organization.

Gitea does not properly verify repository context when deleting attachments. A user who previously uploaded an attachment to a repository may be able to delete it after losing access to that repository by making the request through a different repository they can access.

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

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

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