GHSA-x6fw-778m-wr9v
GHSA-x6fw-778m-wr9v is a Improper Authentication vulnerability in parse-server. O3 Security confirms whether GHSA-x6fw-778m-wr9v is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Parse Server: JWT audience validation bypass in Google, Apple, and Facebook authentication adapters
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
parse-servernpmDescription
Impact
The Google, Apple, and Facebook authentication adapters use JWT verification to validate identity tokens. When the adapter's audience configuration option is not set (clientId for Google/Apple, appIds for Facebook), JWT verification silently skips audience claim validation. This allows an attacker to use a validly signed JWT issued for a different application to authenticate as any user on the target Parse Server.
- For Google and Apple, the vulnerability is exploitable when the server does not configure
clientId. The adapters accepted this as valid and simply skipped audience validation. - For Facebook Limited Login, the vulnerability exists regardless of configuration. The adapter validated
appIdsonly for Standard Login (Graph API), but the Limited Login JWT path never passedappIdsas the audience to JWT verification.
Patches
The fix enforces clientId (Google/Apple) and appIds (Facebook) as mandatory and passes them to JWT verification for audience validation. While this is technically a breaking change for servers that omit these options, it is not a breaking change as per documentation — all three options are documented as required configuration.
Workarounds
- Google / Apple: Ensure
clientIdis set in the adapter configuration. When set, JWT verification correctly validates the audience claim even on unpatched versions. - Facebook Limited Login: There is no workaround. The unpatched adapter does not pass
appIdsto JWT audience validation, so the only mitigation is to upgrade.
References
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-x6fw-778m-wr9v
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.11
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.10
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | parse-server | ≥ 9.0.0-alpha.1&&< 9.5.0-alpha.11 | 9.5.0-alpha.11 |
| 📦npm | parse-server | all versions | 8.6.10 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for parse-server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update parse-server to 9.5.0-alpha.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x6fw-778m-wr9v is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-x6fw-778m-wr9v is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-x6fw-778m-wr9v. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-x6fw-778m-wr9v in your dependencies?
O3 detects GHSA-x6fw-778m-wr9v across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.