🔑 MetaSync MCP Server JWT Security: Token Validation, Secret Rotation & Access Hardening

The MetaSync MCP server's JWT validation bypass (WP-285) has been patched. Any site running MetaSync MCP on WordPress should rotate its JWT secret immediately — this invalidates all pre-patch tokens, including any that exploited the bypass.

📌 Scope: This article applies only to the MetaSync MCP server WordPress plugin. If you use the Search Atlas hosted MCP server at mcp.searchatlas.com, this guidance does not apply — refer to the hosted MCP server documentation instead.

⚠️ What the Vulnerability Was and Why It Matters

The MetaSync MCP server's verify_jwt_token() function applied isset() checks to the exp (expiry) and iss (issuer) JWT claims. Because isset() only tests whether a field exists — not whether it holds a valid value — a JWT crafted without those claims was accepted if its signature was valid against the stored secret. If your secret has never been exposed, the practical risk is lower, but rotation is still recommended as a precaution and is required to revoke any tokens already in circulation. Where the bypass was exploited, the resulting token never expired and carried no issuer binding, granting permanent access to all authenticated MCP server endpoints — including endpoints exposing WordPress post and metadata read/write, plugin configuration, and any other capability the MCP server registers for authenticated callers.

WP-285 closes this by requiring both claims to be present and valid on every incoming token. The patch was released on 2024-11-14 as part of MetaSync MCP plugin version 1.4.2. Existing tokens issued before the patch are unaffected by the code fix alone — rotating the JWT secret is what revokes them.

🔍 How to Determine Whether Your Site Is Affected

Check all three conditions:

• You run the MetaSync MCP server plugin on a WordPress site.
• You have not rotated the JWT secret stored in wp_options since the WP-285 patch was applied (plugin version 1.4.2, released 2024-11-14).
• Your site issued JWT tokens to external clients, API integrations, or automation tools before the patch date. To check when a specific token was issued, decode it (for example, paste it at jwt.io) and read the iat (issued-at) claim. If iat is earlier than 2024-11-14, the token predates the patch.

If all three are true, treat your current tokens as potentially compromised and rotate the secret before taking any other action.

🔑 How to Rotate the JWT Secret in wp_options

Rotating the JWT secret immediately invalidates every previously issued token. You can rotate via the WordPress admin UI or WP-CLI.

Option A — WordPress admin:

1. Navigate to wp-admin → Search Atlas → Settings (MetaSync MCP).
2. Locate the JWT Secret field and click Regenerate.
3. Click Save Changes.
4. Re-issue new tokens from the same settings panel to each external client and API integration that needs continued access.

Option B — WP-CLI:

1. SSH into your WordPress server or open a terminal with WP-CLI access.
2. Identify the exact wp_options key MetaSync MCP uses for its JWT secret. Check your plugin documentation or run:
   wp option list --search="*jwt*" --fields=option_name
3. Generate a cryptographically random replacement secret and write it to wp_options:
   wp option update <your_jwt_secret_key> "$(openssl rand -hex 32)"
4. Confirm success — WP-CLI outputs Success: Updated '<your_jwt_secret_key>' option.

All tokens signed with the old secret are now invalid. Re-issue new tokens to every legitimate client that needs continued access before they attempt another request.

📋 After Rotating: Post-Rotation Checklist

Rotation will cause every active integration to start failing authentication until it receives a freshly signed token. Work through the following immediately after the secret is updated:

1. Re-issue tokens to all connected clients. This includes external API consumers, automation tools, CI jobs, and any internal services that authenticate to the MCP server.
2. Verify integrations are reconnected and healthy. Trigger a known-good request from each client and confirm it returns HTTP 200. Watch your error logs for residual 401 responses, which indicate a client that hasn't been updated yet.
3. Revoke or delete any tokens whose origin is unknown. If you find token records or active sessions you cannot tie to a legitimate client, do not re-issue them — remove them entirely.

Note for Search Atlas AI Agent users: If you use Search Atlas AI Agent integrations alongside MetaSync MCP, be aware that SA JWT tokens now also validate active subscription status (shipped via AIAGENT-2012). Tokens issued for inactive or lapsed Search Atlas accounts will be rejected independently of this patch, which can look like a rotation failure but is unrelated.

Troubleshooting silent auth failures: If authentication fails silently after rotating the JWT secret, check whether your WordPress or Search Atlas account has duplicate usernames prefixed with searchatlas_. This is a known issue (LPS-1114) and may require deduplication before re-authentication succeeds.

🧹 How to Audit Token Usage Before and After the Patch

After rotating the secret, identify which clients held tokens and confirm no unauthorized access occurred during the exposure window.

1. Review your web server access logs for requests to MetaSync MCP endpoints that carried a JWT Authorization: Bearer header. Filter to the date range before the WP-285 patch was applied.
2. Check your WordPress authentication logs (if enabled via a security plugin) for any MCP API calls that authenticated successfully during that window.
3. For each identified client, determine whether the access was legitimate. If you find unexplained API calls, treat the site as potentially compromised and engage your WordPress security team.
4. Contact every legitimate client and provide a freshly signed token issued against the new secret.

Once all legitimate clients hold new tokens, no pre-patch token — including any that exploited the bypass — can authenticate against your MCP server.

🛡️ JWT Hardening Settings to Apply After Patching

The WP-285 patch enforces exp and iss claim validation by default. Apply these additional controls to reduce future risk:

• Set a short token lifetime. Configure token expiry (exp) to 3,600 seconds (1 hour) or the shortest interval your integrations can tolerate. Never issue tokens with an unlimited or multi-year lifetime.
• Verify the issuer value. Ensure the iss claim MetaSync MCP embeds in tokens matches your site's canonical URL. The patch now rejects any token whose iss does not match the configured value exactly.
• Apply least-privilege token scope. Issue tokens with only the WordPress capabilities the client actually needs. Avoid tokens with full administrator scope for read-only integrations.
• Rotate the secret on a schedule. Rotate your JWT secret at least every 90 days, or immediately after any suspected credential exposure.

These controls ensure every active token has a bounded lifetime, a verified origin, and only the access level it requires.

✅ How to Verify the WP-285 Patch Is Active on Your Installation

Confirm the fix is live by testing the two previously exploitable token shapes against your MetaSync MCP endpoint.

1. Craft a JWT that omits the exp claim, signed with your current (rotated) secret. Use jwt.io or a local JWT library.
2. Send a request to your MetaSync MCP endpoint with that token as the Authorization: Bearer header. The server must return HTTP 401 Unauthorized.
3. Repeat with a token that omits the iss claim only. The server must again return HTTP 401.
4. Send a correctly formed token — with valid exp and iss claims — and confirm the server returns HTTP 200 and processes the request normally.

A 401 on both malformed tokens and a 200 on the valid token confirms the WP-285 patch is functioning correctly on your installation.

🎯 You have now revoked all pre-patch tokens, rotated your JWT secret, and hardened your MetaSync MCP server's token policy. For diagnosing MCP connection and configuration errors more broadly, see Understanding MCP Errors & How to Fix Them.