diff --git a/advisories/github-reviewed/2024/07/GHSA-5hcj-rwm6-xmw4/GHSA-5hcj-rwm6-xmw4.json b/advisories/github-reviewed/2024/07/GHSA-5hcj-rwm6-xmw4/GHSA-5hcj-rwm6-xmw4.json
index 3e768000c9f..1a70eb3424f 100644
--- a/advisories/github-reviewed/2024/07/GHSA-5hcj-rwm6-xmw4/GHSA-5hcj-rwm6-xmw4.json
+++ b/advisories/github-reviewed/2024/07/GHSA-5hcj-rwm6-xmw4/GHSA-5hcj-rwm6-xmw4.json
@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5hcj-rwm6-xmw4",
-  "modified": "2024-08-02T16:01:39Z",
+  "modified": "2024-08-02T20:35:06Z",
   "published": "2024-07-31T18:48:40Z",
   "aliases": [
     "CVE-2024-41948"
   ],
   "summary": "biscuit-java vulnerable to public key confusion in third party block",
-  "details": "### Impact\nTokens with third-party blocks containing trusted annotations generated through a third party block request. Due to implementation issues in biscuit-java,  third party block support in published versions is inoperating. Nevertheless, to synchronize with other implementations, we publish this advisory and the related fix.\n\n### Description\nThird-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it:\n\nthe public key of the previous block (used in the signature)\nthe public keys part of the token symbol table (for public key interning in datalog expressions)\nA third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.\n\nConsider the following example (nominal case)\n* Authority A emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n* The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority B\n* Third-party B generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n* The token holder now must obtain a third-party block from third party C to be able to use the token\n\nNow, with a malicious user:\n* Authority A emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n* The holder then attenuates the token with the following third party block `thirdparty(\"c\")`, signed with a keypair pubkeyD, privkeyD) they generate\n* The holder then generates a third-party block request based on this token, but alter the `ThirdPartyBlockRequest` publicKeys field and replace pubkeyD with pubkeyC\n* Third-party B generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n* Due to the altered symbol table, the actual meaning of the block is `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyD}`\n* The attacker can now use the token without obtaining a third-party block from C.",
+  "details": "### Impact\nTokens with third-party blocks containing trusted annotations generated through a third party block request. Due to implementation issues in biscuit-java,  third party block support in published versions is inoperating. Nevertheless, to synchronize with other implementations, we publish this advisory and the related fix.\n\n### Description\nThird-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it:\n\nthe public key of the previous block (used in the signature)\nthe public keys part of the token symbol table (for public key interning in datalog expressions)\nA third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.\n\nConsider the following example (nominal case)\n* Authority A emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n* The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority B\n* Third-party B generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n* The token holder now must obtain a third-party block from third party C to be able to use the token\n\nNow, with a malicious user:\n* Authority A emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n* The holder then attenuates the token with the following third party block `thirdparty(\"c\")`, signed with a keypair pubkeyD, privkeyD) they generate\n* The holder then generates a third-party block request based on this token, but alter the `ThirdPartyBlockRequest` publicKeys field and replace pubkeyD with pubkeyC\n* Third-party B generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n* Due to the altered symbol table, the actual meaning of the block is `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyD}`\n* The attacker can now use the token without obtaining a third-party block from C.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n### References\n_Are there any links users can visit to find out more?_\n\n",
   "severity": [
     {
       "type": "CVSS_V3",
diff --git a/advisories/github-reviewed/2024/07/GHSA-p9w4-585h-g3c7/GHSA-p9w4-585h-g3c7.json b/advisories/github-reviewed/2024/07/GHSA-p9w4-585h-g3c7/GHSA-p9w4-585h-g3c7.json
index 272be3f131c..f675335cfde 100644
--- a/advisories/github-reviewed/2024/07/GHSA-p9w4-585h-g3c7/GHSA-p9w4-585h-g3c7.json
+++ b/advisories/github-reviewed/2024/07/GHSA-p9w4-585h-g3c7/GHSA-p9w4-585h-g3c7.json
@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-p9w4-585h-g3c7",
-  "modified": "2024-08-02T16:01:43Z",
+  "modified": "2024-08-02T20:34:49Z",
   "published": "2024-07-31T21:15:41Z",
   "aliases": [
     "CVE-2024-41949"
   ],
   "summary": "biscuit-auth vulnerable to public key confusion in third party block",
-  "details": "Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it:\n\n- the public key of the previous block (used in the signature)\n- the public keys part of the token symbol table (for public key interning in datalog expressions)\n\nA third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.\n\nConsider the following example (nominal case)\n\n- Authority `A` emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n- The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority `B`\n- Third-party `B` generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n- The token holder now must obtain a third-party block from third party `C` to be able to use the token\n\nNow, with a malicious user:\n- Authority `A` emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n- The holder then attenuates the token with the following third party block `thirdparty(\"c\")`, signed with a keypair `pubkeyD, privkeyD)` they generate\n- The holder then generates a third-party block request based on this token, but alter the `ThirdPartyBlockRequest` `publicKeys` field and replace `pubkeyD` with `pubkeyC`\n- Third-party `B` generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n- Due to the altered symbol table, the actual meaning of the block is `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyD}`\n- The attacker can now use the token without obtaining a third-party block from `C`.\n\n### Impact\n\nTokens with third-party blocks containing `trusted` annotations generated through a third party block request",
+  "details": "Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it:\n\n- the public key of the previous block (used in the signature)\n- the public keys part of the token symbol table (for public key interning in datalog expressions)\n\nA third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.\n\nConsider the following example (nominal case)\n\n- Authority `A` emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n- The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority `B`\n- Third-party `B` generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n- The token holder now must obtain a third-party block from third party `C` to be able to use the token\n\nNow, with a malicious user:\n- Authority `A` emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n- The holder then attenuates the token with the following third party block `thirdparty(\"c\")`, signed with a keypair `pubkeyD, privkeyD)` they generate\n- The holder then generates a third-party block request based on this token, but alter the `ThirdPartyBlockRequest` `publicKeys` field and replace `pubkeyD` with `pubkeyC`\n- Third-party `B` generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n- Due to the altered symbol table, the actual meaning of the block is `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyD}`\n- The attacker can now use the token without obtaining a third-party block from `C`.\n\n### Impact\n\nTokens with third-party blocks containing `trusted` annotations generated through a third party block request\n",
   "severity": [
     {
       "type": "CVSS_V3",