MCP for JCE - Audit and manage JCE editor profiles

Written by: Tim Davis Created: 18 September 2026

Category: Extensions

New!Hits: 268Reading time: 00:23

MCP for JCE is a free add-on for MCP for J that puts JCE's editor profiles in front of your AI client. Twenty-one tools cover profiles, who each one applies to, the toolbar grid, the per-plugin settings and the button catalogue, along with a health check and a read-only security audit. That audit is the reason most people will want this: JCE profiles decide who's allowed to upload what, and checking that yours are still the ones you set up is a question the JCE interface makes you answer by eye, one profile at a time.

Why this exists

JCE stores everything it knows in one table. Profiles, assignments, toolbar layouts, per-plugin settings and upload rules are all rows in #__wf_profiles, and most of the columns are hand-rolled encodings rather than anything a database can check — comma-separated lists of user groups and components, a toolbar stored as semicolon-separated rows of comma-separated button names, and one JSON blob for the settings. That's compact and it works, and it also means the interesting questions about a JCE install are hard to answer by looking.

The most common of those questions is simply "which editor does this person actually get?" JCE picks the first profile that matches on group, component, area and device, in ordering sequence, and once you have more than three profiles nobody can run that in their head reliably. There's a tool that replays JCE's own matching for a given user and context and shows its working, including the profiles it considered and rejected. The second most common question is whether the profiles on the site are still the ones somebody set up on purpose, and that one has a security answer rather than a convenience one.

What Claude can do

Twenty-one tools across five areas.

Installing it

You'll need Joomla 5 or 6, PHP 8.2 or later, MCP for J, and JCE itself. Either edition works.

1. Open Components → MCP for Joomla → Browse MCP Add-Ons and click Install on this add-on. You can also download the ZIP above and install it through System → Install → Extensions.
2. That's the whole install. The plugin enables itself, and the tools show up in your connected AI client the next time it lists them.

There's no admin screen for this plugin, by design — it adds tools to MCP for J rather than a place to click.

Using it

Ask for what you want in plain language. "Audit my JCE profiles" runs the security check. "Which editor toolbar does a Registered user get when they're writing an article?" runs the resolver and shows which profiles it looked at first. "Nobody can see the image button any more" is usually a health-check answer, because that's the class of problem JCE produces silently.

That silence is worth a sentence on its own. A JCE install can be misconfigured in ways that produce no error, no warning and no log line — with no published profile at all, JCE simply renders no editor for anyone, in either the site or the administrator, and says nothing about it. The health check looks for that family of states, which is the correctness counterpart to the security audit.

Checking that your profiles are clean

JCE below 2.9.99.5 carried CVE-2026-48907, a critical unauthenticated flaw that was mass-exploited from June 2026 and is on CISA's Known Exploited Vulnerabilities list. One of the ways it was used was to plant a JCE editor profile that permitted PHP uploads, and then upload a webshell through JCE's own file browser. The row was the payload.

Updating JCE does not remove that row. A site patched in June 2026 can still be carrying an attacker's profile today, sitting in the profile list looking unremarkable next to the legitimate ones. If your site predates 2.9.99.5, that's the thing to go and check, and it's what audit_jce_profiles is for.

The audit is entirely read-only. It touches nothing, changes nothing, and deletes nothing. It reads every profile and reports the indicators that matter: machine-generated-looking names with no human meaning, an ordering value low enough to pin a profile above every legitimate one so that first-match-wins picks it, executable extensions anywhere in a profile's allowed upload types, MIME validation switched off, the flags that permit PHP or JavaScript or event attributes in content, assignment to the Public group or to visitors who haven't logged in, and profiles whose settings are encrypted and therefore couldn't be checked at all. It also reports your installed version against the fix line. None of those indicators is proof on its own, and the response says so rather than shouting; together, they're a strong signal and they give you something specific to look at.

Two honest limits. This finds the profile half of a compromise only — these campaigns are layered, and webshells on disk, rogue Super User accounts, scheduled tasks and modified .htaccess files are all out of scope here. A clean audit is not a clean bill of health for the site, and the tool's own response tells you that instead of implying otherwise. And if a profile's settings are encrypted, which happens on some upgraded sites, the audit says it couldn't read that profile rather than reporting it as clean.

Why the write tools are cautious

Given what that table is, the write side is built to remove options rather than offer them.

There's no profile import tool, and there won't be one. A tool that accepts a whole profile payload and writes it is the shape of the problem, however carefully it validates, so every write here is a named, field-level setter instead. Executable file extensions are refused outright in any write that touches a profile's allowed upload types, checked against JCE's own blocklist and in any position including double extensions — the whole call is refused rather than the bad entry being quietly stripped, so you always know what happened. Writes are refused entirely on any site below 2.9.99.5, because on such a site a legitimate profile write is indistinguishable from an attack in any log you'd read afterwards. Reads still work there, because reading is how you find out what happened. And the security flags are one-way: you can tighten them from here, and you can't loosen them.

There's one more refusal that's about data rather than attack. On some upgraded sites JCE's settings column is encrypted with a key that never shipped in the package, and current JCE has a decrypt path and no encrypt path left. A naive read of such a row returns nothing at all and looks exactly like "this profile has no configuration", and a naive write would replace the encrypted value with plaintext permanently. The tools detect that and refuse in both directions.

There's no Pro version of this add-on, on purpose

JCE Pro adds no database table. Its plugin ships no install SQL at all, and what Pro actually adds is more keys inside the same settings blob on the same single table, plus browser-side editor capability — the image editor, the media manager — that works on files in real time and stores nothing. So these twenty-one tools already cover everything both editions persist, and a Pro add-on would have nothing left to read or write.

That's also the general rule for these add-ons. An add-on's tier mirrors the tier of the extension it wraps, and a tool only ships as paid if the capability genuinely doesn't exist in the free edition. Here nothing does, so the whole thing is free and it reports which edition it found rather than caring.

Open source

GPL-2.0-or-later, the same license as Joomla itself. Source lives on GitHub.

Interesting blog? Like it on Facebook, Post it or share this article on other bookmarking websites.