CVE-2026-89274: Critical RCE in WP Recipe Maker (WordPress) — Public PoC, Patch Now

TL;DR

CVE-2026-89274 is a critical arbitrary shortcode execution flaw in the WP Recipe Maker plugin for WordPress, affecting all versions up to and including 10.8.1. The plugin calls do_shortcode() on recipe metadata fields — including the reviewBody field, which is populated verbatim from the comment_content of approved wprm-comment-rating comments — before any sanitization occurs. An unauthenticated attacker who gets a crafted rating comment approved can cause any registered WordPress shortcode to execute server-side on every recipe page render, with the output embedded in the page's JSON-LD reviewBody metadata and exposed to all visitors.

• Severity: CVSS v3.1 base 9.1 (Critical), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
• Exploitation status: Public proof-of-concept repositories are available on GitHub. Watchstack tags this as Critical with a public PoC and RCE.
• KEV status: Sources are inconsistent. Some feeds reference a CISA KEV addition dated 2026-09-19, while the Watchstack emergent-threat listing and the underlying advisory data do not confirm a KEV entry. Treat KEV status as unconfirmed and verify against the CISA catalog directly before relying on it for prioritization.
• Fix: Upgrade WP Recipe Maker to a version above 10.8.1. If you cannot patch immediately, disable recipe comment ratings or require manual moderation, remove any approved comments containing shortcode tokens, and purge page, CDN, and search engine caches.

If you run WordPress sites with recipe content, this is a patch-now item. The approval requirement is a weak barrier because many recipe sites auto-approve comments to drive engagement.

What happened

WP Recipe Maker is a widely deployed plugin for food, lifestyle, and content publishers. It generates structured recipe metadata — the JSON-LD block that search engines and social platforms consume to render rich results. That metadata pipeline is where the bug lives.

The plugin's WPRM_Metadata::sanitize_metadata() function recursively walks the recipe's structured metadata array and calls WordPress's do_shortcode() on every scalar field. One of those fields, reviewBody, is populated directly from the comment_content of approved wprm-comment-rating comments. In other words, visitor-supplied text is treated as template-capable content and executed server-side before any sanitization runs.

The subsequent wp_strip_all_tags() and strip_shortcodes() calls operate on the output string after execution has already fully occurred. They clean the rendered result; they do not prevent the shortcode from running. That ordering mistake is the entire vulnerability.

Disclosure is dated September 19, 2026. A patch is available in the WordPress plugin repository. Public PoC repositories appeared on GitHub shortly after, which lowers the barrier for opportunistic scanning and abuse.

Technical details

Root cause. WPRM_Metadata::sanitize_metadata() recursively calls do_shortcode() on every scalar field of the recipe metadata array, including reviewBody, before sanitization. The reviewBody field is populated verbatim from the comment_content of approved wprm-comment-rating comments. An attacker-controlled string containing shortcode tokens is therefore passed directly to do_shortcode().

Why the later sanitization does not help. wp_strip_all_tags() and strip_shortcodes() run on the already-executed output. By the time they run, the shortcode has already been invoked server-side and its output has already been produced. Stripping shortcode tokens from the result is cosmetic, not protective.

Weakness classification. CWE-94 (Improper Control of Generation of Code), with a CWE-79 flavor when the rendered output reaches page markup.

Affected versions. All WP Recipe Maker releases through 10.8.1.

Attack prerequisites. Modest. The attacker must submit a comment with a recipe rating, and that comment must pass the site's approval threshold — either through auto-approval or moderator action. No authentication is required. Once approved, the shortcode executes on every recipe page render, not just once.

Trust boundary. Untrusted visitor input is treated as template-capable content inside a server-side rendering path. That is the boundary that was crossed.

Why this is an RCE-class issue

It is tempting to file this as a data-disclosure bug because the observable output lands in JSON-LD. That framing undersells it. do_shortcode() is a server-side code execution primitive in the WordPress sense: it invokes registered shortcode handlers, and those handlers can read from the database, call other functions, and return rendered output. The attacker does not need to upload a file or achieve PHP-level code execution to get meaningful server-side behavior — they need a registered shortcode that does something useful, and most WordPress estates have several.

That is why the RCE tag on the Watchstack listing is appropriate. The practical impact depends on which shortcodes are registered on the target site, but the primitive itself is server-side execution of attacker-influenced content.

Impact

Confidentiality is the primary concern. Any registered shortcode on the target site can be invoked, and its output is embedded into the JSON-LD reviewBody metadata served to every visitor loading the recipe page. Depending on installed plugins, that can expose attachment captions, private post fields, user metadata, or other data that shortcodes surface.

Integrity impact is possible when shortcodes perform state changes or render attacker-influenced markup into the page.

Availability impact is rated none by the CVSS vector, though repeated shortcode execution on high-traffic recipe pages can add server load.

Business exposure includes SEO poisoning of structured data, reputational damage from leaked content, and downstream abuse if exposed data includes internal identifiers or email addresses. Because the output is embedded in page responses, leaked data can persist in search engine indexes and CDN caches long after the vulnerable comment is removed. That persistence is the part defenders most often miss.

Exposure validation: how to check if you are affected

Before you patch, know your footprint. Work through this list:

1. Inventory the plugin. Enumerate every WordPress instance in your estate and record the installed WP Recipe Maker version. Anything at or below 10.8.1 is in scope. Managed hosting dashboards, WP-CLI (wp plugin list --format=table), and your existing SBOM or asset inventory are all valid sources.
2. Confirm the plugin is active, not just installed. A deactivated plugin is not rendering metadata. Verify activation status.
3. Check comment configuration. If recipe comment ratings are enabled and comments are auto-approved, your exposure is materially higher. If ratings are disabled entirely, the attack surface is removed.
4. Inspect approved comments. Query the wp_comments table for approved wprm-comment-rating comments whose comment_content contains shortcode syntax — bracket-enclosed tokens. Any hit is a candidate indicator of compromise.
5. Inspect JSON-LD output. Fetch recipe pages and examine the <script type="application/ld+json"> block. Look for reviewBody values that contain rendered HTML, captions, or fields not authored by the reviewer.
6. Check caches. Page caches, CDN caches, and search engine indexes may hold leaked data. Purging them is part of remediation, not an afterthought.
7. Review logs. Look for automated POST requests to /wp-comments-post.php on recipe pages, particularly from unfamiliar IPs submitting comments with bracket-enclosed tokens. Also look for repeated recipe page requests immediately after a comment approval event — that pattern is consistent with verification or harvesting.

If any of these checks come back positive, treat it as a confirmed exposure and move to containment.

Indicators of compromise

• Comments containing shortcode syntax such as [ and ] inside wprm-comment-rating review bodies.
• Approved comments whose comment_content includes plugin shortcode names not expected from normal users.
• JSON-LD reviewBody values on recipe pages that contain rendered HTML, captions, or fields not authored by the reviewer.
• Spikes in comment submissions with rating metadata from single IPs, ASNs, or user agents.
• Repeated recipe page requests immediately after a comment approval event.
• Web server logs showing recipe URLs requested with unusual referrers or automated tooling signatures.
• Search engine or CDN cache entries containing unexpected data in structured recipe metadata.
• WAF or EDR alerts for shortcode-like patterns in POST bodies to wp-comments-post.php.
• PHP error logs showing unexpected shortcode execution traces originating from class-wprm-metadata.php.

Mitigation and workarounds

Primary fix. Update WP Recipe Maker to a version above 10.8.1. Verify the installed version after upgrading — do not assume the update applied cleanly across a fleet.

If patching is delayed:

• Disable recipe comment ratings, or require manual moderation with a trusted reviewer.
• Consider disabling comments on recipe post types entirely.
• Review and remove any approved comments containing shortcode tokens.
• Purge page caches, CDN caches, and search engine caches for affected recipe URLs.
• Deploy WAF rules that block shortcode delimiters in comment submission fields.
• Restrict which shortcodes are registered on the site, and audit plugins that expose sensitive data through shortcodes.
• Add monitoring for new comments with rating metadata and for JSON-LD changes on recipe pages.

Longer-term hygiene. Shortcode execution is a recurring WordPress attack surface. Treat any plugin that calls do_shortcode() on user-influenced input as a candidate for review. Keep an inventory of registered shortcodes and what data each one can surface — that inventory is what turns a vague "RCE" into a concrete blast-radius estimate.

Detection guidance for SOC and IR teams

• Hunt for the primitive, not just the CVE. Search web logs for POSTs to comment endpoints where the body contains bracket-delimited tokens. This pattern is generic enough to catch variants and copycats.
• Baseline your JSON-LD. If you can, snapshot recipe page JSON-LD output and alert on reviewBody values that change without a corresponding legitimate review.
• Watch approval events. A comment approval followed by a burst of recipe page requests is a suspicious sequence worth alerting on.
• Coordinate with content teams. Comment moderation is often owned by editorial staff, not security. Make sure the people who approve comments know what to look for.
• Check caches as evidence. Cached pages can preserve leaked data and serve as a timeline for when the injected shortcode first executed.

Patch and remediation timeline

1. Immediately: Inventory WP Recipe Maker versions across all WordPress instances. Identify anything at or below 10.8.1.
2. Within 24 hours: Patch to a version above 10.8.1 on internet-facing sites. Where patching is blocked, apply the workarounds above.
3. Within 72 hours: Audit approved wprm-comment-rating comments for shortcode tokens. Remove suspicious comments. Purge page, CDN, and search engine caches.
4. Ongoing: Monitor for new comments with rating metadata and for JSON-LD anomalies. Re-verify plugin versions after any rollback or restore.

KEV status: what we can and cannot confirm

This is where sources diverge, and defenders deserve a straight answer. Some feeds reference a CISA KEV addition dated 2026-09-19. The Watchstack emergent-threat listing and the underlying advisory data do not confirm a KEV entry, and the KEV metadata in the reference material shows unknown vendor, product, and due date — a pattern that is more consistent with an unconfirmed or aggregated claim than a verified catalog entry.

Our position: treat KEV status as unconfirmed. Verify directly against the CISA Known Exploited Vulnerabilities catalog before using KEV membership as a prioritization input. Do not let the ambiguity delay patching — the public PoC and the CVSS 9.1 rating are sufficient justification on their own.

Community reactions

The vulnerability was noted by Wordfence in their threat intelligence database and picked up by automated security tracking services including VulDB and Offseq Radar shortly after disclosure. Social media activity was largely limited to automated security feed posts. Public PoC repositories on GitHub accelerated discussion among bug bounty hunters and site operators, and community threads emphasized that the approval-threshold requirement is a weak barrier because many recipe sites auto-approve comments to encourage engagement. Hosting providers and managed WordPress platforms began issuing advisories and scanning customer sites for the vulnerable version. Defenders shared detection ideas around shortcode tokens in comment bodies and JSON-LD anomalies.

Trusteed take

This is a textbook example of a sanitization-ordering bug: the code does the right thing in the wrong order, and the wrong order is what makes it exploitable. The RCE tag is earned — do_shortcode() is a server-side execution primitive, and the attacker controls the input that reaches it. The public PoC removes the skill barrier. The approval requirement is real but soft, because auto-approval is common on exactly the kind of high-traffic recipe sites that run this plugin.

Our guidance is straightforward: patch to a version above 10.8.1, validate your exposure using the checklist above, purge caches, and hunt for shortcode tokens in approved comments. Do not wait for KEV confirmation to act.

FAQ

Is CVE-2026-89274 in CISA KEV? Sources conflict. Some feeds reference a KEV addition dated 2026-09-19, but the Watchstack listing and underlying advisory data do not confirm it, and the KEV metadata shows unknown vendor, product, and due date. Verify directly against the CISA catalog. Do not let the ambiguity delay remediation.

Is this really RCE, or just data disclosure? Both framings are defensible, but the RCE tag is appropriate. do_shortcode() invokes registered shortcode handlers server-side, and the attacker controls the input that reaches it. The observable output lands in JSON-LD, but the primitive is server-side execution of attacker-influenced content.

Does the attacker need an account? No. The attack is unauthenticated. The attacker submits a comment with a recipe rating; the comment must pass the site's approval threshold, either via auto-approval or moderator action.

What if my site requires manual comment approval? You are less exposed, but not immune. A single moderator approval of a crafted comment activates the payload, and it then executes on every recipe page render. Train moderators to recognize shortcode tokens in review bodies.

Which versions are affected? All WP Recipe Maker versions up to and including 10.8.1.

What is the fix? Upgrade to a version above 10.8.1. If you cannot patch immediately, disable recipe comment ratings or require manual moderation, remove approved comments containing shortcode tokens, and purge page, CDN, and search engine caches.

What shortcodes can be abused? Any registered shortcode on the target site. The practical impact depends on which plugins are installed and what data their shortcodes surface — attachment captions, private post fields, user metadata, and similar.

How do I know if I have been exploited? Look for approved wprm-comment-rating comments containing shortcode syntax, JSON-LD reviewBody values with rendered HTML or unexpected fields, spikes in rating comment submissions, and bursts of recipe page requests after a comment approval. Cached pages can preserve evidence.

Should I purge caches after patching? Yes. Leaked data can persist in page caches, CDN caches, and search engine indexes long after the vulnerable comment is removed. Purging is part of remediation.

Where can I find more information? The GitHub advisory (GHSA-x57m-9xmj-gh9p), the Wordfence threat intelligence entry, the WP Recipe Maker plugin page on WordPress.org, and the CISA Known Exploited Vulnerabilities catalog are the primary references. Public PoC repositories are available on GitHub but should not be used to test production systems.