Latest News

**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…

Drupal core contains a potential PHP Object Injection vulnerability that (if combined with another exploit) could lead to Remote Code Execution. It is not directly exploitable. This issue is mitigated by the fact that in order for it to be exploitable, a separate vulnerability must be present to allow an attacker to pass unsafe input to `unserialize()`. There are no such known exploits in Drupal core. To help protect against this potential vulnerability, types have been added to properties in some of Drupal core's classes. If an application extends those classes, the same types may need to be specified on the subclass to avoid a `TypeError`. This issue affects Drupal Core: from 8.0.0 before 10.2.11, from 10.3.0 before 10.3.9, from 11.0.0 before 11.0.8.

Drupal's uniqueness checking for certain user fields is inconsistent depending on the database engine and its collation. As a result, a user may be able to register with the same email address as another user. This may lead to data integrity issues. This issue affects Drupal Core: from 8.0.0 before 10.2.11, from 10.3.0 before 10.3.9, from 11.0.0 before 11.0.8.

Drupal core contains a potential PHP Object Injection vulnerability that (if combined with another exploit) could lead to Artbitrary File Deletion. It is not directly exploitable. This issue is mitigated by the fact that in order to be exploitable, a separate vulnerability must be present that allows an attacker to pass unsafe input to `unserialize()`. There are no such known exploits in Drupal core. To help protect against this vulnerability, types have been added to properties in some of Drupal core's classes. If an application extends those classes, the same types may need to be specified on the subclass to avoid a `TypeError`. This issue affects Drupal Core: from 8.0.0 before 10.2.11, from 10.3.0 before 10.3.9, from 11.0.0 before 11.0.8.

Drupal core contains a potential PHP Object Injection vulnerability that (if combined with another exploit) could lead to Remote Code Execution. It is not directly exploitable. This issue is mitigated by the fact that in order for it to be exploitable, a separate vulnerability must be present to allow an attacker to pass unsafe input to `unserialize()`. There are no such known exploits in Drupal core. To help protect against this potential vulnerability, some additional checks have been added to Drupal core's database code. If you use a third-party database driver, check the release notes for additional configuration steps that may be required in certain cases. This issue affects Drupal Core: from 7.0 before 7.102, from 8.0.0 before 10.2.11, from 10.3.0 before 10.3.9.

Drupal uses JavaScript to render status messages in some cases and configurations. In certain situations, the status messages are not adequately sanitized. This issue affects Drupal Core: from 8.8.0 before 10.2.11, from 10.3.0 before 10.3.9, from 11.0.0 before 11.0.8.

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