v3.5.3, 2026-10-13
Highlights
- Validate Google and Facebook direct-login tokens against the application's OAuth configuration, use provider-verified Google identity fields, and keep Facebook verification errors from exposing the app secret.
- Prevent server crashes caused by invalid DDP protocol-handler names and unhandled asynchronous handler rejections.
- Include all modified top-level fields in allow/deny checks, closing a field-authorization bypass.
- Bound dynamic-import request size and complexity, batch large legitimate module graphs, and limit failed module reads and logging.
- Keep
meteor shellhistory and compilation caches private on POSIX systems, and keep the app running when private history persistence is unavailable. - Restrict deploy destinations returned by discovery to trusted HTTPS Galaxy servers before sending account credentials, while preserving HTTP discovery for first deploys.
Breaking Changes
google-oauth: Native sign-in that directly supplies an iOS or Android access token withoutserverAuthCodemust list that client inadditionalClientIds, or supply a Google-validatedidTokenfor an accepted client and the same user. Google email and picture data no longer fall back to client-supplied fields; apps must request the corresponding scopes.dynamic-import: Oversized or malformed requests now receive HTTP 413 or 400. The updated client batches large valid graphs, but already-open clients running older code may need a refresh during a rolling deployment. Individual module paths must fit the new enforced limits.allow-deny: Update validators now receive__proto__in the modified-field list instead of omitting it. Review validators that rely on that list.- Deploy discovery now rejects destinations outside Galaxy's HTTPS deploy domain. Custom deploy servers must be selected explicitly through
DEPLOY_HOSTNAME; that override remains trusted with the account credentials.
Internal API changes
- DDP protocol dispatch accepts only string names for handlers defined directly on the handler table. Extensions that inherit protocol handlers must define them directly.
Migration Steps
Please run the following command to update your project:
meteor update --release 3.5.3- Google sign-in: For native access-token sign-in without
serverAuthCode, setadditionalClientIdsin the server's Google service configuration to your application's iOS and Android OAuth client IDs, or send a matchingidTokenthat Google can validate for an accepted client. Requestemailandprofilescopes if your app needs those fields. Allow outbound access tooauth2.googleapis.comwhen using ID-token validation, alongside the existing Google API endpoints. The standard server authorization-code flow exchanges the code for tokens before validation. - Dynamic imports: Deploy the updated client and server together. If older open clients fail to load a large uncached module graph after the server update, refresh them to load the client that batches requests.
- Allow/deny: Check validators that restrict updates by field name, including applications that intentionally use a top-level
__proto__field. - Meteor shell: If a permissions warning appears, check ownership and permission support for
.meteor/local/shell. The shell continues without persistent history when it cannot ensure privacy, and compilation runs without disk caching when the cache cannot be made private. - Deploy: Review any
DEPLOY_HOSTNAMEoverride and trust its destination before supplying account credentials. Automatic discovery still tries HTTP when HTTPS discovery fails, including first deploys before a site has a certificate; the discovery-selected deploy server must use trusted Galaxy HTTPS.
Bumped Meteor Packages
- allow-deny@2.1.1
- ddp-server@3.4.1
- dynamic-import@0.8.0
- facebook-oauth@1.12.0
- google-oauth@1.5.0
- shell-server@0.7.1
- meteor-tool@3.5.3
Bumped NPM Packages
N/A
Special thanks to
✨✨✨
- @italojs, for implementing and adapting the fixes.
- @Grubba27 and @nachocodoner, for reviewing dynamic-import.
- Vext Labs, for the OAuth vulnerability disclosure.
✨✨✨