CVE-2025-61779
BaseFortify
Publication date: 2025-10-09
Last updated on: 2025-10-14
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| confidential_containers | trustee | 0.11.0 |
| confidential_containers | trustee | 0.15.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability in CVE-2025-61779 is in the Confidential Containers' Trustee project, specifically in the 'attestation-policy' endpoint. Before version 0.15.0, this endpoint did not verify if the requesting kbs-client was properly authenticated as an administrator. This lack of authentication allowed any kbs-client, even those without the correct key, to change the attestation policy arbitrarily. The issue was fixed by adding proper admin authentication checks to ensure only authorized users can modify the attestation policy. [1, 2, 3]
How can this vulnerability impact me? :
This vulnerability can severely impact security by allowing unauthorized users to modify the attestation policy within the Trustee component. Since attestation policies are critical for verifying and trusting confidential guests, unauthorized changes could compromise the integrity and trustworthiness of the system, potentially leading to unauthorized access or exposure of sensitive secrets. [1, 3]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection involves monitoring attempts to access or modify the attestation-policy endpoint without proper authentication. You can inspect logs for POST requests to the attestation-policy endpoint from unauthorized kbs-clients. For example, using curl to test the endpoint without authentication: curl -X POST https://<trustee-server>/attestation-policy -d '<policy-data>' -v and checking if the request is accepted. Additionally, network monitoring tools can be used to detect unauthorized POST requests to this endpoint. [1, 3]
What immediate steps should I take to mitigate this vulnerability?
Immediately upgrade the confidential-containers/trustee project to version 0.15.0 or later, where the attestation-policy endpoint enforces administrative authentication. Until the upgrade, restrict network access to the attestation-policy endpoint to trusted clients only, and monitor for unauthorized access attempts. Applying the fix from pull request #957 ensures that only authenticated administrators can modify the attestation policy. [1, 2, 3]