Insertion of Sensitive Information Into Sent Data vulnerability in brandtoss WP Mailster wp-mailster

CVE-2025-22303 is a sensitive information exposure issue in the WordPress plugin WP Mailster affecting versions through 1.8.17.0 and fixed in 1.8.18.0. Public advisories say a remote attacker can retrieve embedded sensitive data, typically described as user or configuration data, from an exposed plugin path or response. The impact is confidentiality-only; there is no published claim of code execution, privilege escalation, integrity loss, or service disruption from this CVE alone.

The vendor's 5.3/MEDIUM baseline is technically defensible in a vacuum, but it overstates operational urgency for most enterprises. The two biggest downward pressures are very small exposure population—WordPress.org shows roughly 300+ active installs and Wordfence tracks about 400—and no meaningful threat signal: no KEV, very low EPSS, and no public exploit tooling I could verify. There is also a credibility wrinkle: Patchstack/NVD/Wordfence describe it as unauthenticated, while the plugin changelog text around the fix mentions Subscriber+ for a sensitive data exposure fix, which lowers confidence in the exact attack preconditions and argues against an upgrade in severity.

Why this verdict

• Start from 5.3/MEDIUM: remote, low-complexity, no-user-interaction disclosure bugs on public web apps usually deserve attention
• Downward adjustment for tiny reachable population: this plugin is niche, with roughly 300-400 active installs, so the real-world target set is far smaller than a typical WordPress-core or top-plugin issue
• Downward adjustment for weak threat signal: no KEV, no public campaign reporting, and a very low EPSS do not support urgent exploitation pressure
• Downward adjustment for limited impact: this is a confidentiality-only bug with C:L/I:N/A:N; there is no direct takeover or code execution path in the advisory set
• Downward adjustment for prerequisite ambiguity: public sources disagree on unauthenticated vs Subscriber+ access, which makes the worst-case path less certain and less suitable for emergency handling

Why not higher?

This is not a takeover bug, not an RCE, and not tied to known exploitation. Even if the unauthenticated reading is correct, the likely payoff is narrow data exposure on a very small install base, not immediate domain-wide compromise. That combination does not justify MEDIUM-to-HIGH operational urgency for a large enterprise patch program.

Why not lower?

I would not ignore it completely because the published advisory set still describes a remotely reachable disclosure path and the patched version is straightforward. If you do run WP Mailster on an internet-facing site, leaking configuration or user-related data can become a useful stepping stone for later phishing, account targeting, or recon.

1. Inventory wp-mailster now — Confirm whether the plugin exists anywhere in your fleet, especially on internet-facing WordPress instances. Because the verdict is LOW, there is no SLA (treat as backlog hygiene), but you should still identify ownership and patch status during the next normal vulnerability sweep.
2. Restrict direct access to plugin paths — Use your WAF, reverse proxy, or web server rules to reduce exposure to unusual requests hitting wp-content/plugins/wp-mailster/ or plugin-specific routes. This is a sensible hardening step while you work through backlog hygiene; for a LOW verdict there is no mitigation SLA, so do it opportunistically where easy.
3. Minimize anonymous reach — If the affected site does not need public access to mailing-list features, tighten route exposure or require authentication where feasible. That directly attacks the most likely exploitation path and can be rolled into routine web-hardening work with no special deadline beyond normal operations.
4. Review leaked-data consequences — Check whether WP Mailster stores or exposes mailing-list metadata, SMTP settings, or user details that would materially help an attacker. This tells you whether the local business impact is merely nuisance-level or worth elevating in your internal queue, even though the noisgate verdict remains LOW.

Run this on the target WordPress host or a mounted copy of its web root. Invoke it as sudo bash check_wp_mailster_cve_2025_22303.sh /var/www/html or point it at the specific WordPress root; it only needs filesystem read access to the plugin files.

#!/usr/bin/env bash
# check_wp_mailster_cve_2025_22303.sh
# Detects whether WP Mailster is vulnerable to CVE-2025-22303 based on installed version.
# Usage: bash check_wp_mailster_cve_2025_22303.sh /path/to/wordpress
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_ROOT="${1:-}"
if [[ -z "$TARGET_ROOT" ]]; then
  echo "UNKNOWN - missing argument: /path/to/wordpress"
  exit 2
fi

PLUGIN_DIR="$TARGET_ROOT/wp-content/plugins/wp-mailster"
PLUGIN_FILE="$PLUGIN_DIR/wp-mailster.php"
README_FILE="$PLUGIN_DIR/readme.txt"

if [[ ! -d "$PLUGIN_DIR" ]]; then
  echo "UNKNOWN - wp-mailster plugin directory not found at $PLUGIN_DIR"
  exit 2
fi

get_version() {
  local file version

  file="$1"
  if [[ -f "$file" ]]; then
    version=$(grep -Eim1 '^[[:space:]]*Version:[[:space:]]*' "$file" | sed -E 's/^[[:space:]]*Version:[[:space:]]*//I' | tr -d '\r')
    if [[ -n "$version" ]]; then
      echo "$version"
      return 0
    fi
  fi
  return 1
}

normalize_version() {
  local v="$1"
  # Keep only digits and dots from the first token that looks like a version.
  v=$(echo "$v" | grep -Eo '[0-9]+(\.[0-9]+)+' | head -n1)
  echo "$v"
}

verlte() {
  # returns 0 if $1 <= $2
  [[ "$1" == "$2" ]] && return 0
  local first
  first=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
  [[ "$first" == "$1" ]]
}

VERSION_RAW=""
VERSION=""

if VERSION_RAW=$(get_version "$PLUGIN_FILE"); then
  VERSION=$(normalize_version "$VERSION_RAW")
fi

if [[ -z "$VERSION" ]] && [[ -f "$README_FILE" ]]; then
  VERSION_RAW=$(grep -Eim1 '^[[:space:]]*Stable tag:[[:space:]]*' "$README_FILE" | sed -E 's/^[[:space:]]*Stable tag:[[:space:]]*//I' | tr -d '\r')
  VERSION=$(normalize_version "$VERSION_RAW")
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN - could not determine WP Mailster version from plugin files"
  exit 2
fi

PATCHED_VERSION="1.8.18.0"

if verlte "$VERSION" "1.8.17.0"; then
  echo "VULNERABLE - WP Mailster version $VERSION detected (patched in $PATCHED_VERSION)"
  exit 1
fi

if verlte "$PATCHED_VERSION" "$VERSION" || [[ "$VERSION" == "$PATCHED_VERSION" ]]; then
  echo "PATCHED - WP Mailster version $VERSION detected"
  exit 0
fi

# Safety fallback for odd version strings
if [[ "$VERSION" =~ ^1\.8\.(1[89]|[2-9][0-9]) ]]; then
  echo "PATCHED - WP Mailster version $VERSION detected"
  exit 0
fi

echo "UNKNOWN - detected version $VERSION but could not classify confidently"
exit 2

Sources

1. NVD CVE-2025-22303
2. Patchstack advisory for WP Mailster sensitive data exposure
3. WordPress.org WP Mailster plugin page and changelog
4. Wordfence threat intel for WP Mailster
5. Rapid7 vulnerability database entry
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS data and API documentation