The Gutenberg Essential Blocks – Page Builder for Gutenberg Blocks & Patterns plugin for WordPress is…

The public record around your prompt is messy, but the closest authoritative public match is a June 4, 2026 WPScan advisory for Essential Blocks < 6.1.4 describing Author+ SSRF via AI Image Generation on the same plugin. An earlier clearly documented sibling issue, CVE-2025-11361, affected <= 5.7.1 and abused save_ai_generated_image / eb_save_ai_generated_image so a logged-in WordPress user with Author-level access could make the server fetch attacker-chosen URLs and save the response body into uploads for later download.

That matters because the prompt's vendor framing says PR:N / HIGH 7.2, but the public technical writeups for this plugin family point the other way: authenticated Author+, admin nonce available from the editor UI, and exploitation bounded by the target's outbound reachability. SSRF with response exfiltration is real and operationally useful, but once you price in the attacker position requirement, this lands as a post-initial-access WordPress abuse path, not a perimeter breaker.

Why this verdict

• Vendor baseline is overstated: the prompt's PR:N / 7.2 framing does not line up with public technical records for this plugin family, which describe Author+ authenticated use of the AI image path.
• This is post-initial-access: requiring WordPress credentials, editor access, and a valid nonce means the attacker is already inside an application trust boundary before the bug does anything useful.
• Reachability is environment-dependent: SSRF value depends on what the WordPress host can reach. Egress filtering, metadata protections, network segmentation, and managed hosting all cap blast radius in real estates.

Why not higher?

I do not buy HIGH unless you can show a truly unauthenticated path or active exploitation. Without that, this is not a perimeter bug that every scanner bot can cash in from the internet. Also, the impact here is mostly data access and internal probing, not straightforward RCE or tenant-wide compromise.

Why not lower?

I am not pushing this to LOW because SSRF that can persist response bodies into uploads is more than a theoretical misfeature. On a WordPress estate with many authors, weak account hygiene, or cloud metadata exposure, it becomes a practical foothold amplifier.

1. Restrict Author-class accounts — Audit who actually needs Author+ on sites running this plugin and remove stale editorial accounts now. This directly cuts the only realistic exploit population; for a MEDIUM issue there is no mitigation SLA, so do this in your next normal access-review cycle if patching is not immediate.
2. Block metadata and east-west egress — Deny outbound access from WordPress hosts to 169.254.169.254, localhost proxies, and internal-only address space unless explicitly required. This turns SSRF into a much duller bug; for MEDIUM, there is no mitigation SLA, so fold it into your standard host-hardening window.
3. Watch admin-ajax.php from low-privileged users — Add detections for unusual AJAX calls from Author accounts, especially around AI image generation workflows and sudden media creation from backend fetches. This gives you fast visibility while you work through remediation under the 365-day window.
4. Disable the AI image feature if unused — If your editors do not need AI image generation, disable or remove that feature path entirely until all sites are patched. This is a clean workaround because it attacks the vulnerable function, not just the symptom.

Run this on the WordPress host or from a config-management agent with filesystem access to the plugin directory. Invoke it as bash check_essential_blocks_ssrf.sh /var/www/html or point it directly at the plugin root; no root is required if the WordPress files are readable.

#!/usr/bin/env bash
# check_essential_blocks_ssrf.sh
# Detects whether the Essential Blocks plugin version is vulnerable to the
# publicly documented AI-image SSRF advisory fixed in 6.1.4.
#
# Usage:
#   bash check_essential_blocks_ssrf.sh /var/www/html
#   bash check_essential_blocks_ssrf.sh /var/www/html/wp-content/plugins/essential-blocks
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -euo pipefail

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

PLUGIN_DIR=""
if [[ -d "$TARGET/wp-content/plugins/essential-blocks" ]]; then
  PLUGIN_DIR="$TARGET/wp-content/plugins/essential-blocks"
elif [[ -d "$TARGET" && "$(basename "$TARGET")" == "essential-blocks" ]]; then
  PLUGIN_DIR="$TARGET"
else
  echo "UNKNOWN - could not locate essential-blocks plugin directory from: $TARGET"
  exit 2
fi

# Try common files for plugin version extraction.
CANDIDATES=(
  "$PLUGIN_DIR/essential-blocks.php"
  "$PLUGIN_DIR/readme.txt"
)

VERSION=""
for f in "${CANDIDATES[@]}"; do
  if [[ -f "$f" ]]; then
    if [[ "$f" == *.php ]]; then
      VERSION=$(grep -Eim1 '^[[:space:]]*\*?[[:space:]]*Version:[[:space:]]*[0-9]+(\.[0-9]+)*' "$f" | sed -E 's/.*Version:[[:space:]]*//I' | tr -d '\r' || true)
    else
      VERSION=$(grep -Eim1 '^[[:space:]]*Stable tag:[[:space:]]*[0-9]+(\.[0-9]+)*' "$f" | sed -E 's/.*Stable tag:[[:space:]]*//I' | tr -d '\r' || true)
    fi
  fi
  if [[ -n "$VERSION" ]]; then
    break
  fi
done

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN - unable to parse plugin version"
  exit 2
fi

normalize() {
  local IFS=.
  local parts=($1)
  printf "%03d%03d%03d\n" "${parts[0]:-0}" "${parts[1]:-0}" "${parts[2]:-0}"
}

INSTALLED=$(normalize "$VERSION")
FIXED=$(normalize "6.1.4")

if [[ "$INSTALLED" -lt "$FIXED" ]]; then
  echo "VULNERABLE - Essential Blocks version $VERSION is older than 6.1.4"
  exit 1
else
  echo "PATCHED - Essential Blocks version $VERSION is 6.1.4 or newer"
  exit 0
fi

Sources

1. WPScan plugin vulnerability summary for Essential Blocks
2. WordPress.org plugin page for Essential Blocks
3. Wordfence advisory for CVE-2025-11361
4. CleanTalk PoC and technical writeup for CVE-2025-11361
5. NVD entry for CVE-2025-11361
6. CISA Known Exploited Vulnerabilities catalog
7. FIRST EPSS API documentation
8. Tenable CVE page mirroring EPSS for CVE-2025-11361