Security

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)

PUBLISHED SEVERITY HIGHSTATUS UnpatchedGHSA-2xrr-5x8x-fchx
Unpatched

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
CWE-287 and CWE-290 as filed on GHSA-2xrr-5x8x-fchx.
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.

  1. Disable OAuth providers that allow unverified email claims (such as Discord) in your InsForge authentication settings if password sign-in is also enabled.
  2. If modifying self-hosted code, patch backend/src/services/auth/auth.service.ts so findOrCreateThirdPartyUser only links to an existing account when the provider identity explicitly asserts email_verified: true.
  3. Do not automatically mark email_verified = true on 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:

Disclosure timeline

  1. Vulnerability reported privately via GitHub Security Advisory (GHSA-2xrr-5x8x-fchx).
  2. First follow-up comment posted on the advisory (33 days in triage).
  3. Second follow-up comment posted on the advisory (7 weeks in triage).
  4. Third follow-up comment posted on the advisory (69 days in triage).
  5. Coordinated-disclosure notice posted on the advisory, setting a 21-day deadline to 2026-10-30.
  6. Coordinated-disclosure deadline expired with no response from the maintainer; sink verified still present at HEAD 21ce31d.
  7. Public advisory published; CVE requested via MITRE CNA-LR.

References

  • Affected repository: InsForge/InsForge
  • GitHub Security Advisory: GHSA-2xrr-5x8x-fchx (private; in triage)