Geal

**Name of the Vulnerable Software and Affected Versions** biscuit-java versions prior to 4.0.0 **Description** The issue concerns the generation of third-party blocks for authentication and authorization tokens in microservices architectures. A malicious user can forge a third-party block request, tricking the third-party authority into generating datalog that trusts the wrong keypair. This can be achieved by altering the public keys field in the `ThirdPartyBlockRequest` and replacing the actual public key with a different one, allowing the attacker to use the token without obtaining a third-party block from the intended authority. **Recommendations** For biscuit-java versions prior to 4.0.0, upgrade to version 4.0.0 to fix the issue. As a temporary workaround, consider restricting the use of third-party block requests until the patch is applied. Avoid using altered symbol tables in `ThirdPartyBlockRequest` to prevent exploitation.

**Name of the Vulnerable Software and Affected Versions** biscuit-rust (affected versions not specified) **Description** The issue concerns biscuit-rust, the Rust implementation of Biscuit, an authentication and authorization token for microservices architectures. A third-party block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair. This occurs because third-party blocks can be generated without transferring the whole token to the third-party authority, using a `ThirdPartyBlock` request that includes the public key of the previous block and the public keys part of the token symbol table. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Biscuit versions prior to 4 **Description** The issue concerns the generation of third-party blocks in Biscuit, an authorization token with decentralized verification. A malicious user can forge a `ThirdPartyBlock` request, tricking the third-party authority into generating datalog that trusts the wrong keypair. This can be achieved by altering the `publicKeys` field in the `ThirdPartyBlockRequest` and replacing the actual public key with a different one, allowing the attacker to use the token without obtaining a third-party block from the intended authority. **Recommendations** For versions prior to 4, update the implementation to conform to version 4 of the specification to address this issue. At the moment, there is no information about other versions that contain a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Biscuit versions 1 **Description** The Biscuit specification version 1 contains a vulnerable algorithm that allows malicious actors to forge valid Γ-signatures. This would allow an attacker to create a token with any access level. The version 2 of the specification mandates a different algorithm than gamma signatures and as such is not affected by this vulnerability. There are no known workarounds for this issue. As Biscuit v1 was still an early version and not broadly deployed, all known users of Biscuit v1 were contacted and helped to migrate to Biscuit v2. There is no known active exploitation of this vulnerability. **Recommendations** For Biscuit versions 1, migrate to Biscuit version 2 to resolve the issue, as version 2 mandates a different algorithm than gamma signatures and is not affected by this vulnerability.