Advisory · CVE-2026-116163
Parse Server custom AuthAdapter subclasses accept any authData
Parse Server contains an authentication bypass for apps whose custom auth adapter subclasses the exported AuthAdapter class: the subclass validation methods are never called and an inherited default accepts any authData, so attackers can sign up, link identities, or log in as existing users for that provider. CVSS 4.0 9.1.
- Vendor
- Parse Server
- Product
- Parse Server
- Identifier / CWE
- CVE-2026-116163
CWE-287 - Action timing
- Immediate
Explain it like I’m five
Parse Server asks a custom login adapter to check credentials, but for adapters built one particular way it never actually calls the check and waves everyone through with whatever they typed.
- 01App uses a subclass adapter
An application configures a custom authentication adapter built as a subclass of the exported AuthAdapter class.
- 02Attacker sends arbitrary authData
The attacker submits sign-up, identity-link, or login data for that provider without valid credentials.
- 03Validation is never called
The subclass validateSetUp, validateLogin, and validateUpdate methods are not invoked; the inherited default runs instead.
- 04Any authData is accepted
The attacker is signed up, linked, or logged in as an existing user, and can skip an extra factor the adapter was meant to enforce.
What happened
Parse Server disclosed CVE-2026-116163 in its GitHub security advisory. A custom authentication adapter that extends the exported AuthAdapter class and implements validateSetUp, validateLogin, and validateUpdate, as the class documentation describes, never had those methods called; Parse Server instead used a default inherited from the base class, which accepts any authentication data. For a provider served by such an adapter, an attacker can sign up, link an identity, or log in as an existing user without valid credentials for that provider, and can skip a custom adapter that implements an additional authentication factor.
The vendor advisory is explicit about scope: only apps that configure a custom authentication adapter built as a subclass of AuthAdapter are affected; built-in adapters and custom adapters defined as plain objects are not affected. Per the affected data in the NVD record, versions before 8.6.102 and the 9.0.0 line before 9.10.5-alpha.2 are affected, with those boundary versions listed as unaffected. The vendor patch makes a subclass validation method actually run and rejects subclasses that implement only some of the validation methods instead of accepting any authData.
What to do
- Determine whether each Parse Server app defines any custom auth adapter as a subclass of AuthAdapter; apps using only built-in adapters or plain-object adapters are outside the vendor-stated scope.
- Upgrade affected servers to a fixed release on your branch, per the vendor advisory and the NVD affected data (8.6.102 on the 8 line).
- If you cannot upgrade immediately, apply the vendor workaround: implement all validation in an overridden validateAuthData method that does not rely on the adapter instance state, or define the adapter as a plain object.
- Audit sign-ups, identity links, and logins through custom-adapter providers for accounts created or accessed without a matching provider-side login.
- Revoke sessions and re-verify linked identities for any account whose provider login cannot be corroborated.
Management note
This is a silent failure of a security control: the code looks like it validates, and the documentation says it validates, but the check never runs. Any app that outsourced an extra factor or a niche identity provider to a subclass adapter should treat its provider login history as untrusted until reviewed.