diff --git a/advisories/github-reviewed/2024/10/GHSA-pj95-ph4q-4qm4/GHSA-pj95-ph4q-4qm4.json b/advisories/github-reviewed/2024/10/GHSA-pj95-ph4q-4qm4/GHSA-pj95-ph4q-4qm4.json
index 630fab0abf7..36df2cffddf 100644
--- a/advisories/github-reviewed/2024/10/GHSA-pj95-ph4q-4qm4/GHSA-pj95-ph4q-4qm4.json
+++ b/advisories/github-reviewed/2024/10/GHSA-pj95-ph4q-4qm4/GHSA-pj95-ph4q-4qm4.json
@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-pj95-ph4q-4qm4",
-  "modified": "2024-10-02T21:50:29Z",
+  "modified": "2025-03-20T18:51:13Z",
   "published": "2024-10-02T18:31:32Z",
   "aliases": [
     "CVE-2024-47803"
diff --git a/advisories/github-reviewed/2024/12/GHSA-jpmc-7p9c-4rxf/GHSA-jpmc-7p9c-4rxf.json b/advisories/github-reviewed/2024/12/GHSA-jpmc-7p9c-4rxf/GHSA-jpmc-7p9c-4rxf.json
index a16ad4cc26d..293a17f5e6a 100644
--- a/advisories/github-reviewed/2024/12/GHSA-jpmc-7p9c-4rxf/GHSA-jpmc-7p9c-4rxf.json
+++ b/advisories/github-reviewed/2024/12/GHSA-jpmc-7p9c-4rxf/GHSA-jpmc-7p9c-4rxf.json
@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-jpmc-7p9c-4rxf",
-  "modified": "2024-12-09T22:43:13Z",
+  "modified": "2025-03-20T18:52:08Z",
   "published": "2024-12-09T22:43:13Z",
   "aliases": [
     "CVE-2024-6219"
   ],
   "summary": "lxd has a restricted TLS certificate privilege escalation when in PKI mode",
-  "details": "### Summary\nIf 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. \n\nThe 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.\n\nWhen 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.\n\n### Details\nWhen 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/5cdc9a35b9c51e981b1e70330bde0413ccacc7fd) was added to LXD to fix the issue. \n\nThe cherry-pick fixed the immediate issue and allowed full access to LXD for CA-signed client certificates when `core.trust_ca_certificates` is enabled, but did not consider the behaviour of LXD when `core.trust_ca_certificates` is disabled. \n\nWhen `core.trust_ca_certificates` is false, restrictions that are applied to a certificate should be honoured. Instead, they are being ignored due to the presence of a `server.ca` file in `LXD_DIR`.\n\n### PoC\n```\n# Install/initialize LXD\n$ snap install lxd --channel 5.21/stable\n$ lxd init --auto\n$ lxc config set core.https_address=127.0.0.1:8443\n\n# Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa\n$ cp -R /usr/share/easy-rsa \"/tmp/pki\"\n$ export EASYRSA_KEY_SIZE=4096\n$ cd /tmp/pki\n$ ./easyrsa init-pki\n$ echo \"lxd\" | ./easyrsa build-ca nopass\n$ ./easyrsa build-client-full lxd-client nopass\n$ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca\n$ cp pki/issued/lxd-client.crt ~/snap/lxd/common/config/client.crt\n$ cp pki/private/lxd-client.key ~/snap/lxd/common/config/client.key\n\n# Restart daemon.\n$ systemctl reload snap.lxd.daemon\n\n# Add a restricted certificate to the trust store.\n$ token=\"$(lxc config trust add --name ca-test --quiet --restricted)\"\n$ lxc remote add tls \"${token}\"\n\n# Our client has a CA-signed certificate, but it is restricted, so the client should not be able to view server config.\n$ lxc config get tls: core.https_address\n127.0.0.1:8443\n```\n\n### Impact\nI believe this vulnerability is low impact because PKI mode is:\n1. Not the standard or recommended mode of operation for LXD.\n2. While `core.trust_ca_certificates` defaults to false, we believe that users who enable PKI mode will generally have `core.trust_ca_certificates` enabled to allow for passwordless PKI with CRL revocation (see https://github.com/canonical/lxd/issues/3832). When this mode is enabled, all clients with CA-signed certificates have root access* anyway.\n\n*Note: If a restricted certificate is added before `core.trust_ca_certificates` is enabled, the certificate becomes unrestricted. We believe this was the original intention of the PR, but this should be changed to disallow any unintended permission change.\n",
+  "details": "### Summary\nIf 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. \n\nThe 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.\n\nWhen 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.\n\n### Details\nWhen 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/5cdc9a35b9c51e981b1e70330bde0413ccacc7fd) was added to LXD to fix the issue. \n\nThe cherry-pick fixed the immediate issue and allowed full access to LXD for CA-signed client certificates when `core.trust_ca_certificates` is enabled, but did not consider the behaviour of LXD when `core.trust_ca_certificates` is disabled. \n\nWhen `core.trust_ca_certificates` is false, restrictions that are applied to a certificate should be honoured. Instead, they are being ignored due to the presence of a `server.ca` file in `LXD_DIR`.\n\n### PoC\n```\n# Install/initialize LXD\n$ snap install lxd --channel 5.21/stable\n$ lxd init --auto\n$ lxc config set core.https_address=127.0.0.1:8443\n\n# Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa\n$ cp -R /usr/share/easy-rsa \"/tmp/pki\"\n$ export EASYRSA_KEY_SIZE=4096\n$ cd /tmp/pki\n$ ./easyrsa init-pki\n$ echo \"lxd\" | ./easyrsa build-ca nopass\n$ ./easyrsa build-client-full lxd-client nopass\n$ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca\n$ cp pki/issued/lxd-client.crt ~/snap/lxd/common/config/client.crt\n$ cp pki/private/lxd-client.key ~/snap/lxd/common/config/client.key\n\n# Restart daemon.\n$ systemctl reload snap.lxd.daemon\n\n# Add a restricted certificate to the trust store.\n$ token=\"$(lxc config trust add --name ca-test --quiet --restricted)\"\n$ lxc remote add tls \"${token}\"\n\n# Our client has a CA-signed certificate, but it is restricted, so the client should not be able to view server config.\n$ lxc config get tls: core.https_address\n127.0.0.1:8443\n```\n\n### Impact\nI believe this vulnerability is low impact because PKI mode is:\n1. Not the standard or recommended mode of operation for LXD.\n2. While `core.trust_ca_certificates` defaults to false, we believe that users who enable PKI mode will generally have `core.trust_ca_certificates` enabled to allow for passwordless PKI with CRL revocation (see https://github.com/canonical/lxd/issues/3832). When this mode is enabled, all clients with CA-signed certificates have root access* anyway.\n\n*Note: If a restricted certificate is added before `core.trust_ca_certificates` is enabled, the certificate becomes unrestricted. We believe this was the original intention of the PR, but this should be changed to disallow any unintended permission change.",
   "severity": [
     {
       "type": "CVSS_V3",
@@ -63,7 +63,8 @@
   ],
   "database_specific": {
     "cwe_ids": [
-      "CWE-287"
+      "CWE-287",
+      "CWE-295"
     ],
     "severity": "LOW",
     "github_reviewed": true,
diff --git a/advisories/unreviewed/2025/03/GHSA-mrhh-3ggq-23p2/GHSA-mrhh-3ggq-23p2.json b/advisories/github-reviewed/2025/03/GHSA-mrhh-3ggq-23p2/GHSA-mrhh-3ggq-23p2.json
similarity index 65%
rename from advisories/unreviewed/2025/03/GHSA-mrhh-3ggq-23p2/GHSA-mrhh-3ggq-23p2.json
rename to advisories/github-reviewed/2025/03/GHSA-mrhh-3ggq-23p2/GHSA-mrhh-3ggq-23p2.json
index e8809a2bc3c..6b675723e16 100644
--- a/advisories/unreviewed/2025/03/GHSA-mrhh-3ggq-23p2/GHSA-mrhh-3ggq-23p2.json
+++ b/advisories/github-reviewed/2025/03/GHSA-mrhh-3ggq-23p2/GHSA-mrhh-3ggq-23p2.json
@@ -1,11 +1,12 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-mrhh-3ggq-23p2",
-  "modified": "2025-03-20T12:32:38Z",
+  "modified": "2025-03-20T18:53:09Z",
   "published": "2025-03-20T12:32:38Z",
   "aliases": [
     "CVE-2024-10190"
   ],
+  "summary": "Horovod Vulnerable to Command Injection",
   "details": "Horovod versions up to and including v0.28.1 are vulnerable to unauthenticated remote code execution. The vulnerability is due to improper handling of base64-encoded data in the `ElasticRendezvousHandler`, a subclass of `KVStoreHandler`. Specifically, the `_put_value` method in `ElasticRendezvousHandler` calls `codec.loads_base64(value)`, which eventually invokes `cloudpickle.loads(decoded)`. This allows an attacker to send a malicious pickle object via a PUT request, leading to arbitrary code execution on the server.",
   "severity": [
     {
@@ -13,12 +14,36 @@
       "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
     }
   ],
-  "affected": [],
+  "affected": [
+    {
+      "package": {
+        "ecosystem": "PyPI",
+        "name": "horovod"
+      },
+      "ranges": [
+        {
+          "type": "ECOSYSTEM",
+          "events": [
+            {
+              "introduced": "0"
+            },
+            {
+              "last_affected": "0.28.1"
+            }
+          ]
+        }
+      ]
+    }
+  ],
   "references": [
     {
       "type": "ADVISORY",
       "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10190"
     },
+    {
+      "type": "PACKAGE",
+      "url": "https://github.com/horovod/horovod"
+    },
     {
       "type": "WEB",
       "url": "https://huntr.com/bounties/3e398d1f-70c2-4e05-ae22-f5d66b19a754"
@@ -29,8 +54,8 @@
       "CWE-77"
     ],
     "severity": "CRITICAL",
-    "github_reviewed": false,
-    "github_reviewed_at": null,
+    "github_reviewed": true,
+    "github_reviewed_at": "2025-03-20T18:53:09Z",
     "nvd_published_at": "2025-03-20T10:15:15Z"
   }
 }
\ No newline at end of file