#auth

**How would an attacker exploit this vulnerability?** This vulnerability would require an authenticated attacker on a guest VM to send specially crafted file operation requests on the VM to hardware resources on the VM which could result in remote code execution on the host server.

**How could an attacker exploit this vulnerability?** An authenticated attacker could exploit the vulnerability by triggering remote code execution (RCE) on the server via a Remote Desktop connection. Alternatively, an authenticated attacker could trigger guest-to-host RCE via a malicious program by connecting to the host using MMC.

Versions of the package luigi before 3.6.0 are vulnerable to Arbitrary File Write via Archive Extraction (Zip Slip) due to improper destination file path validation in the _extract_packages_archive function.

Summary Cybersecurity researchers have identified a large-scale hacking operation linked to notorious ShinyHunters and Nemesis hacking groups. In…

It’s easy to tick the checkboxes on a compliance checklist with the mindset that your system is protected and not exposed to risk. If it is this simple, why do we continue to invest billions of dollars in developing security controls and software development lifecycle (SDL) practices that help harden software and minimize risk? What is the value in configuring services, tuning firewalls, and enforcing access policies only to accept a risk rating for a vulnerability directly mapped to a base score that seemingly ignores all the work done?This contradictory model of focusing on security featur

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