Gerasimos

sudowp

SudoWP Radar is a runtime security auditor for the WordPress 6.9 Abilities API. It scans every registered ability across all active plugins and themes, applying a rule engine that detects the vulnerability patterns most likely to be exploited in production.
What it audits:
<ul>
<li>Open and weak permissions — abilities with no permission_callback, or one that allows any authenticated user through.</li>
<li>Missing or loose input schemas — abilities that accept unconstrained string inputs, creating potential injection vectors for path traversal, SSRF, and similar attacks.</li>
<li>REST overexposure — abilities marked show_in_rest with no or open permission control, accessible to unauthenticated callers.</li>
<li>MCP overexposure — abilities marked meta.mcp.public = true with a weak or null permission callback are directly callable by any connected AI agent. Flagged as CRITICAL.</li>
<li>Orphaned callbacks — execute_callbacks that reference functions no longer loaded, often left behind by deactivated plugins.</li>
<li>Namespace collisions — duplicate ability names where the last registration silently overwrites the first, potentially downgrading the permission model.</li>
<li>AI prompt filter bypass (WP 7.0+) — callbacks on wp_ai_client_prevent_prompt that unconditionally return false, disabling the AI prompt prevention gate sitewide. Flagged as HIGH.</li>
<li>AI REST overexposure (WP 7.0+) — REST endpoints that call wp_ai_client_prompt() with no or weak permission callbacks. Flagged as CRITICAL or HIGH.</li>
<li>AI missing version gate (WP 7.0+) — plugins that call wp_ai_client_prompt() without a function_exists compatibility check, causing fatal errors on WP < 7.0. Flagged as MEDIUM.</li>
<li>Hosting-injected ability (WP 7.0+) — abilities registered by hosting-provider auto-installed plugins with REST exposure, without explicit site administrator consent. Flagged as HIGH. Requires premium vendor slug list.</li>
<li>Connector key in database (WP 7.0+) — AI connector API keys stored as plaintext in the WordPress database via the WP 7.0 Connectors API, rather than as environment variables or PHP constants. Flagged as HIGH.</li>
</ul>
How it works:
SudoWP Radar reads the live abilities registry after all plugins and themes have loaded. It applies static rules to each ability and returns a structured findings report with severity ratings (Critical, High, Medium, Low) and actionable remediation guidance. A risk score from 0-100 summarises the overall exposure of the site.
Security model:
<ul>
<li>Requires the <code>radar_run_audit</code> capability (granted to site administrators by default).</li>
<li>All audit requests are nonce-gated. No public-facing endpoints.</li>
<li>Audit findings are stored in user meta, not global options.</li>
<li>Rate-limited to one audit per 30 seconds per user.</li>
</ul>
Optional premium extension (SudoWP Pro):
The free plugin is a fully functional standalone security auditor. An optional premium add-on extends it with SudoWP Vulnerability Dataset matching (CVE references, CVSS scores, patch guidance), scheduled audits with email alerts, multi-site dashboard aggregation, and report export. None of these are required to use the core auditing features.
SudoWP Radar is a complement to static analysis tools. It audits the live, runtime state of your site — what is actually registered and executing — not just what is declared in code.
<h3>External Services</h3>
When an API key is configured, SudoWP Radar connects to the SudoWP vulnerability 
dataset API (api.sudowp.com) to retrieve patch availability information for 
registered WordPress abilities.
No data is transmitted without an API key being explicitly entered by the site 
administrator. When no key is present, the plugin makes zero external network 
requests.
Data sent to the API: the ability name being looked up and your API key. 
No personal data, no site URL, no user data is transmitted.
API key registration: https://sudowp.com/get-api-key/ 
Terms of service: https://sudowp.com/tos/ 
Privacy policy: https://sudowp.com/privacy-policy/
<h3>Premium Extension Filters</h3>
SudoWP Radar exposes four WordPress filters so a premium plugin can extend 
the audit engine without modifying core plugin files.
<h4>radar_dataset_enabled</h4>
Controls whether dataset lookups run during an audit. Return true to activate.
Parameters: 
 $enabled (bool) — default false. 
 Returns: 
 bool
Example:
<pre><code>add_filter( 'radar_dataset_enabled', function ( bool $enabled ): bool {
 return true; // Enable dataset lookups.
} );
</code></pre>
<h4>radar_dataset_findings</h4>
Inject Finding objects from a vulnerability dataset for a specific ability. 
Called once per ability during an audit. Non-Finding return values are stripped.
Parameters: 
 $findings (array) — current Finding[] for this ability, default []. 
 $ability (array) — ability data array from Scanner (name, meta, callbacks, etc.). 
 Returns: 
 Finding[]
Note: register with accepted_args=2 to receive both parameters.
Example:
<pre><code>add_filter(
 'radar_dataset_findings',
 function ( array $findings, array $ability ): array {
 if ( str_starts_with( $ability['name'], 'my-plugin/' ) ) {
 $findings[] = new \SudoWP\Radar\Finding(
 ability_name: $ability['name'],
 severity: \SudoWP\Radar\Finding::SEVERITY_CRITICAL,
 vuln_class: \SudoWP\Radar\Finding::VULN_DATASET_MATCH,
 message: 'Known vulnerable ability pattern detected (CVE-2026-1234).',
 recommendation: 'Update my-plugin to version 2.1.0 or later.',
 is_premium: true,
 );
 }
 return $findings;
 },
 10,
 2
);
</code></pre>
<h4>radar_dataset_status</h4>
Override the dataset status array displayed in the admin UI.
Parameters: 
 $status (array) — default status with keys: 
 enabled (bool) — false in free version. 
 label (string) — UI display string. 
 last_updated (string|null) — ISO 8601 date or null. 
 total_entries (int) — 0 in free version. 
 Returns: 
 array (same shape as input)
Example:
<pre><code>add_filter( 'radar_dataset_status', function ( array $status ): array {
 return [
 'enabled' => true,
 'label' => 'SudoWP Vulnerability Dataset: Connected. 4,821 entries.',
 'last_updated' => '2026-03-08',
 'total_entries' => 4821,
 ];
} );
</code></pre>
<h4>radar_audit_findings</h4>
Modify the complete findings array after all rules and dataset lookups have run. 
Use this to add cross-ability findings, re-score existing findings, or suppress 
false positives. Called once per full audit run.
Parameters: 
 $findings (array) — complete Finding[] from the full audit. 
 $abilities (array) — all ability data arrays scanned during this audit. 
 Returns: 
 Finding[]
Note: register with accepted_args=2 to receive both parameters.
Example:
<pre><code>add_filter(
 'radar_audit_findings',
 function ( array $findings, array $abilities ): array {
 // Example: promote medium findings to high for a high-risk site.
 return array_map( function ( $finding ) {
 if ( $finding->severity === \SudoWP\Radar\Finding::SEVERITY_MEDIUM ) {
 return new \SudoWP\Radar\Finding(
 ability_name: $finding->ability_name,
 severity: \SudoWP\Radar\Finding::SEVERITY_HIGH,
 vuln_class: $finding->vuln_class,
 message: $finding->message,
 recommendation: $finding->recommendation,
 context: $finding->context,
 is_premium: $finding->is_premium,
 );
 }
 return $finding;
 }, $findings );
 },
 10,
 2
);
</code></pre>

SudoWP Radar

Security auditor for the WordPress Abilities API. Scans registered abilities for permission, schema, and exposure risks.

Timon

SlyTranslate wires AI translation into WordPress at three different levels: the admin UI, the Gutenberg editor, and from external LLM tools via MCP. Whichever level you work at, the same language plugin integrations and translation quality controls apply.
It works with any LLM available through a WordPress AI connector and natively supports Polylang, WP Multilang, WPGlobus, and TranslatePress Multilingual.
What it does
<ul>
<li>Translates posts, pages, and custom post types into any language managed by your active language plugin</li>
<li>Translates selected text or entire Gutenberg blocks inline, without leaving the editor</li>
<li>Exposes the same functionality as MCP abilities, so external LLM tools (Claude Code, Codex, and others) can drive translations programmatically</li>
<li>Carries SEO metadata (title, description) through the same translation workflow as the post content</li>
<li>Handles long and structured content with chunking and output validation</li>
<li>Supports model-specific profiles that tune prompt style and retry behavior for known model families</li>
</ul>
<h4>Workflow 1 — Admin UI translation (posts & pages overview, side panel)</h4>
Translate full posts or pages directly inside WordPress admin — either one at a time from the editor side panel or in bulk from the list view.
Requirements: language plugin + configured AI Connector
From the post/page list, select one or more items and choose a translation action from the bulk-actions menu. A dialog lets you pick target language, model, and whether to overwrite existing translations. Progress updates live while the translation runs, and you can cancel at any time.
From the editor side panel, the same controls appear alongside the post you are currently editing. TranslatePress users get an equivalent panel inside the TranslatePress visual editor on <code>?trp-edit-translation</code> pages.
The language plugin (Polylang, WP Multilang, WPGlobus, or TranslatePress) handles the translated post as it normally would — SlyTranslate creates or updates the translated entry and lets the language plugin own the relationship.
<h4>Workflow 2 — Inline Gutenberg translation (block or selected text)</h4>
Translate content while writing, without touching a language plugin or a full-post workflow.
Requirements: configured AI Connector
Select any text in a Gutenberg block and the block toolbar gains a Translate button. The selected text is replaced with the translation in place. When no text is selected, the button translates the entire block.
This workflow is self-contained: it does not require a language plugin and does not create or modify translated post entries. It is useful for one-off corrections, translating imported content on the fly, or working in a single-language site where you just need AI rewriting in another language.
<h4>Workflow 3 — LLM wrapper via MCP (Claude Code, Codex, and others)</h4>
Drive WordPress translations from inside your LLM tool of choice.
Requirements: language plugin + WordPress application password (token) + WordPress MCP Adapter plugin
When a WordPress MCP Adapter is active, SlyTranslate registers its abilities over MCP. Any MCP-capable LLM client — Claude Code, Codex, custom agents — can then discover and call them.
In this workflow the LLM wrapper provides the translation itself. SlyTranslate’s MCP abilities handle the WordPress side: reading content structure, checking translation status, writing translated entries, and coordinating with the language plugin. No WordPress AI Connector is needed because translation is performed by the external model, not by WordPress.
A typical agent session:
<ol>
<li>Call <code>ai-translate/get-languages</code> to find valid target language codes.</li>
<li>Call <code>ai-translate/get-translation-status</code> on the source post to read <code>source_language</code> and <code>single_entry_mode</code>.</li>
<li>Translate the content using the agent’s own LLM.</li>
<li>Call <code>ai-translate/translate-content</code> to write the translated entry.</li>
</ol>
This is the right workflow for automating bulk site migrations, integrating translation into a CI/CD pipeline, or building a custom translation agent that uses a model not available as a WordPress AI connector.
<h4>Internal flow</h4>
<pre><code>┌──────────────────┐ ┌───────────────────┐ ┌────────────────────────┐
│ Admin UI │ │ Gutenberg │ │ LLM Wrapper │
│ (panel / list) │ │ (block / toolbar) │ │ (Claude Code, Codex…) │
└────────┬─────────┘ └────────┬──────────┘ └──────────┬─────────────┘
 │ REST │ REST │ MCP
 └──────────────────────┴──────────────────────────┘
 │
 ┌──────────▼──────────────┐
 │ SlyTranslate Ability │
 │ (REST / MCP endpoint) │
 └──────────┬──────────────┘
 │
 ┌───────────▼───────────┐
 │ AI Connector │ ← UI/block workflows
 │ (wp_ai_client_prompt)│ only
 └───────────┬───────────┘
 │
 ┌───────────▼───────────┐
 │ LLM (any provider) │
 └───────────┬───────────┘
 │
 ┌───────────▼───────────┐
 │ Chunk + Validate │
 └───────────┬───────────┘
 │
 ┌───────────▼───────────┐
 │ Language Plugin │
 │ Polylang / TP / … │
 └───────────┬───────────┘
 │
 ┌───────────▼───────────┐
 │ WordPress Post │
 └───────────────────────┘
</code></pre>
In the MCP workflow the LLM Wrapper acts as the translation engine — the AI Connector and LLM steps inside WordPress are bypassed.
<h4>Abilities reference</h4>
<pre><code>ai-translate/get-languages — List languages exposed by the active language plugin

ai-translate/get-translation-status — Show translation status for a content item, including `source_language` and `single_entry_mode`

ai-translate/set-post-language — Change the language assignment of an existing content item (Polylang only)

ai-translate/get-untranslated — Find content still missing a target translation

ai-translate/translate-text — Translate arbitrary text

ai-translate/translate-blocks — Translate serialized Gutenberg blocks

ai-translate/translate-content — Create or update one translated post/page/CPT entry

ai-translate/translate-content-bulk — Bulk-translate multiple entries

ai-translate/get-progress — Return live progress for a running translation

ai-translate/cancel-translation — Cancel a running translation

ai-translate/get-available-models — List models from configured connectors

ai-translate/save-additional-prompt — Save per-user additional instructions

ai-translate/configure — Read or update persistent plugin settings
</code></pre>
MCP call sequence
For reliable results in agent workflows:
<ul>
<li>Call <code>get-languages</code> first when the correct target language code is unknown.</li>
<li>Call <code>get-translation-status</code> before <code>translate-content</code> to read <code>source_language</code>, <code>single_entry_mode</code>, and whether a translation already exists.</li>
<li>Omit <code>source_language</code> unless you intentionally pin a source variant.</li>
<li>Set <code>overwrite=true</code> only when status or prior context confirms a target-language entry already exists.</li>
<li><code>translated_post_id</code> equals <code>source_post_id</code> in single-entry adapters (WP Multilang, WPGlobus, TranslatePress). In multi-post adapters (Polylang) the translated item has a sibling post ID.</li>
</ul>
<h4>Supported plugins</h4>
Language plugins
<ul>
<li>Polylang</li>
<li>WP Multilang</li>
<li>WPGlobus</li>
<li>TranslatePress Multilingual</li>
</ul>
SEO plugins (metadata translated alongside content)
<ul>
<li>Genesis SEO</li>
<li>Yoast SEO</li>
<li>Rank Math</li>
<li>All in One SEO</li>
<li>The SEO Framework</li>
<li>SEOpress</li>
<li>Slim SEO</li>
</ul>
<h4>Supported model profiles</h4>
Any LLM available through a WordPress AI connector works without configuration. The following model families have dedicated built-in profiles that tune prompt style, chunking, and retry behavior:
<ul>
<li>TranslateGemma — dedicated runtime with <code>chat_template_kwargs</code> support via <code>direct_api_url</code></li>
<li>TowerInstruct / Salamandra — bilingual framing, conservative chunking, stricter retries</li>
<li>Nvidia Nemotron — system-prompt-aware, reasoning-disable, provider-parameter forwarding</li>
<li>Qwen 3.x / GLM-4.6v / Gemma 4 / Phi-4 — thinking-aware profiles</li>
<li>EuroLLM / Llama 3.1-8B / SauerkrautLM — conservative chunking tuned for European languages</li>
<li>Ministral-3 / Ministral-8B — optimized for the Ministral model family</li>
</ul>
Additional profiles can be registered via the <code>slytranslate_model_profiles</code> filter.

SlyTranslate – AI Translation Abilities

AI translation for WordPress — admin UI, Gutenberg inline, and MCP workflows for external LLM tools.

SudoWP Radar vs SlyTranslate – AI Translation Abilities