Snel Newsletter WP Registry grade B. Medium-severity findings · 2 findingsWP RegistryMedium-severity findings · 2 findingsOpen the reportB

Medium-severity findings.

Audited release

1.9.25

Findings

2

Worst severity

medium

Content hash

dafad60eaa0d37bc817af443… Copy

Findings

• medium SNS webhook accepts AWS-signed messages from any topic (no TopicArn pinning, auto-confirms subscriptions)

  missing_auth

  POST /wp-json/snel-newsletter/v1/webhook/<slug> is registered with permission_callback __return_true and dispatches to the active adapter (SES is the default when no adapter is set). SES Adapter::parse_webhook() checks the SNS signature (cert URL restricted to sns.*.amazonaws.com) but never compares TopicArn (or the AWS account) against a configured topic, and for Type=SubscriptionConfirmation it blindly fetches SubscribeURL. An attacker with any AWS account can therefore create an SNS topic, add the site's webhook URL as an HTTPS subscriber (the plugin auto-confirms it), then publish to their own topic a Notification whose Message is a fake SES Bounce/Complaint listing arbitrary email addresses. The message is genuinely signed by AWS, so it passes verify_sns_signature(), and Controller::webhook() sets status='bounced' or 'complained' for every listed email (WHERE email = ...), permanently suppressing those subscribers (or the whole list if emails are known/guessed) and polluting delivery-event logs. No shared secret or per-site token is part of the URL.

  inc/adapters/ses/Adapter.php:40-79, 150-205

  Recommendation

  Store the expected SNS TopicArn(s) (or AWS account ID) in settings and reject any message whose TopicArn does not match before confirming subscriptions or processing notifications; optionally add a secret token to the webhook URL. Do not auto-confirm SubscriptionConfirmation for unknown topics.

• low Developer seeding scripts shipped in bin/ with hard-coded local paths

  dev_tool_in_production

  bin/seed-demo.php and bin/seed-demo-local.php are CLI demo-data seeders (create/delete subscribers, automations, queue and tracking rows) that require_once a hard-coded developer wp-load.php path and define a local MySQL socket. They have no ABSPATH/php_sapi_name() guard, so they are directly web-reachable under wp-content/plugins/snel-newsletter/bin/. On production the hard-coded path does not exist, so a request only produces a fatal error (path/username disclosure if display_errors is on), but shipping data-mutating dev tools without a CLI guard is unnecessary attack surface.

  bin/seed-demo.php:13-16

  Recommendation

  Remove the bin/ seeding scripts from the distributed package (or guard them with if ( PHP_SAPI !== 'cli' ) exit; and use WP-CLI commands instead).

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.