Multiple constant-time implementations in wolfSSL before version 5.8.4 may be transformed into non-constant-time binary by LLVM optimizations, which can potentially result in observable timing discrepancies and lead to information disclosure through timing side-channel attacks.

Vulnerability in X25519 constant-time cryptographic implementations due to timing side channels introduced by compiler optimizations and CPU architecture limitations, specifically with the Xtensa-based ESP32 chips. If targeting Xtensa it is recommended to use the low memory implementations of X25519, which is now turned on as the default for Xtensa.

A CRL critical extension bypass exists in ParseCRL_Extensions where critical extensions are not properly enforced, allowing a crafted CRL with an unhandled critical extension to be accepted. This only affects builds with CRL support enabled and where a crafted CRL had a trusted signature when parsed.

ImageMagick before 7.1.2-26 and 6.9.13-51 contains a heap-based buffer over-write vulnerability that occurs when running an X11 import with a crafted window title, which can result in heap memory corruption and denial of service.

Weblate is a web based localization tool. In versions prior to 5.15, it was possible to accept an invitation opened by a different user. Version 5.15. contains a patch. As a workaround, avoid leaving one's Weblate sessions with an invitation opened unattended.

uniget is a universal installer and updater for (container) tools. Prior to 0.27.6, the hooks edit command in cmd/uniget/hooks.go parses UNIGET_EDITOR or EDITOR with strings.Split(editor, " ") and passes every space-delimited suffix as an argument to the selected editor executable. An attacker who can influence the editor environment and cause hook editing can supply unexpected editor arguments, potentially causing unintended actions with the privileges of the uniget process account. Go os/exec does not evaluate shell operators in these arguments, so the advisory's wrapper demonstration establishes argument delivery but does not establish shell command interpretation. This issue is fixed in version 0.27.6.

Arduino IDE 2.x is an IDE based on the Theia IDE framework and built with Electron. A Self Cross-Site Scripting (XSS) vulnerability has been identified within the Arduino-IDE prior to version v2.3.5. The vulnerability occurs in the Additional Board Manager URLs field, which can be found in the Preferences -> Settings section of the Arduino IDE interface. In the vulnerable versions, any values entered in this field are directly displayed to the user through a notification tooltip object, without a proper output encoding routine, due to the underlying ElectronJS engine interpretation. This vulnerability exposes the input parameter to Self-XSS attacks, which may lead to security risks depending on where the malicious payload is injected. This vulnerability is fixed in 2.3.5.

Giskard is an open-source testing framework for AI models. In versions prior to 1.0.2b1, the RegexMatching check passes a user-supplied regular expression pattern directly to Python's re.search() without any timeout or complexity guard. A crafted regex pattern can trigger catastrophic backtracking, causing the process to hang indefinitely. Exploitation requires write access to a check definition and subsequent execution of the test suite. This issue has been fixed in giskard-checks version 1.0.2b1.

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hfr4-7c6c-48w2
For more information see the GitHub-hosted security advisory.

Nix is a package manager for Linux and other Unix systems. On macOS, built-in builders (such as `builtin:fetchurl`, exposed to users with `import <nix/fetchurl.nix>`) were not executed in the macOS sandbox. Thus, these builders (which are running under the `nixbld*` users) had read access to world-readable paths and write access to world-writable paths outside of the sandbox. This issue is fixed in 2.18.9, 2.19.7, 2.20.9, 2.21.5, 2.22.4, 2.23.4, and 2.24.10. Note that sandboxing is not enabled by default on macOS. The Nix sandbox is not primarily intended as a security mechanism, but as an aid to improve reproducibility and purity of Nix builds. However, sandboxing *can* mitigate the impact of other security issues by limiting what parts of the host system a build has access to.

OpenSC before 0.27.0-rc1, fixed in commit 3f24f0b, contains a stack buffer overflow vulnerability in piv_process_history() in src/libopensc/card-piv.c that allows physically present attackers to trigger memory corruption by presenting a crafted PIV smart card or USB device returning a URL field longer than 118 bytes in the Key History Object ASN.1 response.

### Impact

It was possible to accept an invitation opened by a different Weblate user.

### Patches

* https://github.com/WeblateOrg/weblate/pull/16913

### Workarounds

Users should avoid leaving Weblate sessions with an unattended opened invitation.

### References

Thanks to Nahid0x for responsibly disclosing this vulnerability to Weblate.

### Impact

In version 43.0.0 of the `wasmtime` crate, cloning a `wasmtime::Linker` is unsound and can result in use-after-free bugs.

This bug is not controllable by guest Wasm programs. It can only be triggered by a specific sequence of embedder API calls made by the host.

The typical symptom of this use-after-free bug is a segfault. It does not enable heap corruption or data leakage.

If you are using the `wasmtime` CLI, rather than the embedding API, you are not affected. If you are using the embedding API but are not calling `wasmtime::Linker`'s `Clone` implementation, you are not affected.

Specifically, the following steps must occur to trigger the bug:

* Clone a `wasmtime::Linker`
* Drop the original linker instance
* Use the new, cloned linker instance, resulting in a use-after-free

### Patches

This bug has been patched in Wasmtime version 43.0.1

### Workarounds

Wasmtime embedders are highly encouraged to upgrade their `wasmtime` crate dependency.

If upgrading is not an option, or as a temporary workaround before upgrading, you can avoid this bug by not cloning `wasmtime::Linker` and instead creating a new, empty `wasmtime::Linker` and manually reregistering the host APIs from the original linker:

```rust
use wasmtime::{Linker, Result, Store};

fn clone_linker<T>(linker: &Linker<T>, store: &mut Store<T>) -> Result<Linker<T>> {
    let mut cloned = Linker::new();
    for (module, name, item) in linker.iter(store) {
        cloned.define(module, name, item)?;
    }
    Ok(cloned)
}
```

### References

This bug was introduced during an internal refactoring that was part of our efforts to [robustly handle allocation failure in Wasmtime](https://github.com/bytecodealliance/wasmtime/issues/12069). This refactoring introduced an string-interning pool which had an unsound `TryClone`[^try-clone] implementation.

[^try-clone]: [The `TryClone` trait](https://github.com/bytecodealliance/wasmtime/blob/33e8b3d955697587b23cf39d87fbcbdb4d26b0c9/crates/core/src/alloc/try_clone.rs#L5-L17) is our version of the Rust standard library's `Clone` trait that allows for returning `OutOfMemory` errors.

* The `StringPool` was introduced in https://github.com/bytecodealliance/wasmtime/pull/12536, at which time the bug in `TryClone for StringPool` was already present, although this code path was not yet used anywhere.
* `wasmtime::Linker` was refactored to internally use `StringPool` in https://github.com/bytecodealliance/wasmtime/pull/12537, at which time the buggy code path became accessible.
* This bug was originally reported to the Wasmtime maintainers as https://github.com/bytecodealliance/wasmtime/pull/12906

zx is a tool for writing better scripts. An attacker with control over environment variable values can inject unintended environment variables into `process.env`. This can lead to arbitrary command execution or unexpected behavior in applications that rely on environment variables for security-sensitive operations. Applications that process untrusted input and pass it through `dotenv.stringify` are particularly vulnerable. This issue has been patched in version 8.3.2. Users should immediately upgrade to this version to mitigate the vulnerability. If upgrading is not feasible, users can mitigate the vulnerability by sanitizing user-controlled environment variable values before passing them to `dotenv.stringify`. Specifically, avoid using `"`, `'`, and backticks in values, or enforce strict validation of environment variables before usage.

Potential use of sensitive information in GET requests in Checkmk GmbH's Checkmk versions <2.4.0p13, <2.3.0p38, <2.2.0p46, and 2.1.0 (EOL) may cause sensitive form data to be included in URL query parameters, which may be logged in various places such as browser history or web server logs.

ImageMagick before 7.1.2-30 contains a time-of-check-time-of-use vulnerability in path policy enforcement on Windows that allows attackers to bypass read or write restrictions by exploiting symlink race conditions. Attackers can swap symlinks between policy validation and file access to read or write policy-denied files.

The PKCS#7 decode path ignores the caller-supplied output buffer size (outputSz), allowing decoded content to be written past the bounds of the provided buffer. This affects wolfSSL 5.9.0 and earlier and was fixed in the 5.9.1 release.

Integer underflow in wc_PKCS7_DecryptOri when handling crafted Other Recipient Info, leading to incorrect length handling during decryption.

Exporting a TPM based RSA key larger than 2048 bits from the TPM could overrun a stack buffer if the default `MAX_RSA_KEY_BITS=2048` is used. If your TPM 2.0 module supports RSA key sizes larger than 2048 bit and your applications supports creating or importing an RSA private or public key larger than 2048 bits and your application calls `wolfTPM2_RsaKey_TpmToWolf` on that key, then a stack buffer could be overrun. If the `MAX_RSA_KEY_BITS` build-time macro is set correctly (RSA bits match what TPM hardware is capable of) for the hardware target, then a stack overrun is not possible.

When Bazel Plugin in intellij imports a project (either using "import project" or "Auto import") the dialog for trusting the project is not displayed. This comes from the fact that both call the method ProjectBuilder.createProject which then calls ProjectManager.getInstance().createProject. This method, as its name suggests is intended to create a new project, not to import an existing one. 
We recommend upgrading to version 2024.06.04.0.2 or beyond for the IntelliJ, CLion and Android Studio Bazel plugins.

conda-forge-webservices is the web app deployed to run conda-forge admin commands and linting. Prior to version 2025.3.24, the conda_forge_webservice Docker container executes commands without specifying a user. By default, Docker containers run as the root user, which increases the risk of privilege escalation and host compromise if a vulnerability is exploited. This issue has been patched in version 2025.3.24.

Wasmtime is a runtime for WebAssembly. In 43.0.0, cloning a wasmtime::Linker is unsound and can result in use-after-free bugs. This bug is not controllable by guest Wasm programs. It can only be triggered by a specific sequence of embedder API calls made by the host. Specifically, the following steps must occur to trigger the bug clone a wasmtime::Linker, drop the original linker instance, use the new, cloned linker instance, resulting in a use-after-free. This vulnerability is fixed in 43.0.1.

OpenSC before 0.27.0, fixed in commit 0358817, contains a stack and heap buffer overrun vulnerability in the do_key_value() function in src/pkcs15init/profile.c that allows attackers to corrupt memory by supplying a crafted profile configuration file. During pkcs15-init invocation, a key value entry beginning with '=' followed by more than sizeof(keybuf) characters is copied into keybuf via memcpy without a length check, causing both stack and heap buffer overruns.

A buffer overread can occur in the CPC application when operating in full duplex SPI upon receiving an invalid packet over the SPI interface.

Wasmtime is a runtime for WebAssembly. Wasmtime 37.0.0 and 37.0.1 have memory leaks in the C/C++ API when using bindings for the `anyref` or `externref` WebAssembly values. This is caused by a regression introduced during the development of 37.0.0 and all prior versions of Wasmtime are unaffected. If `anyref` or `externref` is not used in the C/C++ API then embeddings are also unaffected by the leaky behavior. The `wasmtime` Rust crate is unaffected by this leak.

Development of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted<T>` type to a new `OwnedRooted<T>` type. This change was integrated into Wasmtime's C API but left the C API in a state which had memory leaks. Additionally the new ownership semantics around this type were not reflected into the C++ API, making it leak-prone. A short version of the change is that previously `ManuallyRooted<T>`, as the name implies, required manual calls to an "unroot" operation. If this was forgotten then the memory was still cleaned up when the `wasmtime_store_t` itself was destroyed eventually. Documentation of when to "unroot" was sparse and there were already situations prior to 37.0.0 where memory would be leaked until the store was destroyed anyway. All memory, though, was always bound by the store, and destroying the store would guarantee that there were no memory leaks.

In migrating to `OwnedRooted<T>` the usage of the type in Rust changed. A manual "unroot" operation is no longer required and it happens naturally as a destructor of the `OwnedRooted<T>` type in Rust itself. These new resource ownership semantics were not fully integrated into the preexisting semantics of the C/C++ APIs in Wasmtime. A crucial distinction of `OwnedRooted<T>` vs `ManuallyRooted<T>` is that the `OwnedRooted<T>` type allocates host memory outside of the store. This means that if an `OwnedRooted<T>` is leaked then destroying a store does not release this memory and it's a permanent memory leak on the host.

This led to a few distinct, but related, issues arising: A typo in the `wasmtime_val_unroot` function in the C API meant that it did not actually unroot anything. This meant that even if embedders faithfully call the function then memory will be leaked. If a host-defined function returned a `wasmtime_{externref,anyref}_t` value then the value was never unrooted. The C/C++ API no longer has access to the value and the Rust implementation did not unroot. This meant that any values returned this way were never unrooted. The goal of the C++ API of Wasmtime is to encode automatic memory management in the type system, but the C++ API was not updated when `OwnedRooted<T>` was added. This meant that idiomatic usage of the C++ API would leak memory due to a lack of destructors on values.

These issues have all been fixed in a 37.0.2 release of Wasmtime. The implementation of the C and C++ APIs have been updated accordingly and respectively to account for the changes of ownership here. For example `wasmtime_val_unroot` has been fixed to unroot, the Rust-side implementation of calling an embedder-defined function will unroot return values, and the C++ API now has destructors on the `ExternRef`, `AnyRef`, and `Val` types. These changes have been made to the 37.0.x release branch in a non-API-breaking fashion. Changes to the 38.0.0 release branch (and `main` in the Wasmtime repository) include minor API updates to better accommodate the API semantic changes. The only known workaround at this time is to avoid using `externref` and `anyref` in the C/C++ API of Wasmtime. If avoiding those types is not possible then it's required for users to update to mitigate the leak issue.

A security vulnerability has been detected in proma-ai Proma up to 0.19.37. Affected is the function resolveTargetPath of the file apps/electron/src/main/lib/file-preview-service.ts of the component File Preview Service. Such manipulation of the argument file_path leads to path traversal. Local access is required to approach this attack. The exploit has been disclosed publicly and may be used. Upgrading to version 0.19.52 is able to address this issue. The name of the patch is b7bf78ab74b1552c92fc98c7db9a8a8d92c631df. It is suggested to upgrade the affected component. The PoC's candidateBasePaths parameter name does not match the current IPC API (0.19.52 uses FileAccessOptions with internal getPreviewCandidateBasePaths()). The reporter likely targeted 0.16.3 where the IPC handler accepted raw string[] base paths. The core vulnerability - basename-collision fallback - is independent of the parameter name and is confirmed in source.

A vulnerability has been found in GPAC up to f1219cde. Affected by this issue is the function lsr_exec_command_list of the file laser/lsr_dec.c of the component MP4Box. The manipulation leads to reachable assertion. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. Upgrading to version abi-16.23 can resolve this issue. The identifier of the patch is afca1f1181668d85941d51ed1adf647807d5d975. The affected component should be upgraded.

A vulnerability was determined in GPAC 26.07.0. Affected by this issue is the function gf_node_del of the file scenegraph/base_scenegraph.c of the component MP4Box. This manipulation causes out-of-bounds read. The attack is restricted to local execution. The exploit has been publicly disclosed and may be utilized. Upgrading to version abi-16.23 can resolve this issue. Patch name: afca1f1181668d85941d51ed1adf647807d5d975. It is advisable to upgrade the affected component.

A vulnerability was found in agentverus agentverus-scanner up to 0.8.1. Affected by this vulnerability is the function isSecurityDefenseSkill of the file dist/scanner/analyzers/context.js. Performing a manipulation results in reliance on untrusted inputs in a security decision. The attack must be initiated from a local position. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability was detected in OpenClaw ClawScan up to 0.1.6. The impacted element is the function IsBinaryFile of the file internal/runner/static_scanner.go of the component File Classifier. The manipulation results in interpretation conflict. Attacking locally is a requirement. The exploit is now public and may be used. Upgrading to version 0.1.7 is sufficient to resolve this issue. The patch is identified as 04401337b3adb9343bd338b21e5e258bf49ca9c8. You should upgrade the affected component.

A vulnerability was determined in GPAC up to f1219cde. The affected element is the function gf_node_activate_ex of the file scenegraph/base_scenegraph.c. This manipulation causes stack-based buffer overflow. It is possible to launch the attack on the local host. The exploit has been publicly disclosed and may be utilized. Upgrading to version abi-16.23 is sufficient to fix this issue. Patch name: 9eb40df4448b88d6a6ce3454657c06f47eff0b24. The affected component should be upgraded.

A flaw has been found in GPAC up to f1219cde. Affected by this vulnerability is the function gf_node_get_field_count of the file scenegraph/base_scenegraph.c of the component MP4Box. Executing a manipulation can lead to reachable assertion. It is possible to launch the attack on the local host. The exploit has been published and may be used. Upgrading to version abi-16.23 addresses this issue. This patch is called 49dee5cad329cfed310c1682703df7daa47df31a. You should upgrade the affected component.

A vulnerability was identified in Tencent AI-Infra-Guard up to 4.5.2/4.6.2. This affects the function startsWith of the file skill_scan/tools/dir/dir_actions.py of the component File Access. The manipulation leads to path traversal. The attack needs to be performed locally. The exploit is publicly available and might be used. Upgrading to version 4.6.0 is able to mitigate this issue. The identifier of the patch is ac0384edc9dbea3b226edefcf50613bd8509134f. You should upgrade the affected component.

A flaw has been found in OpenClaw ClawScan up to 0.1.6. This affects an unknown function of the file internal/runner/static_scanner.go of the component Static Scanner. This manipulation causes incomplete comparison with missing factors. It is possible to launch the attack on the local host. The exploit has been published and may be used. Upgrading to version 0.1.7 mitigates this issue. Patch name: 9f6a6fbb9f1137345566d0ab44c73893dfe112fa. The affected component should be upgraded.

Out-of-bounds read while parsing untrusted SVG path strings in Qt Quick's Context2D.path / PathSvg.path.

## Summary

The `/list_relationships` and `/retrieve_graph_neighborhood` endpoints call `getAuthenticatedUserId` (confirming a valid session exists) but do not pass the resolved user ID into the Supabase query as an `.eq("user_id", userId)` filter. As a result, queries return rows from all users rather than scoping to the authenticated caller's data.

## Affected code

**`/list_relationships`** (`src/actions.ts`):
- Calls `getAuthenticatedUserId` but does not apply `.eq("user_id", userId)` to the relationships query
- Uses `.or()` string interpolation for entity ID matching without input validation

**`/retrieve_graph_neighborhood`** (`src/actions.ts`):
- Same pattern: auth resolved, user ID not applied to query filter

## Affected versions

v0.13.0

## Prerequisites

1. A valid authentication token for the Neotoma instance (attacker must have a legitimate account on the same instance)
2. A known entity ID belonging to another user (~96 bits of entropy — brute-force not practical)

An unauthenticated caller is rejected at the auth middleware layer. The gap requires a second user account on the instance.

## Impact

An authenticated user with a known cross-user entity ID can retrieve relationship edges and graph neighborhood data belonging to another user. No write capability is exposed.

## Severity

Low under current conditions — no multi-tenant deployments exist. Escalates to Medium the moment two or more user accounts share an instance.

## Remediation

1. Add `.eq("user_id", userId)` to all Supabase queries in both handlers
2. Validate entity ID inputs with `isNeotomaEntityId` before query construction
3. Replace `.or()` string interpolation with separate scoped `.eq()` calls

Fix tracked in #365 (list_relationships) and #366 (retrieve_graph_neighborhood). Gate gap tracked in #372.

Orejime is a consent manager that focuses on accessibility. On HTML elements handled by Orejime prior to version 2.3.2, one could run malicious code by embedding `javascript:` code within data attributes. When consenting to the related purpose, Orejime would turn data attributes into unprefixed ones (i.e. `data-href` into `href`), thus executing the code. This shouldn't have any impact on most setups, as elements handled by Orejime are generally hardcoded. The problem would only arise if somebody could inject HTML code within pages. The problem has been patched in version 2.3.2. As a workaround, the problem can be fixed outside of Orejime by sanitizing attributes which could contain executable code.

Poetry is a dependency manager for Python. Prior to 2.3.4, the extractall() function in src/poetry/utils/helpers.py:410-426 extracts sdist tarballs without path traversal protection on Python versions where tarfile.data_filter is unavailable. Considering only Python versions which are still supported by Poetry, these are 3.10.0 - 3.10.12 and 3.11.0 - 3.11.4. This vulnerability is fixed in 2.3.4.

Fleet is open source device management software. In versions prior to 4.80.1, Fleet generated device lock and wipe PINs using a predictable algorithm based solely on the current Unix timestamp. Because no secret key or additional entropy was used, the resulting PIN could potentially be derived if the approximate time the device was locked is known. Fleet’s device lock and wipe commands generate a 6-digit PIN that is displayed to administrators for unlocking a device. In affected versions, this PIN was deterministically derived from the current timestamp. An attacker with physical possession of a locked device and knowledge of the approximate time the lock command was issued could theoretically predict the correct PIN within a limited search window. However, successful exploitation is constrained by multiple factors: Physical access to the device is required, the approximate lock time must be known, the operating system enforces rate limiting on PIN entry attempts, attempts would need to be spread over, and device wipe operations would typically complete before sufficient attempts could be made. As a result, this issue does not allow remote exploitation, fleet-wide compromise, or bypass of Fleet authentication controls. Version 4.80.1 contains a patch. No known workarounds are available.

### Summary

The `extractall()` function in `src/poetry/utils/helpers.py:410-426` extracts sdist tarballs without path traversal protection on Python versions where `tarfile.data_filter` is unavailable. Considering only Python versions which are still supported by Poetry, these are 3.10.0 - 3.10.12 and 3.11.0 - 3.11.4.

### Impact

Arbitrary file write (path traversal) from untrusted sdist content.

**In practice, the impact is low** because an attacker who exploits this vulnerability can as well include arbitrary code in a `setup.py`, which will be executed when the sdist is built after tar extraction. In other words, a malicious sdist can write arbitrary files by design. However, since it is unexpected and not by design that the file write already happens during tar extraction, this is still considered a vulnerability.

On Python 3.11.2 (Debian Bookworm default, directly tested), a crafted sdist with `../../` tar member paths writes files outside the intended extraction directory. The traversal occurs during metadata resolution (`poetry add --lock`), before the build backend is run.

Affected Environments: 
- **Python 3.10.0 through 3.10.12** (inclusive): `tarfile.data_filter` absent or broken
- **Python 3.11.0 through 3.11.4** (inclusive): `tarfile.data_filter` absent or broken
- **Debian Bookworm**: Python 3.11.2 (default)
- **Ubuntu 22.04 LTS**: Python 3.10.6 (default)

### Patches

Versions 2.3.4 and newer of Poetry ensure that paths are inside the target directory.

### Root Cause

File: `src/poetry/utils/helpers.py`, lines 410-426:

```python
def extractall(source: Path, dest: Path, zip: bool) -> None:
    """Extract all members from either a zip or tar archive."""
    if zip:
        with zipfile.ZipFile(source) as archive:
            archive.extractall(dest)
    else:
        broken_tarfile_filter = {(3, 9, 17), (3, 10, 12), (3, 11, 4)}
        with tarfile.open(source) as archive:
            if (
                hasattr(tarfile, "data_filter")
                and sys.version_info[:3] not in broken_tarfile_filter
            ):
                archive.extractall(dest, filter="data")
            else:
                archive.extractall(dest)  # <-- NO FILTER: path traversal
```

On Python versions without a working `tarfile.data_filter`, the `else` branch at line 426 calls `tarfile.extractall()` without any filter or path validation. This enables three attack vectors:

1. **Direct path traversal**: Tar members with `../../` path components write files outside the extraction directory.
2. **Symlink traversal**: A symlink member pointing outside dest, followed by a file written through that symlink, escapes the boundary.
3. **Hardlink attacks**: Hardlink members can read arbitrary files (same inode) or overwrite targets outside dest.

#### Call Sites

This function is called from two locations:

1. **`src/poetry/installation/chef.py:104`** (`_prepare_sdist`): During `poetry install` / `poetry add` when building a package from sdist. Only triggered when the executor is enabled (actual installation).

2. **`src/poetry/inspection/info.py:322`** (`_from_sdist_file`): During dependency resolution (`poetry lock` / `poetry add`). This path is reached when the sdist's `PKG-INFO` lacks `Requires-Dist` metadata, forcing Poetry to extract the archive (and afterwards build the package).

### Suggested Fix

Apply path validation in the `else` branch, covering direct traversal, symlinks, and hardlinks:

```python
def extractall(source: Path, dest: Path, zip: bool) -> None:
    """Extract all members from either a zip or tar archive."""
    if zip:
        with zipfile.ZipFile(source) as archive:
            archive.extractall(dest)
    else:
        broken_tarfile_filter = {(3, 9, 17), (3, 10, 12), (3, 11, 4)}
        with tarfile.open(source) as archive:
            if (
                hasattr(tarfile, "data_filter")
                and sys.version_info[:3] not in broken_tarfile_filter
            ):
                archive.extractall(dest, filter="data")
            else:
                # Validate all member paths before extraction
                dest_resolved = dest.resolve()
                safe_members = []
                for member in archive.getmembers():
                    member_path = (dest_resolved / member.name).resolve()
                    if not member_path.is_relative_to(dest_resolved):
                        raise ValueError(
                            f"Refusing to extract {member.name}: "
                            f"would write outside {dest}"
                        )
                    if member.issym():
                        link_target = (member_path.parent / member.linkname).resolve()
                        if not link_target.is_relative_to(dest_resolved):
                            raise ValueError(
                                f"Refusing symlink {member.name}: "
                                f"target {member.linkname} outside {dest}"
                            )
                    elif member.islnk():
                        link_target = (dest_resolved / member.linkname).resolve()
                        if not link_target.is_relative_to(dest_resolved):
                            raise ValueError(
                                f"Refusing hardlink {member.name}: "
                                f"target {member.linkname} outside {dest}"
                            )
                    safe_members.append(member)
                archive.extractall(dest, members=safe_members)
```

### Summary

The `asm!` block enabled by the off-by-default `asm` feature, when enabled on ARMv8 targets, misspecified the operand
type for all of its operands, using `in` for pointers and values which were subsequently mutated by operations performed
within the assembly block.

### Impact

It's unclear what practical impact, if any, this actually had. Incorrect operand types are technically undefined
behavior, however changing them had no actual impact on the generated assembly for these targets. The possibility still
exists that it may lead to potential memory safety or other issues on hypothetical future versions of rustc.

### Mitigation

The operand types were changed from `in` to `inout`, and the impacted versions of the `keccak` crate were yanked.

Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. In version 4.39.15, an attacker may potentially be able to inject javascript into the Authelia login page if several conditions are met simultaneously. Unless both the `script-src` and `connect-src` directives have been modified it's almost impossible for this to have a meaningful impact. However if both of these are and they are done so without consideration to their potential impact; there is a are situations where this vulnerability could be exploited. This is caused to the lack of neutralization of the `langauge` cookie value when rendering the HTML template. This vulnerability is likely difficult to discover though fingerprinting due to the way Authelia is designed but it should not be considered impossible. The additional requirement to identify the secondary application is however likely to be significantly harder to identify along side this, but also likely easier to fingerprint. Users should upgrade to 4.39.16 or downgrade to 4.39.14 to mitigate the issue. The overwhelming majority of installations will not be affected and no workarounds are necessary. The default value for the Content Security Policy makes exploiting this weakness completely impossible. It's only possible via the deliberate removal of the Content Security Policy or deliberate inclusion of clearly noted unsafe policies.

## Overview

Omni and each Talos machine establish a peer-to-peer (P2P) SideroLink connection using WireGuard to mutually authenticate and authorize access.

In this setup, Omni assigns a random IPv6 address to each Talos machine from a `/64` network block. Omni itself uses the fixed `::1` address within that same block.

From Omni's perspective, this is a WireGuard interface with multiple peers, where each peer corresponds to a Talos machine. The WireGuard interface on Omni is configured to ensure that the **source IP address** of an incoming packet matches the IPv6 address assigned to the Talos peer. However, it **performs no validation on the packet's destination address**.

The Talos end of the SideroLink connection cannot be considered a trusted environment. Workloads running on Kubernetes, especially those configured with host networking, could gain direct access to this link. Therefore, a malicious workload could theoretically send arbitrary packets over the SideroLink interface.

---

## Impact

This vulnerability creates two distinct attack scenarios based on Omni's `IP forwarding` configuration.

1.  **IP Forwarding Disabled (Default)**
    If `IP forwarding` is disabled, an attacker on a Talos machine can send packets over SideroLink to any listening service on Omni itself (e.g., an internal API). If Omni is running in host networking mode, any service on the host machine could also be targeted. While this is the default configuration, Omni does not enforce it.

2.  **IP Forwarding Enabled**
    If `IP forwarding` is enabled, an attacker on a Talos machine can communicate with other machines connected to Omni or route packets deeper into Omni's network. Although this is not the default configuration, Omni does not check for or prevent this state.

### Patches

The problem has been fixed in Omni >= [0.48.0](https://github.com/siderolabs/omni/releases/tag/v0.48.0), the commit is https://github.com/siderolabs/omni/commit/a5efd816a239e6c9e5ea7c0d43c02c04504d7b60

### Workarounds

Disable IP forwarding, implement strict firewall rules.

### References

None

Omni manages Kubernetes on bare metal, virtual machines, or in a cloud. Prior to version 0.48.0, Omni Wireguard SideroLink has the potential to escape. Omni and each Talos machine establish a peer-to-peer (P2P) SideroLink connection using WireGuard to mutually authenticate and authorize access. The WireGuard interface on Omni is configured to ensure that the source IP address of an incoming packet matches the IPv6 address assigned to the Talos peer. However, it performs no validation on the packet's destination address. The Talos end of the SideroLink connection cannot be considered a trusted environment. Workloads running on Kubernetes, especially those configured with host networking, could gain direct access to this link. Therefore, a malicious workload could theoretically send arbitrary packets over the SideroLink interface. This issue has been patched in version 0.48.0.

### Impact

**Official Weighted Severity Rating:** Low

This exploit is very unlikely to be the case for most users as it requires configuration of the Content Security Policy template value. Below represents a safe value, **_any other value_** other than unconfigured should be **_very carefully evaluated_** regardless of the fix.

```yaml
server:
  headers:
    csp_template: ''
```

```env
AUTHELIA_SERVER_HEADERS_CSP_TEMPLATE=
```

Provided the following conditions are met:

1. The Content Security Policy:
    1. Has been disabled or modified from the entirely safe default value; and
    2. Has been completely disabled by the Administrator by omitting the header explicitly at the proxy (worst practice); or
    3. Has been effectively disabled by modifying `script-src` allowing unsafe inline scripts rather than using hashes AND effectively disabled by modifying `connect-src` allowing connections to arbitrary websites.
2. Authelia is being hosted on a domain that has other applications that can write to the cookie for the Authelia domain.
3. One of the other applications noted in 2 has an vulnerability that can be exploited to execute malicious javascript with similar requirements to 1.
4. The attacker can exploit the javascript in 3 to delete the existing `language` cookie scoped to the fully qualified domain name of Authelia with the same site value of `strict` (which is not possible in most scenarios unless the application in 3 has the exact same domain or a subdomain of the Authelia domain).
5. The attacker can exploit the javascript in 3 to write a new `language` cookie scoped for a domain that Authelia is sent cookies for.
6. The attacker can get a user to meet the conditions required to execute the javascript in 3.
7. You are running Authelia 4.39.15.

An attacker may potentially be able to inject javascript into the Authelia login page. Unless both the `script-src` and `connect-src` directives have been modified it's almost impossible for this to have a meaningful impact. However if both of these are and they are done so without consideration to their potential impact; there is a are situations where this vulnerability could be exploited.

This is caused to the lack of neutralization of the `langauge` cookie value when rendering the HTML template.

This vulnerability is likely difficult to discover though fingerprinting due to the way Authelia is designed but it should not be considered impossible. The additional requirement to identify the secondary application is however likely to be significantly harder to identify along side this, but also likely easier to fingerprint.

### Patches

Upgrade to 4.39.16 or Downgrade to 4.39.14.

### Proof of Concept

No current proof of concept exists that does not require manual manipulation of the browser which is effectively a local attack where all privileges have been compromised without the need for this attack vector (i.e. installation of userscripts or a browser plugin which would be able to compromise any website or web app). There is a decent chance one will exist or certain conditions exist that could lead to the vulnerability being exploitable.

Discovery of this flaw has prompted an deliberate evaluation of any other potential flaws similar to this which did not yield any results, as well as a deliberate evaluation of best practices in this area which has resulted in a minor tweak to hardening measures. These additional hardening measures should not have any effect (explicit definition of the `script-src` and `connect-src` policies, which are the same value as `default` was previously), but it should theoretically prevent an accidental change in the future degrading the existing security layers we implement.

### Workarounds

The overwhelming majority of installations will not be affected and no workarounds are necessary. The default value for the Content Security Policy makes exploiting this weakness completely impossible. It's only possible via the deliberate removal of the Content Security Policy or deliberate inclusion of clearly noted unsafe policies.

#### Use the default Content Security Policy

The default Content Security Policy is completely secure and prevents any third party javascript the browser evaluates against it.

```yaml
server:
  headers:
    csp_template: ''
```

Using a custom Content Security Policy is a very advanced choice that requires specialist knowledge. The use of `unsafe-inline`, `unsafe-eval`, `unsafe-hashes`, etc. are particularly problematic as they effectively allow arbitrary script execution (if a security policy includes an option that says `unsafe` it's probably a good indication you should not use it).

#### Upgrade or Downgrade

Both the next version and previous version of Authelia do not have this bug.

### Impact
Refresh tokens are logged to the console when the disabled by default `debug` flag, is enabled.

### Patches
Patched in [https://github.com/workos/authkit-remix/releases/tag/v0.4.1](https://github.com/workos/authkit-remix/releases/tag/v0.4.1)

### Impact
Refresh tokens are logged to the console when the disabled by default `debug` flag, is enabled.

### Patches
Patched in [https://github.com/workos/authkit-nextjs/releases/tag/v0.13.2](https://github.com/workos/authkit-nextjs/releases/tag/v0.13.2)


CVE ID↕	Published↕	CVSS↓
DEBIAN-CVE-2025-13912	Dec 11, 2025	Low 1
CVE-2025-12888	Nov 21, 2025	Low 1
CVE-2026-6450	Jun 25, 2026	Low 1
DEBIAN-CVE-2026-61464	Jul 15, 2026	Low 1
CVE-2026-61464	Jul 15, 2026	Low 1
CVE-2025-64725	Dec 15, 2025	Low 1
CVE-2026-55061	Sep 17, 2026	Low 1
CVE-2025-27608	Apr 2, 2025	Low 1
CVE-2026-40319	Apr 17, 2026	Low 1
RUSTSEC-2026-0090	Apr 9, 2026	Low 1
CVE-2024-51481	Oct 31, 2024	Low 1
CVE-2026-40510	May 29, 2026	Low 1
GHSA-m6hq-f4w9-qrjj	Dec 15, 2025	Low 1
PYSEC-2026-2042	Jul 7, 2026	Low 1
GHSA-hfr4-7c6c-48w2	Apr 9, 2026	Low 1
CVE-2025-24959	Feb 3, 2025	Low 1
CVE-2025-32916	Oct 9, 2025	Low 1
CVE-2026-86422	Sep 7, 2026	Low 1
CVE-2026-6681	Jun 25, 2026	Low 1
CVE-2026-6678	Jun 25, 2026	Low 1
CVE-2025-7844	Aug 4, 2025	Low 1
CVE-2024-5899	Jun 18, 2024	Low 1
CVE-2025-49842	Jun 17, 2025	Low 1
CVE-2026-34983	Apr 9, 2026	Low 1
CVE-2026-40528	May 29, 2026	Low 1
CVE-2024-12975	Mar 7, 2025	Low 1
CVE-2025-13912	Dec 11, 2025	Low 1
CVE-2025-61670	Oct 7, 2025	Low 1
CVE-2026-88790	Sep 10, 2026	Low 0.9
CVE-2026-90685	Sep 14, 2026	Low 0.9
CVE-2026-90826	Sep 14, 2026	Low 0.9
CVE-2026-101079	Sep 28, 2026	Low 0.9
CVE-2026-91835	Sep 15, 2026	Low 0.9
CVE-2026-91090	Sep 15, 2026	Low 0.9
CVE-2026-90684	Sep 14, 2026	Low 0.9
CVE-2026-101080	Sep 28, 2026	Low 0.9
CVE-2026-91836	Sep 15, 2026	Low 0.9
DEBIAN-CVE-2026-79616	Sep 23, 2026	Low 0.6
GHSA-wrr4-782v-jhwh	Jun 25, 2026	Low 0.6
CVE-2025-68457	Dec 19, 2025	Low 0.6
DEBIAN-CVE-2026-41140	Apr 24, 2026	Low 0.6
CVE-2026-23999	Feb 26, 2026	Low 0.6
PYSEC-2026-2890	Jul 13, 2026	Low 0.6
GHSA-73h3-mf4w-8647	Apr 22, 2026	Low 0.6
CVE-2026-41140	Apr 24, 2026	Low 0.6
GHSA-3288-p39f-rqpv	Feb 19, 2026	Low 0.5
CVE-2026-33525	Mar 26, 2026	Low 0.5
GHSA-hqrf-67pm-wgfq	Sep 24, 2025	Low 0.5
CVE-2025-59824	Sep 24, 2025	Low 0.5
GHSA-gmfg-3v4q-9qr4	Mar 24, 2026	Low 0.5
GHSA-v2qh-f584-6hj8	Nov 5, 2024	Low 0.4
GHSA-5wmg-9cvh-qw25	Nov 5, 2024	Low 0.4

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.