#git

A suspected China-nexus cyber espionage group has been attributed to an attacks targeting large business-to-business IT service providers in Southern Europe as part of a campaign codenamed Operation Digital Eye. The intrusions took place from late June to mid-July 2024, cybersecurity companies SentinelOne SentinelLabs and Tinexta Cyber said in a joint report shared with The Hacker News, adding

A Chinese threat actor infiltrated several IT and security companies in a bring-your-own VS code, with an eye to carrying out a supply-chain-based espionage attack.

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

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

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

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