Newsletter Builder WP Registry grade D+. High-severity findings · 3 findingsWP RegistryHigh-severity findings · 3 findingsOpen the reportD+

High-severity findings.

Audited release

0.8.0

Findings

3

Worst severity

high

Content hash

0a312c442986fb1aed9e05a8… Copy

Findings

• high Stored XSS in wp-admin via unsanitized newsletter template style meta

  xss_stored

  nb_template_font, nb_template_bg_color, and nb_template_link_color are registered post meta (config/post-meta.json) on the public, show_in_rest nb_template CPT with type string, no sanitize_callback, and default auth_callback (edit_post). A Contributor or Author can PUT those keys to a payload such as </style><script>…</script> on a template they can edit, then point an nb_newsletter at that template via nb_newsletter_template. When any user opens that newsletter in the block editor, set_template_values() (hooked to admin_head) prints the three values raw into a <style> tag (explicit EscapeOutput phpcs ignores). That is stored XSS in wp-admin: the victim's session can create administrators, change options, or install plugins. The same meta is interpolated into frontend newsletter CSS in action_newsletters_enqueue_styles(); that path runs wp_strip_all_tags first so it is CSS injection rather than script execution. The Gutenberg ColorPicker/SelectControl UI does not emit this payload; the REST meta write does.

  src/assets.php:289-307

  Recommendation

  Sanitize template style meta on write (hex for colors; allowlist for font stacks). Escape all three values with esc_attr() in set_template_values(). Do not phpcs-ignore EscapeOutput here. Restrict nb_template / nb_newsletter capabilities so Contributor cannot plant templates that editors then open.

• medium Unauthenticated visitors can list and view draft newsletters

  information_disclosure

  nb_newsletter is registered public with has_archive and rewrite slug nb-newsletters. modify_query() on pre_get_posts, for the front-end main query with post_type=nb_newsletter, forces post_status to [publish, draft]. WordPress would otherwise 404 drafts for logged-out users. The comment states this is so draft newsletters can be viewed; Campaign Monitor create_campaign() sends home_url()?post_type=nb_newsletter&p={id} as HtmlUrl. Combined with a public archive, GET /nb-newsletters/ lists unpublished newsletters and GET /?post_type=nb_newsletter&p={id} (or /nb-newsletters/{slug}/) renders single-nb_newsletter.php → the_content() for drafts. Drafts commonly embed unpublished post content via the post blocks. There is no preview token, capability check, or logged-in requirement. REST collection queries are unaffected (not the main query), but the HTML surface is public.

  src/class-wp-newsletter-builder.php:296-307

  Recommendation

  Do not globally expose drafts. Gate HtmlUrl with a secret token (query arg checked in template_include / modify_query) or a capability check, and keep the public archive to published only. Prefer sending inlined HTML to the ESP (as SendGrid/Beehiiv already render internally) instead of a world-readable draft permalink.

• medium Unauthenticated subscribe accepts arbitrary list IDs and force-resubscribes

  unsafe_input

  POST /wp-json/wp-newsletter-builder/v1/subscribe is registered with permission_callback __return_true. subscribe() only checks that email and listIds are non-empty strings, then explodes listIds and calls the configured provider add_subscriber() for each ID with no allowlist against lists configured on signup blocks. Email is not passed through is_email() or sanitize_email(). Campaign_Monitor::add_subscriber() sends Resubscribe=true and ConsentToTrack=yes; Beehiiv::add_subscriber() sends reactivate_existing=true. Signup-form view.ts posts without a nonce (REST cookie auth is not used). List IDs are not secret: they appear in signup-form markup and in public REST meta nb_newsletter_list on published newsletters; users with edit_posts can also dump every ESP list from GET /wp-newsletter-builder/v1/lists. Observable effects: unauthenticated addition of any address to any list the stored API key can write, re-opt-in of previously unsubscribed addresses, and unbounded ESP API traffic (no rate limit). Failed provider responses are returned in results (API error bodies).

  src/class-rest-api-endpoints.php:77-84,251-299

  Recommendation

  Keep the endpoint public for the signup block, but validate is_email(), allowlist listIds against IDs actually configured on published signup-form blocks (or a managed option), set Resubscribe/reactivate_existing to false unless the list explicitly allows it, rate-limit by IP, and do not echo raw ESP API bodies to the client. Prefer rest_url() in view.ts instead of a hardcoded /wp-json path.

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.