This vulnerability occurs when a WebSocket endpoint does not enforce
proper authentication mechanisms, allowing unauthorized users to
establish connections. As a result, attackers can exploit this weakness
to gain unauthorized access to sensitive data or perform unauthorized
actions. Given that no authentication is required, this can lead to
privilege escalation and potentially compromise the security of the
entire system.
Rekor is a software supply chain transparency log. In versions 1.4.3 and below, attackers can trigger SSRF to arbitrary internal services because /api/v1/index/retrieve supports retrieving a public key via user-provided URL. 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. The issue has been fixed in version 1.5.0. To workaround this issue, disable the search endpoint with --enable_retrieve_api=false.
Incus is a system container and virtual machine manager. In versions 6.20.0 and below, 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 newline injection. This can allow adding arbitrary lifecycle hooks, ultimately resulting in arbitrary command execution on the host. Exploiting this issue on IncusOS requires a slight modification of the payload to change to a different writable directory for the validation step (e.g /tmp). This can be confirmed with a second container with /tmp mounted from the host (A privileged action for validation only). A fix is planned for versions 6.0.6
and 6.21.0, but they have not been released at the time of publication.
Incus is a system container and virtual machine manager. Versions 6.21.0 and below allow a user with the ability to launch a container with a custom image (e.g a member of the ‘incus’ group) to use directory traversal or symbolic links in the templating functionality to achieve host arbitrary file read, and host arbitrary file write. This ultimately results in arbitrary command execution on the host. 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. This can also be exploited in IncusOS. A fix is planned for versions 6.0.6 and 6.21.0, but they have not been released at the time of publication.
Gitea does not properly validate ownership when toggling OpenID URI visibility. An authenticated user may be able to change the visibility settings of other users' OpenID identities.
Gitea does not properly validate repository ownership when linking attachments to releases. An attachment uploaded to a private repository could potentially be linked to a release in a different public repository, making it accessible to unauthorized users.
Rekor is a software supply chain transparency log. In versions 1.4.3 and below, the entry implementation can panic on attacker-controlled input when canonicalizing a proposed entry with an empty spec.message, causing nil Pointer Dereference. Function validate() returns nil (success) when message is empty, leaving sign1Msg uninitialized, and Canonicalize() later dereferences v.sign1Msg.Payload. 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. This issue has been fixed in version 1.5.0.
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 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.
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.