CWE-287
DiscouragedImproper Authentication
Abstraction: Class · Status: Draft
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
5977 vulnerabilities reference this CWE, most recent first.
GHSA-FMH4-WCC4-5JM3
Vulnerability from github – Published: 2026-07-07 20:54 – Updated: 2026-07-07 20:54Am I affected?
Users are affected if all of the following are true:
- Their application uses
better-authwith theorganizationplugin (import { organization } from "better-auth/plugins/organization"). - Their application enables a sign-up surface that allows arbitrary unverified email registration. Most commonly
emailAndPassword: { enabled: true }withoutrequireEmailVerification: true. - Their application has not set
requireEmailVerificationOnInvitation: trueon theorganization()options. - Their application invitation distribution flow allows anyone other than the invited mailbox owner to obtain the
invitationId. Examples: admin UI surfacing the link, copy-paste into chat, forwarded email, mail-forwarding rules at the recipient's domain, link previews logging the URL, or a customsendInvitationEmailintegration that sends to a non-owner channel.
If their application set emailAndPassword: { enabled: true, requireEmailVerification: true } so unverified rows cannot reach a usable session, they are not affected. Setting requireEmailVerificationOnInvitation: true closes acceptInvitation and rejectInvitation, but getInvitation and listUserInvitations remain ungated even with that flag.
Fix:
- Upgrade to
better-auth@1.6.11or later. - If developers cannot upgrade their application, see workarounds below.
Summary
The organization plugin's acceptInvitation endpoint trusts an email-string equality check as proof that the session user owns the invited address. With Better Auth's stock emailAndPassword: { enabled: true } configuration, requireEmailVerification defaults to false, so an attacker can sign up a row keyed to victim@target.example (auto-signed-in, emailVerified: false) before the legitimate owner. When an organization admin invites that address, the attacker presents the invitationId and accepts the invitation, joining the organization at the invited role.
Details
The recipient gate compares invitation.email.toLowerCase() to session.user.email.toLowerCase() and returns 403 on mismatch. The opt-in requireEmailVerificationOnInvitation flag adds an emailVerified check, but it defaults to false and only fires on acceptInvitation and rejectInvitation; getInvitation and listUserInvitations have no emailVerified gate at all.
The bearer token (invitationId) is by default 32 chars over [a-zA-Z0-9] (~190 bits), so the realistic attack vector is leakage of the invitation link rather than brute force.
The fix shape defaults the emailVerified gate to on and extends it across all four invitation endpoints (acceptInvitation, rejectInvitation, getInvitation, listUserInvitations). This is the same trust-primitive class as GHSA-g38m-r43w-p2q7 (OAuth auto-link); both ship the rule "email equality is not ownership proof; both sides must prove ownership".
Patches
Fixed in better-auth@1.6.11. All four invitation recipient endpoints (acceptInvitation, rejectInvitation, getInvitation, listUserInvitations) now require the session user's emailVerified to be true in addition to the email-string match. The requireEmailVerificationOnInvitation option default flips from false to true, so applications are secure out of the box.
getInvitation and listUserInvitations use the new EMAIL_VERIFICATION_REQUIRED_FOR_INVITATION error code so the wording matches the operation; acceptInvitation and rejectInvitation keep the existing EMAIL_VERIFICATION_REQUIRED_BEFORE_ACCEPTING_OR_REJECTING_INVITATION code. Server-side calls to listUserInvitations that pass ctx.query.email without an authenticated session continue to bypass the gate; the gate is specific to session-authenticated recipient calls.
Integrators who intentionally accept invitations on unverified sessions can preserve the legacy permissive behavior with organization({ requireEmailVerificationOnInvitation: false }). The option is marked @deprecated; the gate at each call site carries a FIXME pointing at the next-minor follow-up that drops the option and makes the check unconditional. Operators that take this opt-out should understand the takeover risk before doing so.
Workarounds
If developers cannot upgrade their applications immediately:
- Set
organization({ requireEmailVerificationOnInvitation: true }). ClosesacceptInvitationandrejectInvitationagainst unverified sessions. Does not closegetInvitationorlistUserInvitations. - Set
emailAndPassword.requireEmailVerification: true(or remove email/password sign-up entirely). Closes the pre-registration step itself. - Layer middleware on the organization invitation routes that asserts
session.user.emailVerified === trueand rejects otherwise.
Impact
- Account takeover via pre-account hijacking on the org invitation surface: the attacker, holding only an unverified self-issued session and the leaked
invitationId, joins the organization as a member at the invited role. - Organization membership reach: the attacker reads invitation contents and any organization-scoped data the joined role can see, and acts as a member of the victim organization.
Credit
Reported by @widavies.
Resources
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "better-auth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53514"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-345",
"CWE-441",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-07T20:54:51Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- Their application uses `better-auth` with the `organization` plugin (`import { organization } from \"better-auth/plugins/organization\"`).\n- Their application enables a sign-up surface that allows arbitrary unverified email registration. Most commonly `emailAndPassword: { enabled: true }` without `requireEmailVerification: true`.\n- Their application has not set `requireEmailVerificationOnInvitation: true` on the `organization()` options.\n- Their application invitation distribution flow allows anyone other than the invited mailbox owner to obtain the `invitationId`. Examples: admin UI surfacing the link, copy-paste into chat, forwarded email, mail-forwarding rules at the recipient\u0027s domain, link previews logging the URL, or a custom `sendInvitationEmail` integration that sends to a non-owner channel.\n\nIf their application set `emailAndPassword: { enabled: true, requireEmailVerification: true }` so unverified rows cannot reach a usable session, they are not affected. Setting `requireEmailVerificationOnInvitation: true` closes `acceptInvitation` and `rejectInvitation`, but `getInvitation` and `listUserInvitations` remain ungated even with that flag.\n\nFix:\n\n1. Upgrade to `better-auth@1.6.11` or later.\n2. If developers cannot upgrade their application, see workarounds below.\n\n### Summary\n\nThe organization plugin\u0027s `acceptInvitation` endpoint trusts an email-string equality check as proof that the session user owns the invited address. With Better Auth\u0027s stock `emailAndPassword: { enabled: true }` configuration, `requireEmailVerification` defaults to `false`, so an attacker can sign up a row keyed to `victim@target.example` (auto-signed-in, `emailVerified: false`) before the legitimate owner. When an organization admin invites that address, the attacker presents the `invitationId` and accepts the invitation, joining the organization at the invited role.\n\n### Details\n\nThe recipient gate compares `invitation.email.toLowerCase()` to `session.user.email.toLowerCase()` and returns 403 on mismatch. The opt-in `requireEmailVerificationOnInvitation` flag adds an `emailVerified` check, but it defaults to `false` and only fires on `acceptInvitation` and `rejectInvitation`; `getInvitation` and `listUserInvitations` have no `emailVerified` gate at all.\n\nThe bearer token (`invitationId`) is by default 32 chars over `[a-zA-Z0-9]` (~190 bits), so the realistic attack vector is leakage of the invitation link rather than brute force.\n\nThe fix shape defaults the `emailVerified` gate to on and extends it across all four invitation endpoints (`acceptInvitation`, `rejectInvitation`, `getInvitation`, `listUserInvitations`). This is the same trust-primitive class as GHSA-g38m-r43w-p2q7 (OAuth auto-link); both ship the rule \"email equality is not ownership proof; both sides must prove ownership\".\n\n### Patches\n\nFixed in `better-auth@1.6.11`. All four invitation recipient endpoints (`acceptInvitation`, `rejectInvitation`, `getInvitation`, `listUserInvitations`) now require the session user\u0027s `emailVerified` to be `true` in addition to the email-string match. The `requireEmailVerificationOnInvitation` option default flips from `false` to `true`, so applications are secure out of the box.\n\n`getInvitation` and `listUserInvitations` use the new `EMAIL_VERIFICATION_REQUIRED_FOR_INVITATION` error code so the wording matches the operation; `acceptInvitation` and `rejectInvitation` keep the existing `EMAIL_VERIFICATION_REQUIRED_BEFORE_ACCEPTING_OR_REJECTING_INVITATION` code. Server-side calls to `listUserInvitations` that pass `ctx.query.email` without an authenticated session continue to bypass the gate; the gate is specific to session-authenticated recipient calls.\n\nIntegrators who intentionally accept invitations on unverified sessions can preserve the legacy permissive behavior with `organization({ requireEmailVerificationOnInvitation: false })`. The option is marked `@deprecated`; the gate at each call site carries a `FIXME` pointing at the next-minor follow-up that drops the option and makes the check unconditional. Operators that take this opt-out should understand the takeover risk before doing so.\n\n### Workarounds\n\nIf developers cannot upgrade their applications immediately:\n\n- **Set `organization({ requireEmailVerificationOnInvitation: true })`**. Closes `acceptInvitation` and `rejectInvitation` against unverified sessions. Does not close `getInvitation` or `listUserInvitations`.\n- **Set `emailAndPassword.requireEmailVerification: true`** (or remove email/password sign-up entirely). Closes the pre-registration step itself.\n- **Layer middleware** on the organization invitation routes that asserts `session.user.emailVerified === true` and rejects otherwise.\n\n### Impact\n\n- **Account takeover via pre-account hijacking on the org invitation surface**: the attacker, holding only an unverified self-issued session and the leaked `invitationId`, joins the organization as a member at the invited role.\n- **Organization membership reach**: the attacker reads invitation contents and any organization-scoped data the joined role can see, and acts as a member of the victim organization.\n\n### Credit\n\nReported by @widavies.\n\n### Resources\n\n- [CWE-287: Improper Authentication](https://cwe.mitre.org/data/definitions/287.html)\n- [CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)\n- [CWE-862: Missing Authorization](https://cwe.mitre.org/data/definitions/862.html)\n- [CWE-441: Unintended Proxy or Intermediary](https://cwe.mitre.org/data/definitions/441.html)",
"id": "GHSA-fmh4-wcc4-5jm3",
"modified": "2026-07-07T20:54:52Z",
"published": "2026-07-07T20:54:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-fmh4-wcc4-5jm3"
},
{
"type": "PACKAGE",
"url": "https://github.com/better-auth/better-auth"
},
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Better Auth vulnerable to unauthorized invitation acceptance via unverified email match in organization plugin"
}
GHSA-FMPC-XP2H-4H2W
Vulnerability from github – Published: 2024-04-25 21:30 – Updated: 2024-09-07 00:31An issue discovered in Yealink VP59 Teams Editions with firmware version 91.15.0.118 allows a physically proximate attacker to gain control of an account via a flaw in the factory reset procedure.
{
"affected": [],
"aliases": [
"CVE-2024-30939"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-25T19:15:49Z",
"severity": "MODERATE"
},
"details": "An issue discovered in Yealink VP59 Teams Editions with firmware version 91.15.0.118 allows a physically proximate attacker to gain control of an account via a flaw in the factory reset procedure.",
"id": "GHSA-fmpc-xp2h-4h2w",
"modified": "2024-09-07T00:31:28Z",
"published": "2024-04-25T21:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30939"
},
{
"type": "WEB",
"url": "https://medium.com/%40deepsahu1/yealink-ip-phone-account-take-over-9bf9e7b847c0?source=friends_link\u0026sk=b0d664dd5b3aad5b758e4934aca997ad"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FMQM-MV4M-4VH3
Vulnerability from github – Published: 2023-10-03 06:30 – Updated: 2024-04-04 08:02Cryptographic issue in Data Modem due to improper authentication during TLS handshake.
{
"affected": [],
"aliases": [
"CVE-2023-28540"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-03T06:15:24Z",
"severity": "HIGH"
},
"details": "Cryptographic issue in Data Modem due to improper authentication during TLS handshake.",
"id": "GHSA-fmqm-mv4m-4vh3",
"modified": "2024-04-04T08:02:58Z",
"published": "2023-10-03T06:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28540"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/october-2023-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FMW2-JXVH-9JCR
Vulnerability from github – Published: 2022-05-17 05:34 – Updated: 2022-05-17 05:34The HMI web server in Siemens WinCC flexible 2004, 2005, 2007, and 2008 before SP3; WinCC V11 (aka TIA portal) before SP2 Update 1; the TP, OP, MP, Comfort Panels, and Mobile Panels SIMATIC HMI panels; WinCC V11 Runtime Advanced; and WinCC flexible Runtime generates predictable authentication tokens for cookies, which makes it easier for remote attackers to bypass authentication via a crafted cookie.
{
"affected": [],
"aliases": [
"CVE-2011-4508"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-02-03T20:55:00Z",
"severity": "HIGH"
},
"details": "The HMI web server in Siemens WinCC flexible 2004, 2005, 2007, and 2008 before SP3; WinCC V11 (aka TIA portal) before SP2 Update 1; the TP, OP, MP, Comfort Panels, and Mobile Panels SIMATIC HMI panels; WinCC V11 Runtime Advanced; and WinCC flexible Runtime generates predictable authentication tokens for cookies, which makes it easier for remote attackers to bypass authentication via a crafted cookie.",
"id": "GHSA-fmw2-jxvh-9jcr",
"modified": "2022-05-17T05:34:22Z",
"published": "2022-05-17T05:34:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-4508"
},
{
"type": "WEB",
"url": "http://www.siemens.com/corporate-technology/pool/de/forschungsfelder/siemens_security_advisory_ssa-345442.pdf"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/control_systems/pdf/ICSA-12-030-01.pdf"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FMW4-39XW-JJW4
Vulnerability from github – Published: 2023-04-14 15:30 – Updated: 2024-04-04 03:28An issue was discovered in LIVEBOX Collaboration vDesk through v018. A Bypass of Two-Factor Authentication can occur under the /api/v1/vdeskintegration/challenge endpoint. Because only the client-side verifies whether a check was successful, an attacker can modify the response, and fool the application into concluding that the TOTP was correct.
{
"affected": [],
"aliases": [
"CVE-2022-45173"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-14T14:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in LIVEBOX Collaboration vDesk through v018. A Bypass of Two-Factor Authentication can occur under the /api/v1/vdeskintegration/challenge endpoint. Because only the client-side verifies whether a check was successful, an attacker can modify the response, and fool the application into concluding that the TOTP was correct.",
"id": "GHSA-fmw4-39xw-jjw4",
"modified": "2024-04-04T03:28:28Z",
"published": "2023-04-14T15:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45173"
},
{
"type": "WEB",
"url": "https://www.gruppotim.it/it/footer/red-team.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FP38-37P3-QJ24
Vulnerability from github – Published: 2025-07-25 00:30 – Updated: 2025-10-09 21:31HCL IEM is affected by an improper invalidation of access or JWT token vulnerability. A token was not invalidated which may allow attackers to access sensitive data without authorization.
{
"affected": [],
"aliases": [
"CVE-2025-0249"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T00:15:24Z",
"severity": "LOW"
},
"details": "HCL IEM is affected by an improper invalidation of access or JWT token vulnerability.\u00a0 A token was not invalidated which may allow attackers to access sensitive data without authorization.",
"id": "GHSA-fp38-37p3-qj24",
"modified": "2025-10-09T21:31:08Z",
"published": "2025-07-25T00:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0249"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0122368"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FP4Q-HRV9-R6F5
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-05-24 19:06VMware Carbon Black App Control 8.0, 8.1, 8.5 prior to 8.5.8, and 8.6 prior to 8.6.2 has an authentication bypass. A malicious actor with network access to the VMware Carbon Black App Control management server might be able to obtain administrative access to the product without the need to authenticate.
{
"affected": [],
"aliases": [
"CVE-2021-21998"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-23T12:15:00Z",
"severity": "CRITICAL"
},
"details": "VMware Carbon Black App Control 8.0, 8.1, 8.5 prior to 8.5.8, and 8.6 prior to 8.6.2 has an authentication bypass. A malicious actor with network access to the VMware Carbon Black App Control management server might be able to obtain administrative access to the product without the need to authenticate.",
"id": "GHSA-fp4q-hrv9-r6f5",
"modified": "2022-05-24T19:06:01Z",
"published": "2022-05-24T19:06:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21998"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2021-0012.html?"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FP5G-RGJQ-C9MX
Vulnerability from github – Published: 2026-01-14 15:33 – Updated: 2026-02-02 18:31The vulnerability exists in BLUVOYIX due to improper authentication in the BLUVOYIX backend APIs. An unauthenticated remote attacker could exploit this vulnerability by sending specially crafted HTTP requests to the vulnerable APIs. Successful exploitation of this vulnerability could allow the attacker to gain full access to customers' data and completely compromise the targeted platform.
{
"affected": [],
"aliases": [
"CVE-2026-22236"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-14T15:16:04Z",
"severity": "CRITICAL"
},
"details": "The vulnerability exists in BLUVOYIX due to improper authentication in the BLUVOYIX backend APIs. An unauthenticated remote attacker could exploit this vulnerability by sending specially crafted HTTP requests to the vulnerable APIs. Successful exploitation of this vulnerability could allow the attacker to gain full access to customers\u0027 data and completely compromise the targeted platform.",
"id": "GHSA-fp5g-rgjq-c9mx",
"modified": "2026-02-02T18:31:29Z",
"published": "2026-01-14T15:33:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22236"
},
{
"type": "WEB",
"url": "https://blusparkglobal.com/bluvoyix"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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:M/U:Red",
"type": "CVSS_V4"
}
]
}
GHSA-FPFR-6QQP-32GM
Vulnerability from github – Published: 2023-09-12 18:30 – Updated: 2024-04-04 07:37The JMX Console within the Rockwell Automation Pavilion8 is exposed to application users and does not require authentication. If exploited, a malicious user could potentially retrieve other application users’ session data and or log users out of their session.
{
"affected": [],
"aliases": [
"CVE-2023-29463"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-12T17:15:09Z",
"severity": "MODERATE"
},
"details": "\nThe JMX Console within the Rockwell Automation Pavilion8 is exposed to application users and does not require authentication. If exploited, a malicious user could potentially retrieve other application users\u2019 session data and or log users out of their session.\n\n",
"id": "GHSA-fpfr-6qqp-32gm",
"modified": "2024-04-04T07:37:19Z",
"published": "2023-09-12T18:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29463"
},
{
"type": "WEB",
"url": "https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1140590"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FPGF-PJJV-2QGM
Vulnerability from github – Published: 2022-09-30 04:37 – Updated: 2022-09-30 04:37Impact
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. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device.
These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm.
Patches
matrix-android-sdk2 has been modified to only accept Olm-encrypted to-device messages and to stop signing backups on a successful decryption.
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 using verify with passphrase.
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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.4.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.matrix.android:matrix-android-sdk2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-39248"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-322"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T04:37:39Z",
"nvd_published_at": "2022-09-28T20:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\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. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device.\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-android-sdk2 has been modified to only accept Olm-encrypted to-device messages and to stop signing backups on a successful decryption.\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\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 using verify with passphrase.\n\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-fpgf-pjjv-2qgm",
"modified": "2022-09-30T04:37:39Z",
"published": "2022-09-30T04:37:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-android-sdk2/security/advisories/GHSA-fpgf-pjjv-2qgm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39248"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-android-sdk2/commit/77df720a238d17308deab83ecaa37f7a4740a17e"
},
{
"type": "PACKAGE",
"url": "https://github.com/matrix-org/matrix-android-sdk2"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-android-sdk2/releases/tag/v1.5.1"
},
{
"type": "WEB",
"url": "https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients"
}
],
"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-android-sdk2 vulnerable to Olm/Megolm protocol confusion"
}
Mitigation
Strategy: Libraries or Frameworks
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CAPEC-114: Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.
CAPEC-115: Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
CAPEC-151: Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.
CAPEC-194: Fake the Source of Data
An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-593: Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.
CAPEC-633: Token Impersonation
An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.
CAPEC-650: Upload a Web Shell to a Web Server
By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.