Elementor just dropped MCP support

The WordPress and AI ecosystems just collided in a major way. Elementor has officially rolled out its Elementor MCP (Model Context Protocol) beta, allowing external AI assistants like Claude Desktop, Claude Code, Cursor, and OpenAI Codex to hook directly into your WordPress site. Instead of prompting an AI to dump arbitrary HTML or CSS into a code block for you to paste by hand, Elementor MCP lets your AI agent construct layouts, manipulate design-system variables, and configure widgets natively inside Elementor’s engine.

On paper, this is the workflow agency developers have been dreaming about.

Under the hood, however, there is a security concession that should make any system administrator’s fur stand on end: Elementor is relying on native WordPress Application Passwords to authenticate the AI connection.

If you run security plugins like Wordfence, you already know the problem: many hardened WordPress stacks explicitly restrict, monitor, or outright disable Application Passwords.

So why did Elementor choose this route, is it actually a security risk, and should you connect it to your live or staging sites? Let’s dig in.

What Elementor MCP actually does

The Model Context Protocol (MCP), open-sourced by Anthropic, provides an open standard for AI models to query external contexts and execute tools.

Elementor’s implementation bridges external LLM interfaces to WordPress via the REST API and the WordPress Abilities framework. Inside the WordPress dashboard (Elementor → Elementor MCP), an administrator can enable MCP access and select an AI tool (Claude, Cursor, Codex, and so on).

To connect the two, Elementor generates a setup prompt for you to paste into your AI client. Behind the scenes, Elementor automatically provisions a WordPress Application Password associated with your administrator account and bundles it right into the connection string.

It works, it’s fast, and it requires zero technical configuration on the user’s part. But in cybersecurity, when setup friction drops to zero, risk usually rises with it.

The core issue: what are WordPress Application Passwords?

Introduced into WordPress core in version 5.6, Application Passwords provide a way to authenticate REST API requests using standard HTTP Basic Authentication (a username paired with a generated 24-character alphanumeric string).

The intention was sensible: stop users from handing their primary administrative passwords to external scripts and mobile apps. Because application passwords can be revoked individually from the user profile, WordPress core developers viewed them as an improvement over raw password sharing.

However, Application Passwords carry fundamental architectural limits when applied to modern AI integrations.

1. Zero granular scoping (the all-or-nothing trap)

The single biggest risk of WordPress Application Passwords is the absence of least privilege.

A WordPress Application Password does not have permission scopes. You cannot issue a password that says: “Allow this AI agent to edit Elementor pages, but forbid it from touching users, themes, core settings, or WooCommerce orders.”

Instead, an Application Password inherits every capability of the user who created it. Because Elementor MCP requires an Administrator to set up the connection, that generated key gets full administrative reign over your entire WordPress REST API. It can:

• Read and modify all published, draft, and private content.
• Exfiltrate customer data or order histories if e-commerce plugins are installed.
• Create, elevate, or delete user accounts (subject to REST endpoints available).
• Alter site options and taxonomy structures.

In Anthropic’s own MCP specification, scope minimisation is highlighted as a core security requirement. Elementor’s approach does the opposite: it hands over the master skeleton key.

2. The 2FA bypass loophole

Two-factor authentication (2FA) is the cornerstone of modern account security. Security plugins like Wordfence, Solid Security, and native passkey integrations are standard for any WordPress admin.

Here’s the catch: WordPress Application Passwords completely bypass 2FA.

By architectural design, HTTP Basic Auth via application passwords skips the 2FA challenge. If an attacker intercepts that 24-character string, or if a compromised desktop environment exposes your local AI config, an unauthorised party has a straight backdoor through your firewall’s login protections.

3. Secret sprawl in plaintext desktop configs

When you configure Claude Desktop or Cursor to speak MCP, the credentials must be stored locally on your workstation:

• In Claude Desktop: claude_desktop_config.json
• In Cursor: project MCP settings, or local .env files

These files are often stored in plaintext. Developers and content teams routinely sync dotfiles, push project repositories to GitHub or GitLab, or leave home directories unencrypted. If an MCP configuration file containing a live admin Application Password gets accidentally pushed to a public or team repo, your WordPress backend is fully compromised within seconds.

Why Wordfence and security pros often block them

The user friction with Elementor MCP is not theoretical — it is happening in real time. Many developers attempting to connect the beta immediately hit connection timeouts or HTTP 401 Unauthorized / 403 Forbidden errors.

The culprit? Wordfence.

Wordfence and several enterprise security plugins take a dim view of unmonitored Application Passwords for several reasons:

• Explicit hardening options: Under Wordfence’s Brute Force and Login Security settings, there is a dedicated toggle to disable Application Passwords. When enabled, Wordfence returns: “Application passwords have been disabled by Wordfence.” Wordfence does this precisely because application passwords are prime targets for credential abuse, bypass 2FA, and can be used in phishing vectors to link WordPress accounts to rogue endpoints.
• REST API lockdown: Many high-security configurations block unauthorised REST API access entirely or restrict endpoints to specific IP ranges. Because AI desktop agents (like Claude Desktop running on your laptop) connect from dynamic residential or office IPs, they trip heuristic rate-limits, XML-RPC/REST protection rules, and brute-force defences.
• No native IP whitelisting or TTL: WordPress Application Passwords are persistent until manually revoked. They do not expire after 24 hours, and they do not lock to a single IP address. Once leaked, they remain active indefinitely.

Is Elementor MCP inherently vulnerable?

To be clear: the Elementor MCP beta code is not an exploit.

It is using an official, documented WordPress Core authentication mechanism as it was designed. However, calling it “safe” obscures the difference between functional and best-practice security.

By taking the Application Password shortcut, Elementor prioritised immediate adoption and a low barrier to entry over robust credential isolation.

Practical recommendations

If you are eager to test Elementor’s new AI powers without turning your site into an open barn door, handle it like this today:

1. Never test on a live production site

Do not enable the Elementor MCP beta on production sites. If you want to experience the AI workflow, pull a staging copy into a sandboxed local environment (like LocalWP) or an isolated staging container (like InstaWP).

2. Avoid your primary admin account

If you must test on a remote staging server, do not generate the MCP setup prompt from your primary Super Admin profile.

• Create a dedicated user specifically for AI interaction (for example ai-elementor-bot).
• Assign it the bare minimum role necessary to construct pages (Editor or a custom role with page-editing capabilities, rather than full Administrator).
• Revoke the Application Password the minute your testing session concludes.

3. Check your Wordfence / security plugin configuration

If you run Wordfence:

• If you want to use Elementor MCP, navigate to Wordfence → Login Security and Firewall → Brute Force Protection to ensure Application Passwords are not globally blocked.
• Whitelist your client IP address if Wordfence repeatedly blocks REST API queries from your desktop AI agent.
• Remember to re-enable blocking once your tests are complete.

4. Git-ignore your MCP client configs

Ensure that any .cursor, .vscode, or local environment files containing MCP connection strings are explicitly added to your .gitignore. Never commit raw application credentials to version control.

The Bear’s verdict: what Elementor needs to build next

Elementor’s MCP integration is an impressive glimpse into the future of site design. Being able to direct Claude or Cursor to scaffold a responsive header or restructure a flexbox container using native widgets is legitimately powerful.

However, WordPress Application Passwords are a blunt instrument for autonomous AI agents.

For Elementor MCP to be viable in enterprise and agency environments, Elementor must implement:

• OAuth 2.0 with scoped permissions: grant AI agents read/write access strictly to Elementor templates, styles, and posts — locking out core settings, users, and plugin files.
• Ephemeral / time-limited access tokens: sessions that automatically expire, eliminating forgotten credentials sitting in plaintext config files.
• Audit logging: an in-dashboard log showing exactly which prompts and API calls modified which elements.

Until Elementor replaces static admin passwords with scoped, secure authentication, keep the beta inside your local sandbox.

The tech is fascinating — just don’t let convenience leave your backend wide open.