https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 04:56:02 +0000 https://cve.radiocsirt.org/vuln/cve-2022-3500 <p><strong>Affected:</strong> keylime</p> <p>A vulnerability was found in keylime. This security issue happens in some circumstances, due to some improperly handled exceptions, there exists the possibility that a rogue agent could create errors on the verifier that stopped attestation attempts for that host leaving it in an attested state but not verifying that anymore.</p> <p><strong>Affected:</strong> keylime</p> <p>A vulnerability was found in keylime. This security issue happens in some circumstances, due to some improperly handled exceptions, there exists the possibility that a rogue agent could create errors on the verifier that stopped attestation attempts for that host leaving it in an attested state but not verifying that anymore.</p> https://cve.radiocsirt.org/vuln/cve-2022-3500 https://cve.radiocsirt.org/vuln/ghsa-hff2-x2j9-gxgv <p><strong>Affected:</strong> PyPI: keylime</p> <p>### Impact</p> <p>This vulnerability creates a false sense of security for keylime users -- i.e. a user could query keylime and conclude that a parcitular node/agent is correctly attested, while attestations are not in fact taking place.</p> <p>**Short explanation**: the keylime verifier creates periodic reports on the state of each attested agent. The keylime verifier runs a set of python asynchronous processes to challenge attested nodes and create reports on the outcome.</p> <p>The vulnerability consists of the above named python asynchronous processes failing silently, i.e. quitting without leaving behind a database entry, raising an error or producing even a mention of an error in a log. The silent failure can be triggered by a small set of transient network failure conditions; recoverable device driver crashes being one such condition we saw in the wild.</p> <p>### Patches</p> <p>The problem is fixed in keylime starting with tag 6.5.1</p> <p>### Workarounds</p> <p>This [patch](https://github.com/keylime/keylime/pull/1128/files) can be retroactively applied to any running keylime deployment. Only running verifiers need to be patched. After the patch is applied, the keylime verifier needs to be restarted.</p> <p>### References</p> <p>The problem, as well as the proposed fix, are described in detail [here](https://github.com/keylime/keylime/pull/1128). Further details about the system where the bug was found, and the conditions in which the bug was found, are available from @galmasi on demand.</p> <p>### For more information</p> <p>If…</p> <p><strong>Affected:</strong> PyPI: keylime</p> <p>### Impact</p> <p>This vulnerability creates a false sense of security for keylime users -- i.e. a user could query keylime and conclude that a parcitular node/agent is correctly attested, while attestations are not in fact taking place.</p> <p>**Short explanation**: the keylime verifier creates periodic reports on the state of each attested agent. The keylime verifier runs a set of python asynchronous processes to challenge attested nodes and create reports on the outcome.</p> <p>The vulnerability consists of the above named python asynchronous processes failing silently, i.e. quitting without leaving behind a database entry, raising an error or producing even a mention of an error in a log. The silent failure can be triggered by a small set of transient network failure conditions; recoverable device driver crashes being one such condition we saw in the wild.</p> <p>### Patches</p> <p>The problem is fixed in keylime starting with tag 6.5.1</p> <p>### Workarounds</p> <p>This [patch](https://github.com/keylime/keylime/pull/1128/files) can be retroactively applied to any running keylime deployment. Only running verifiers need to be patched. After the patch is applied, the keylime verifier needs to be restarted.</p> <p>### References</p> <p>The problem, as well as the proposed fix, are described in detail [here](https://github.com/keylime/keylime/pull/1128). Further details about the system where the bug was found, and the conditions in which the bug was found, are available from @galmasi on demand.</p> <p>### For more information</p> <p>If…</p> https://cve.radiocsirt.org/vuln/ghsa-hff2-x2j9-gxgv