biscuit-java vulnerable to public key confusion in third party block
Impact
Tokens 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.
Description
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:
the public key of the previous block (used in the signature) the public keys part of the token symbol table (for public key interning in datalog expressions) A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.
Consider the following example (nominal case)
- Authority A emits the following token:
check if thirdparty("b") trusting ${pubkeyB} - The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority B
- Third-party B generates the following third-party block
thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC} - The token holder now must obtain a third-party block from third party C to be able to use the token
Now, with a malicious user:
- Authority A emits the following token:
check if thirdparty("b") trusting ${pubkeyB} - The holder then attenuates the token with the following third party block
thirdparty("c"), signed with a keypair pubkeyD, privkeyD) they generate - The holder then generates a third-party block request based on this token, but alter the
ThirdPartyBlockRequestpublicKeys field and replace pubkeyD with pubkeyC - Third-party B generates the following third-party block
thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC} - Due to the altered symbol table, the actual meaning of the block is
thirdparty("b"); check if thirdparty("c") trusting ${pubkeyD} - The attacker can now use the token without obtaining a third-party block from C.
Patches
Has the problem been patched? What versions should users upgrade to?
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
References
Are there any links users can visit to find out more?
Affected software
Click a technology to see all vulnerabilities affecting it.
| Platform | Package | Vulnerable versions | Fixed in |
|---|---|---|---|
| Java / Kotlin (Maven) | org.biscuitsec:biscuit | >= 3.0.0, < 4.0.0 | 4.0.0 |
References
- https://github.com/biscuit-auth/biscuit-java/security/advisories/GHSA-5hcj-rwm6-xmw4
- https://github.com/biscuit-auth/biscuit/security/advisories/GHSA-rgqv-mwc3-c78m
- https://nvd.nist.gov/vuln/detail/CVE-2024-41948
- https://github.com/biscuit-auth/biscuit-java/commit/2e05e7b3f8f2aae38f33294f19419e2d638cb564
- https://github.com/biscuit-auth/biscuit-java
- https://github.com/biscuit-auth/biscuit-java/releases/tag/4.0.0
- CVSS vector
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:L/A:N- Weakness (CWE)
CWE-1259- Platform
- Java / Kotlin (Maven)
- Package
org.biscuitsec:biscuit- Disclosed
- 31.07.2024
- Updated
- 11.10.2026 12:21
Sources and licenses
OSV / GitHub Advisory Database - GHSA-5hcj-rwm6-xmw4 - CC BY 4.0
Vulnerability history: org.biscuitsec:biscuit
All published vulnerabilities of this package (Java / Kotlin (Maven)), newest first. Shows whether this is a one-off slip or a package that needs watching.
This is the only known vulnerability of this package.
Know which vulnerabilities affect your application
With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.