GHSA-8x3w-qj7j-gqhf: Openmls Openmls Has Improper Tag Validation Vulnerability

HIGH
CWE-754
Published
Advisory Summary

GHSA-8x3w-qj7j-gqhf is a HIGH openmls has improper tag validation vulnerability (CWE-754: Improper Check for Unusual or Exceptional Conditions) affecting Openmls libraries in the crates.io ecosystem. The issue involves openmls has improper tag validation. Remediation is available by upgrading affected packages to version 0.7.2.

GHSA-8x3w-qj7j-gqhf at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-8x3w-qj7j-gqhf
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-754: Improper Check for Unusual or Exceptional Conditions
Affected Product Openmls
Package Ecosystem crates.io
Published Date
Last Updated

How to Fix GHSA-8x3w-qj7j-gqhf

To remediate this vulnerability, upgrade all affected Openmls dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

openmls fixed: 0.7.2
Upgrade openmls to 0.7.2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for openmls

How to Check if You Are Affected

To determine whether your application is affected by GHSA-8x3w-qj7j-gqhf, inspect your project dependencies for Openmls:

inspect dependencies for openmls

Analyze the terminal output to locate any version of Openmls in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.7.2), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-754: Improper Check for Unusual or Exceptional Conditions, where the product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product. In Openmls, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

Membership and confirmation tags may not be checked correctly due to a missing length check. Any tag that is shorter than the expected tag, but matches up to its length, as well as any empty tag is considered valid. ### Impact The vulnerability affects a secondary authentication guarantee that MLS provides in certain scenarios. The primary authentication guarantee for all messages comes from the signature on MLS messages. This guarantee is *not* affected by the vulnerability. The secondary authentication attests to the group membership of the message author. For MLS private messages, it is implied in the AEAD. For MLS public messages, it is expressed as the ‘membership tag’, a MAC whose key is derived from the private group state only known to group members. In addition, for public Commit messages, the ‘confirmation tag’ works in a similar manner. Its purpose is to help members who processed the Commit message to ascertain that they now have the same view on the group as the creator of the Commit message for both the private and public group state. The vulnerability lets an attacker create MLS messages with a truncated tag that are considered valid nonetheless. The vulnerability does not affect the primary authentication guarantees of MLS, but breaks post-compromise security (PCS) of the MLS authentication guarantees. As a consequence, an adversary that has compromised a member’s signature key can create valid-looking proposals even after the affected member has successfully updated its key material. However, this is only possible in applications where the following conditions are met: - The application uses public MLS messages (i.e. it has not restricted the wire format type to private MLS messages only), and - the application supports proposals by reference (aka standalone proposals). Note that, in deployments that allow external Commits, an attacker in possession of a member’s signature key can insert itself into the group without having to forge a membership tag. ### Patches There are two ways to mitigate the issue: - Upgrade to openmls v0.7.2: This minor release includes a fix for the issue and bumps the libcrux dependencies. This release does not contain any breaking changes from v0.7.1. - Upgrade to openmls v0.8.0: This release contains the fix, as well as other improvements. The list of changes is in [CHANGELOG.md](https://github.com/openmls/openmls/blob/main/CHANGELOG.md). Some of the changes are breaking API changes.

GHSA-8x3w-qj7j-gqhf Affected Openmls Versions

1 component(s)
Fixed Versions:
0.7.2
Product / Package Ecosystem Affected Versions Fixed Version
openmls
crates.io
< 0.7.2
0.7.2

References

Frequently Asked Questions

What is GHSA-8x3w-qj7j-gqhf?
GHSA-8x3w-qj7j-gqhf is a security vulnerability in Openmls involving openmls has improper tag validation under CWE-754: Improper Check for Unusual or Exceptional Conditions.
Which Openmls versions are affected?
Affected versions include releases prior to 0.7.2 across affected packages: openmls.
What version fixes GHSA-8x3w-qj7j-gqhf?
Upgrading to 0.7.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is openmls affected?
Yes, openmls is affected in releases prior to 0.7.2. Upgrade your dependency to 0.7.2 or later.
What CWE is associated with GHSA-8x3w-qj7j-gqhf?
GHSA-8x3w-qj7j-gqhf is classified under CWE-754: Improper Check for Unusual or Exceptional Conditions (The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.).
How can I check crates.io dependencies for GHSA-8x3w-qj7j-gqhf?
Run the dependency tree command: 'inspect dependencies for openmls'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-8x3w-qj7j-gqhf",
  "modified" : "2026-02-04T20:24:03Z",
  "published" : "2026-02-04T20:24:03Z",
  "aliases" : [ ],
  "summary" : "openmls has improper tag validation",
  "details" : "Membership and confirmation tags may not be checked correctly due to a missing length check. Any tag that is shorter than the expected tag, but matches up to its length, as well as any empty tag is considered valid.\n\n### Impact\n\nThe vulnerability affects a secondary authentication guarantee that MLS provides in certain scenarios. The primary authentication guarantee for all messages comes from the signature on MLS messages. This guarantee is *not* affected by the vulnerability.  \nThe secondary authentication attests to the group membership of the message author. For MLS private messages, it is implied in the AEAD. For MLS public messages, it is expressed as the ‘membership tag’, a MAC whose key is derived from the private group state only known to group members.\n\nIn addition, for public Commit messages, the ‘confirmation tag’ works in a similar manner. Its purpose is to help members who processed the Commit message to ascertain that they now have the same view on the group as the creator of the Commit message for both the private and public group state. \n\nThe vulnerability lets an attacker create MLS messages with a truncated tag that are considered valid nonetheless.\n\nThe vulnerability does not affect the primary authentication guarantees of MLS, but breaks post-compromise security (PCS) of the MLS authentication guarantees. As a consequence, an adversary that has compromised a member’s signature key can create valid-looking proposals even after the affected member has successfully updated its key material. However, this is only possible in applications where the following conditions are met:\n\n- The application uses public MLS messages (i.e. it has not restricted the wire format type to private MLS messages only), and  \n- the application supports proposals by reference (aka standalone proposals).\n\nNote that, in deployments that allow external Commits, an attacker in possession of a member’s signature key can insert itself into the group without having to forge a membership tag.\n\n### Patches\n\nThere are two ways to mitigate the issue:\n\n- Upgrade to openmls v0.7.2: This minor release includes a fix for the issue and bumps the libcrux dependencies. This release does not contain any breaking changes from v0.7.1.  \n- Upgrade to openmls v0.8.0: This release contains the fix, as well as other improvements. The list of changes is in [CHANGELOG.md](https://github.com/openmls/openmls/blob/main/CHANGELOG.md). Some of the changes are breaking API changes.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "openmls"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.7.2"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/openmls/openmls/security/advisories/GHSA-8x3w-qj7j-gqhf"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/openmls/openmls/commit/91ec049ffc2fa3766110223aa2aabe0303837af8"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/openmls/openmls"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/openmls/openmls/releases/tag/openmls-v0.7.2"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-754" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-02-04T20:24:03Z",
    "nvd_published_at" : null
  }
}