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