---
id: "CVE-2026-106013"
kind: "vulnerability"
aliases: ["CVE-2026-106013"]
title: "Jupiter X Core WordPress plugin: Twitter login lets anyone sign in as admin"
severity: "critical"
cvss: 9.8
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["package", "self-hosted", "wordpress", "wordpress-plugins"]
not_affected_if: ["default-config", "plugin-not-installed"]
published_at: "2026-10-28T02:17:01+00:00"
first_seen_at: "2026-10-28T02:30:29+00:00"
updated_at: "2026-10-28T02:32:03+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106013", "first_seen_at": "2026-10-28T02:30:29+00:00"}]
---

# Jupiter X Core WordPress plugin: Twitter login lets anyone sign in as admin

The Jupiter X Core WordPress plugin's Twitter/X social login signs visitors in as whichever WordPress account matches the X app owner's email, because the handler keeps using the site's stored X credentials. An unauthenticated attacker can log in as the site administrator.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed Jupiter X Core plugin version in the WordPress admin Plugins screen; versions up to and including `4.61.0` are affected.
- Check whether the Twitter/X social login feature is enabled in the Jupiter X Core settings.

## Fix

- Update the Jupiter X Core plugin to a version later than `4.61.0`; the fixed version is unknown from the sources.
- Disable the Twitter/X social login until the plugin is updated.
- Review WordPress administrator accounts for unexpected logins and rotate their passwords.

## Timeline

- 2026-10-28T02:30:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-106013

## From the sources

The Jupiter X Core plugin for WordPress is vulnerable to Authentication Bypass via the Twitter/X Social Login handler in all versions up to and including 4.61.0. The vulnerability exists within the verify_twitter_callback function because after exchanging the visitor's oauth_verifier for their access token, the handler never calls setOauthToken() to reassign the returned credentials to the TwitterOAuth client, causing the subsequent account/verify_credentials API call to remain signed with the site operator's stored Access Token and Access Token Secret rather than the authenticating visitor's token. This causes the X API to return the profile of the X application owner instead of the signing-in visitor, and the plugin then resolves and authenticates a WordPress account solely by matching that owner's email address via wp_set_auth_cookie(), allowing unauthenticated attackers to gain authenticated access as the WordPress user whose email corresponds to the X app owner, who is typically the site administrator.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_