Total
4 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-36533 | 2024-11-21 | N/A | 9.8 CRITICAL | ||
| Insecure permissions in volcano v1.8.2 allows attackers to access sensitive data and escalate privileges by obtaining the service account's token. | |||||
| CVE-2024-36111 | 2024-11-21 | N/A | 6.3 MEDIUM | ||
| KubePi is a K8s panel. Starting in version 1.6.3 and prior to version 1.8.0, there is a defect in the KubePi JWT token verification. The JWT key in the default configuration file is empty. Although a random 32-bit string will be generated to overwrite the key in the configuration file when the key is detected to be empty in the configuration file reading logic, the key is empty during actual verification. Using an empty key to generate a JWT token can bypass the login verification and directly take over the back end. Version 1.8.0 contains a patch for this issue. | |||||
| CVE-2022-23551 | 2024-11-21 | N/A | 5.3 MEDIUM | ||
| aad-pod-identity assigns Azure Active Directory identities to Kubernetes applications and has now been deprecated as of 24 October 2022. The NMI component in AAD Pod Identity intercepts and validates token requests based on regex. In this case, a token request made with backslash in the request (example: `/metadata/identity\oauth2\token/`) would bypass the NMI validation and be sent to IMDS allowing a pod in the cluster to access identities that it shouldn't have access to. This issue has been fixed and has been included in AAD Pod Identity release version 1.8.13. If using the AKS pod-managed identities add-on, no action is required. The clusters should now be running the version 1.8.13 release. | |||||
| CVE-2024-41948 | 1 Biscuitsec | 1 Biscuit-java | 2024-08-09 | N/A | 5.0 MEDIUM |
| biscuit-java is the java implementation of Biscuit, an authentication and authorization token for microservices architectures. 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, which includes the public key of the previous block (used in the signature) and 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. This vulnerability is fixed in 4.0.0. | |||||