I found a security vulnerability in WordPress Studio Code.

And the ironic part? I found it by using Studio Code itself.

What is Studio Code?

WordPress Studio is a local development environment for WordPress made by Automattic.

Recently, they added a built-in code editor called Studio Code. Think of it like VS Code but inside Studio, with an AI assistant built in.

When you open Studio Code for the first time, it asks you to pick how to authenticate for AI:

  1. Login with your WordPress.com account
  2. Use your own API key (BYOK)

I picked the WordPress.com option. No payment required. Just my existing WordPress.com account.

Free Access to Premium AI Models

After logging in, I could immediately use GPT 5.5 and Claude Opus 4.8.

No credit card. No API setup. Just log in and go.

I used it for about 30 minutes and never hit a limit.

Impressive. But then I started wondering something.

The Question That Started Everything

Studio Code is good, but the AI inside it is focused on WordPress-related tasks. When I tried using it for general coding, it felt a bit constrained compared to using Claude Code or Cursor directly.

So I asked myself: can I use this WordPress.com AI access somewhere else?

That’s where things got interesting.

Using GPT 5.5 to Reverse Engineer Itself

I asked GPT 5.5, directly inside Studio Code, to help me figure out how Studio Code sends AI requests to WordPress.com.

My goal was to add WordPress.com as a provider in 9Router.

If you don’t know 9Router: it’s a local AI routing tool that sits between you and different AI providers. You configure your providers once in 9Router, and then any OpenAI-compatible client on your machine can use them. Instead of setting up API keys separately for each tool, you set it up once and route everything through one place. So for example, Claude Code, Cursor, or any other client can all use the same provider connection through 9Router.

I spent about 2 hours going back and forth with GPT 5.5 inside Studio Code. I gave it minimal guidance, basically just asking it to figure out how Studio Code talks to WordPress.com and make it work as a 9Router provider.

And it worked.

GPT 5.5 reverse engineered its own proxy setup and helped me configure it outside of Studio Code.

I was genuinely amazed. I gave it very little direction and somehow it pulled it off.

What Happened When I Tried Opus 4.8

Out of curiosity, I tried the same thing with Claude Opus 4.8.

It politely refused.

I don’t have the transcript to show you. But Opus 4.8 would not help me reverse engineer or replicate the proxy configuration.

So it seems like Anthropic’s models are more cautious about this kind of task than GPT 5.5 was. Interesting difference in how each model handles security-adjacent requests.

The Vulnerability

Once 9Router was connected to the WordPress.com AI proxy, I realized the actual problem.

Studio Code routes AI requests through this endpoint:

https://public-api.wordpress.com/wpcom/v2/ai-api-proxy

The authentication only needs two things:

  • A valid WordPress.com OAuth token (the same one used when you log in)
  • A header called X-WPCOM-AI-Feature: studio-assistant

Both of these can be copied by any HTTP client. The header is not a secret. And the OAuth token is just your regular WordPress.com login token.

This means anyone with a WordPress.com account can use Studio’s AI proxy from any tool, not just Studio Code.

How Critical Is This?

Very.

The most serious part is not just that you could access GPT 5.5 or Opus for free.

Through this loophole, I was also able to access claude-fable-5. (Yes, the timeline was when Fable 5 still available)

Fable is Anthropic’s latest and most capable model. It is significantly more expensive than Opus or Sonnet.

In a single day of testing, I made 1,365 requests to claude-fable-5 through this proxy. The equivalent API cost was $576.16 for Fable alone. Add GPT 5.5 usage on top of that and the total was nearly $600 in one day, from a single person.

If someone built a public tool using this loophole and distributed it, the cost to Automattic could have reached millions.

And because a WordPress.com OAuth token is all you need, the attack surface is every WordPress.com account holder, not just Studio users.

What I Did

I posted on X asking who at Automattic I should contact to report this.

Wojtek Naruniec from the Studio team reached out the same day and asked me to send the details via DM.

I sent him everything: the endpoint, the required headers, and how I had configured 9Router to use the proxy from outside Studio Code.

How Automattic Responded

The next day, they had already made a fix.

I was seeing studio_cap_exceeded responses, which meant they added rate limits on the API side.

Wojtek confirmed:

“Yesterday, we’ve added rate limits on the API side to address the abuse vector you described. The GPT 5.5 gap you’re still seeing is on our radar and we’ll be looking at that too.”

Fast response. No dismissal. They took it seriously.

Bug Bounty?

I asked about it.

Wojtek said they were planning to revisit the pricing and access model post-beta. No formal bug bounty program was mentioned.

No bounty so far.

Key Takeaway

If you are building something that has AI in it, just be careful, someone could abuse it.