CWE-322
AllowedKey Exchange without Entity Authentication
Abstraction: Base · Status: Draft
The product performs a key exchange with an actor without verifying the identity of that actor.
44 vulnerabilities reference this CWE, most recent first.
GHSA-R48R-J8FX-MQ2C
Vulnerability from github – Published: 2022-09-30 00:41 – Updated: 2022-10-03 19:46Impact
An attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield.
Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver.
These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm.
Patches
matrix-js-sdk has been modified to only accept Olm-encrypted to-device messages.
Out of caution, several other checks have been audited or added:
- Cleartext m.room_key, m.forwarded_room_key and m.secret.send to_device messages are discarded.
- Secrets received from untrusted devices are discarded.
- Key backups are only usable if they have a valid signature from a trusted device (no more local trust, or trust-on-decrypt).
- The origin of a to-device message should only be determined by observing the Olm session which managed to decrypt the message, and not by using claimed sender_key, user_id, or any other fields controllable by the homeserver.
Workarounds
As this attack requires coordination between a malicious home server and an attacker, if you trust your home server no particular workaround is needed. Notice that the backup spoofing attack is a particularly sophisticated targeted attack.
We are not aware of this attack being used in the wild, though specifying a false positive-free way of noticing malicious key backups key is challenging.
As an abundance of caution, to avoid malicious backup attacks, you should not verify your new logins using emoji/QR verifications methods until patched. Prefer verifying with your security passphrase instead.
References
Blog post: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients
For more information
If you have any questions or comments about this advisory, e-mail us at security@matrix.org.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "matrix-js-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "19.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-39251"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-322"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T00:41:24Z",
"nvd_published_at": "2022-09-28T20:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nAn attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield.\n\nAdditionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver.\n\nThese attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm.\n\n### Patches\n\nmatrix-js-sdk has been modified to only accept Olm-encrypted to-device messages.\n\nOut of caution, several other checks have been audited or added:\n- Cleartext `m.room_key`, `m.forwarded_room_key` and `m.secret.send` to_device messages are discarded.\n- Secrets received from untrusted devices are discarded.\n- Key backups are only usable if they have a valid signature from a trusted device (no more local trust, or trust-on-decrypt).\n- The origin of a to-device message should only be determined by observing the Olm session which managed to decrypt the message, and not by using claimed sender_key, user_id, or any other fields controllable by the homeserver.\n\n### Workarounds\n\nAs this attack requires coordination between a malicious home server and an attacker, if you trust your home server no particular workaround is needed. Notice that the backup spoofing attack is a particularly sophisticated targeted attack.\n\nWe are not aware of this attack being used in the wild, though specifying a false positive-free way of noticing malicious key backups key is challenging.\n\nAs an abundance of caution, to avoid malicious backup attacks, you should not verify your new logins using emoji/QR verifications methods until patched. Prefer verifying with your security passphrase instead.\n\n### References\nBlog post: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients\n\n### For more information\nIf you have any questions or comments about this advisory, e-mail us at [security@matrix.org](mailto:security@matrix.org).\n",
"id": "GHSA-r48r-j8fx-mq2c",
"modified": "2022-10-03T19:46:42Z",
"published": "2022-09-30T00:41:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-r48r-j8fx-mq2c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39251"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-js-sdk/commit/a587d7c36026fe1fcf93dfff63588abee359be76"
},
{
"type": "PACKAGE",
"url": "https://github.com/matrix-org/matrix-js-sdk"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-js-sdk/releases/tag/v19.7.0"
},
{
"type": "WEB",
"url": "https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202210-35"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "matrix-js-sdk subject to user spoofing via Olm/Megolm protocol confusion"
}
GHSA-RWXW-P86H-G9Q6
Vulnerability from github – Published: 2024-09-09 12:31 – Updated: 2024-09-09 15:30Improper host key checking in active check 'Check SFTP Service' and special agent 'VNX quotas and filesystem' in Checkmk before Checkmk 2.3.0p15, 2.2.0p33, 2.1.0p48 and 2.0.0 (EOL) allows man-in-the-middle attackers to intercept traffic
{
"affected": [],
"aliases": [
"CVE-2024-6572"
],
"database_specific": {
"cwe_ids": [
"CWE-322"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-09T10:15:01Z",
"severity": "MODERATE"
},
"details": "Improper host key checking in active check \u0027Check SFTP Service\u0027 and special agent \u0027VNX quotas and filesystem\u0027 in Checkmk before Checkmk 2.3.0p15, 2.2.0p33, 2.1.0p48 and 2.0.0 (EOL) allows man-in-the-middle attackers to intercept traffic",
"id": "GHSA-rwxw-p86h-g9q6",
"modified": "2024-09-09T15:30:40Z",
"published": "2024-09-09T12:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6572"
},
{
"type": "WEB",
"url": "https://checkmk.com/werk/17148"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-VW6G-9HPF-V3CQ
Vulnerability from github – Published: 2026-07-13 18:30 – Updated: 2026-07-14 03:31The Apache Airflow Git provider runs its git-over-SSH operations with StrictHostKeyChecking=no by default, disabling SSH host-key verification. An attacker who can intercept the network path between an Airflow worker and the Git server can impersonate the server (man-in-the-middle), capturing the SSH deploy key or injecting malicious repository content. Deployments that use the Git DAG bundle or Git provider to clone over SSH with a deploy key are affected. The fix changes the default to verify host keys; upgrade to apache-airflow-providers-git 0.4.1 or later and configure a known_hosts file.
{
"affected": [],
"aliases": [
"CVE-2026-58065"
],
"database_specific": {
"cwe_ids": [
"CWE-322"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-13T16:16:41Z",
"severity": "HIGH"
},
"details": "The Apache Airflow Git provider runs its git-over-SSH operations with `StrictHostKeyChecking=no` by default, disabling SSH host-key verification. An attacker who can intercept the network path between an Airflow worker and the Git server can impersonate the server (man-in-the-middle), capturing the SSH deploy key or injecting malicious repository content. Deployments that use the Git DAG bundle or Git provider to clone over SSH with a deploy key are affected. The fix changes the default to verify host keys; upgrade to apache-airflow-providers-git `0.4.1` or later and configure a `known_hosts` file.",
"id": "GHSA-vw6g-9hpf-v3cq",
"modified": "2026-07-14T03:31:34Z",
"published": "2026-07-13T18:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58065"
},
{
"type": "WEB",
"url": "https://github.com/apache/airflow/pull/69103"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/fjmclngfksz2kp7llpcjxzdz568h0zhc"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/13/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W4PR-4VJG-HFFH
Vulnerability from github – Published: 2022-09-30 22:56 – Updated: 2022-09-30 22:56When matrix-nio before 0.20 requests a room key from our devices, it correctly accepts key forwards only if they are a response to a previous request. However, it doesn't check that the device that responded matches the device the key was requested from.
This allows a malicious homeserver to insert room keys of questionable validity into the key store in some situations, potentially assisting in an impersonation attack.
For more information
If you have any questions or comments about this advisory, e-mail us at poljar@termina.org.uk.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "matrix-nio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-39254"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-322"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T22:56:17Z",
"nvd_published_at": "2022-09-29T15:15:00Z",
"severity": "HIGH"
},
"details": "When matrix-nio before 0.20 requests a room key from our devices, it correctly accepts key forwards only if they are a response to a previous request. However, it doesn\u0027t check that the device that responded matches the device the key was requested from.\n\nThis allows a malicious homeserver to insert room keys of questionable validity into the key store in some situations, potentially assisting in an impersonation attack.\n\n### For more information\nIf you have any questions or comments about this advisory, e-mail us at [poljar@termina.org.uk](mailto:poljar@termina.org.uk).",
"id": "GHSA-w4pr-4vjg-hffh",
"modified": "2022-09-30T22:56:17Z",
"published": "2022-09-30T22:56:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/poljar/matrix-nio/security/advisories/GHSA-w4pr-4vjg-hffh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39254"
},
{
"type": "WEB",
"url": "https://github.com/poljar/matrix-nio/commit/b1cbf234a831daa160673defd596e6450e9c29f0"
},
{
"type": "PACKAGE",
"url": "https://github.com/poljar/matrix-nio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "When matrix-nio receives forwarded room keys, the receiver doesn\u0027t check if it requested the key from the forwarder"
}
Mitigation
Ensure that proper authentication is included in the system design.
Mitigation
Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.
No CAPEC attack patterns related to this CWE.