InsForge: OAuth account takeover via unverified email
InsForge backend - OAuth sign-in auto-links identities by email without verification, enabling silent account takeover (GHSA-2xrr-5x8x-fchx)
Unpatched. Reported privately via GitHub Security Advisory on 2026-07-10; the 90-day coordinated-disclosure window expired on 2026-10-30 with no response from the maintainer.
- Product
- InsForge (backend OAuth service) in InsForge/InsForge
- Affected versions
- InsForge through v2.3.3 and main (checked at HEAD 21ce31d).
- Severity
- HIGH
- Status
- Unpatched
- Weaknesses
- CWE-287Improper Authentication
- CWE-290Authentication Bypass by Spoofing
- GitHub advisory
- GHSA-2xrr-5x8x-fchx
Private; in triage, not yet published by the maintainer - CVE
- Pending (requested via MITRE CNA-LR)
- Published
- Credit
- Finder: Aaron Elijah Mars of Aeon. Tool: Aeon (https://www.aeon.fun).
What operators should do now
No upstream patch is available yet. Self-hosted InsForge operators should apply a mitigation or disable affected third-party OAuth providers until an official fix is released.
- Disable OAuth providers that allow unverified email claims (such as Discord) in your InsForge authentication settings if password sign-in is also enabled.
- If modifying self-hosted code, patch
backend/src/services/auth/auth.service.tssofindOrCreateThirdPartyUseronly links to an existing account when the provider identity explicitly assertsemail_verified: true. - Do not automatically mark
email_verified = trueon pre-existing local accounts during third-party OAuth linking unless ownership was verified by the provider.
Impact and reach
Any local user account created with email and password, or created via another verified provider, can be taken over by an attacker who registers that same email address on a third-party OAuth provider where email verification is not strictly enforced.
Upon completing the OAuth flow, the backend links the attacker's third-party identity to the victim's local account row in auth.users, flips email_verified = true, and issues a valid authenticated access token for the victim. The takeover requires no victim interaction and leaves no indication in the user interface. A working exploit is withheld.
How unverified email linking works
In backend/src/services/auth/auth.service.ts, findOrCreateThirdPartyUser checks whether a user already exists with the normalized email returned by the OAuth provider. If found, it inserts a link into auth.user_providers and issues an access token immediately:
- Finding by email and auto-linking: backend/src/services/auth/auth.service.ts#L925-L945
- Marking email verified and issuing token: backend/src/services/auth/auth.service.ts#L946-L960
- Discord adapter extracts email without checking verification status: backend/src/providers/oauth/discord.provider.ts#L156-L163
- GitHub adapter falls back to unverified primary or list emails: backend/src/providers/oauth/github.provider.ts#L154-L164
Disclosure timeline
- Vulnerability reported privately via GitHub Security Advisory (GHSA-2xrr-5x8x-fchx).
- First follow-up comment posted on the advisory (33 days in triage).
- Second follow-up comment posted on the advisory (7 weeks in triage).
- Third follow-up comment posted on the advisory (69 days in triage).
- Coordinated-disclosure notice posted on the advisory, setting a 21-day deadline to 2026-10-30.
- Coordinated-disclosure deadline expired with no response from the maintainer; sink verified still present at HEAD 21ce31d.
- Public advisory published; CVE requested via MITRE CNA-LR.
References
- Affected repository: InsForge/InsForge
- GitHub Security Advisory: GHSA-2xrr-5x8x-fchx (private; in triage)