#vulnerability

### Summary If a `server.ca` file is present in `LXD_DIR` at LXD start up, LXD is in "PKI mode". In this mode, only TLS clients that have a CA-signed certificate should be able to authenticate with LXD. We have discovered that if a client that sends a non-CA signed certificate during the TLS handshake, that client is able to authenticate with LXD if their certificate is present in the trust store. - The LXD Go client (and by extension `lxc`) does not send non-CA signed certificates during the handshake. - A manual client (e.g. `cURL`) might send a non-CA signed certificate during the handshake. #### Versions affected LXD 4.0 and above. ### Details When PKI mode was added to LXD it was intended that all client and server certificates *must* be signed by the certificate authority (see https://github.com/canonical/lxd/pull/2070/commits/84d917bdcca6fe1e3191ce47f1597c7d094e1909). In PKI mode, the TLS listener configuration is altered to add the CA certificate but the `ClientAut...

### Summary If a `server.ca` file is present in `LXD_DIR` at LXD start up, LXD is in "PKI mode". In this mode, all clients must have certificates that have been signed by the CA. The LXD configuration option `core.trust_ca_certificates` defaults to `false`. This means that although the client certificate has been signed by the CA, LXD will additionally add the certificate to the trust store and verify it via mTLS. When a restricted certificate is added to the trust store in this mode, it's restrictions are not honoured, and the client has full access to LXD. ### Details When authorization was refactored to allow for generalisation (at the time for TLS, RBAC, and OpenFGA, see https://github.com/canonical/lxd/pull/12313), PKI mode did not account for the `core.trust_ca_certificates` configuration option. When this option is enabled, all CA-signed client certificates are given full access to LXD. [This cherry-pick from Incus](https://github.com/canonical/lxd/pull/12513/commits/5cdc9a3...

The second zero-day vulnerability found in Windows NTLM in the past two months paves the way for relay attacks and credential theft. Microsoft has no patch, but released updated NTLM cyberattack mitigation advice.

Protect your systems with automated patching and server hardening strategies to defend against vulnerabilities like the NTLM zero-day.…

A vulnerability was found in OIDC-Client. When using the RH SSO OIDC adapter with EAP 7.x or when using the elytron-oidc-client subsystem with EAP 8.x, authorization code injection attacks can occur, allowing an attacker to inject a stolen authorization code into the attacker's own session with the client with a victim's identity. This is usually done with a Man-in-the-Middle (MitM) or phishing attack.

unstructured v.0.14.2 and before is vulnerable to XML External Entity (XXE) via the XMLParser.

due to a weakness in the encryption method used in cookie-encrypter an attack can use the world visible IV to edit encrypted cookies without decrypting the cookie itself. This is known as an AES CBC bit flipping attack.

## Impact Some HTML attributes in Markdown in the internal templates listed below not escaped. Impacted are Hugo users who do not trust their Markdown content files and are using one or more of these templates. * `_default/_markup/render-link.html` from `v0.123.0` * `_default/_markup/render-image.html` from `v0.123.0` * `_default/_markup/render-table.html` from `v0.134.0` * `shortcodes/youtube.html` from `v0.125.0` ## Patches Patched in v0.139.4. ## Workarounds Replace with user defined templates or disable the internal templates: https://gohugo.io/getting-started/configuration-markup/#renderhooksimageenabledefault ## References * https://github.com/gohugoio/hugo/releases/tag/v0.139.4 * https://gohugo.io/about/security/

### Impact Several polynomial time complexity issues in league/commonmark may lead to unbounded resource exhaustion and subsequent denial of service. Malicious users could trigger that inefficient code with carefully crafted Markdown inputs that are specifically designed to ensure the worst-case performance is reached. Sending multiple such requests in parallel could tie up all available CPU resources and/or PHP-FPM processes, leading to denial of service for legitimate users. ### Patches These vulnerabilities have been patched in version 2.6.0. All users on older versions are highly encouraged to upgrade as soon as possible. ### Workarounds If you cannot upgrade, you may be able to mitigate the issues by: - Setting very low `memory_limit` and `max_execution_time` PHP configurations to prevent runaway resource usage - Implementing rate-limiting, bot protection, or other approaches to reduce the risk of simultaneous bad requests hitting your site - Limiting the size of inputs f...

The Trix editor, in versions prior to 2.1.9 and 1.3.3, is vulnerable to XSS + mutation XSS attacks when pasting malicious code. ### Impact An attacker could trick a user to copy and paste malicious code that would execute arbitrary JavaScript code within the context of the user's session, potentially leading to unauthorized actions being performed or sensitive information being disclosed. ### Patches Update Recommendation: Users should upgrade to Trix editor version 2.1.9 or later, which uses [DOMPurify](https://github.com/cure53/DOMPurify) to sanitize the pasted content. If using Trix 1.x, upgrade to version 1.3.3 or later. ### Mitigations This is not really a workaround but something that should be considered in addition to upgrading to the patched version. If affected users can disallow browsers that don't support a Content Security Policy, then this would be an effective workaround for this and all XSS vulnerabilities. Set CSP policies such as script-src 'self' to ensure th...