GHSA-qr9h-x63w-vqfm: 
Rust vulnerability analysis and mitigation

A vulnerability in OpenMLS library (GHSA-qr9h-x63w-vqfm) was discovered that prevented private key material from being properly updated in storage during message processing. The vulnerability affects versions up to and including 0.7.0, with version 0.7.1 providing the patch. The bug impacts the keys stored in the MLS secret tree, which are used for decryption of private MLS messages, potentially affecting forward secrecy and message decryption capabilities (GitHub Advisory).

The vulnerability's scope is limited to private messages (application and handshake messages) received in groups, confined to one epoch, with effects resetting upon epoch transition. Within each epoch, there is a maximum number of private messages per sender (default 1000) that can be skipped before an error occurs. The bug causes the library to incorrectly indicate that private messages have been processed when they haven't, potentially leading to processing errors. The vulnerability has a CVSS v4.0 score of 4.1 (Moderate), with metrics indicating Local attack vector, High attack complexity, and High privileges required (GitHub Advisory).

The security impact is significant when an adversary gains access to the client's state, though the exploitation risk is relatively low in typical use cases. The vulnerability allows decryption of more messages than intended, up to the maximumforwarddistance additional messages per sender in the current epoch. This compromises forward secrecy, as messages previously considered secure become vulnerable to decryption (GitHub Advisory).

Several mitigation strategies are available: 1) Message encryption secrets are automatically deleted during epoch transitions, securing messages in past epochs if message retention isn't configured. 2) Increasing update/commit frequency helps minimize the compromise window. 3) Creating private messages for each sender of previously received messages using the same MlsGroup object ensures proper key updates. Post-patch security requires either entering the next epoch, advancing sufficient epochs for pre-patch state to exit the retention window, or processing enough messages for pre-patch decrypted messages to fall outside the out-of-order tolerance window (GitHub Advisory).