High-severity findings.

Audited release

0.6.0

Findings

2

Worst severity

high

Content hash

a2409cb562a463333133683d… Copy

Findings

• high Unauthenticated SSRF: futusign_or_rss_url is passed to wp_remote_get and the XML body is echoed

  ssrf

  When ACF + futusign + futusign Overlay are active, Futusign_OverlayRSS_Public::query_vars registers futusign_or_rss_endpoint and futusign_or_rss_url as public query vars; add_rewrite_rule('^fs-or-rss-endpoint/?', 'index.php?futusign_or_rss_endpoint=1') plus parse_request forwards the attacker-supplied URL into futusign_or_rss_endpoint(). That helper calls wp_remote_get($rss_url) — not wp_safe_remote_get, so reject_unsafe_urls stays false and loopback/RFC1918/link-local/link-local metadata hosts are not blocked — then echo $body when Content-Type matches /^text\/xml/. No capability, nonce, or allow-list. The signage player (public/rss/src/apis/feed.js) is supposed to pass the ACF-stored feed URL; because the URL is a client query argument, any visitor can substitute an arbitrary http/https target. Full-read when the upstream answers with text/xml (attacker-controlled XML server, internal SOAP/RSS); always-on blind SSRF (connection still happens; 400 vs reflected body fingerprints ports/services). Redirects are followed (WP_Http default), so an open redirector can bounce the request at 169.254.169.254. Fix is to resolve the feed URL from the widget's rssID/ACF url server-side and use wp_safe_remote_get against that stored value only.

  public/partials/futusign-or-rss-endpoint.php:19-37

  Recommendation

  Do not accept a client-supplied URL. Look up the widget/overlay RSS post and fetch only its stored ACF 'url'. Switch to wp_safe_remote_get(), allow-list https (and optionally http) to public hosts, block private/loopback/link-local, cap response size, and do not reflect arbitrary upstream bodies to unauthenticated callers. Disable or auth-gate /fs-or-rss-endpoint if screens can fetch the feed directly.

• medium Abandoned futusign add-on: no maintainer will patch the update-hijack or SSRF

  unmaintained

  Header version 0.6.0, last_updated in the bundled metadata JSON is 2019-01-13, GitHub larkintuckerllc/futusign-wp-overlayrss last commit is 2019-01-13 (tag 0.6.0, 'Yahoo API terminated'). The parent plugin README (larkintuckerllc/futusign-wordpress) opens with 'This project is abandoned.' Tested up to WordPress 4.9. The only update channel is the dangling HTTP S3 host above; there is no Update URI and no newer GitHub release. Critical/high issues in this tree have no in-tree remediation path.

  futusignz-overlayrss.php:8-18

  Recommendation

  Remove the plugin from production. Replace digital-signage RSS overlays with a maintained stack, or a tightly scoped custom mu-plugin that fetches a single allow-listed HTTPS feed without an update checker or open proxy.

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.