The Eventin – Events Calendar

CVE-2026-4109 is a broken access control flaw in the WordPress plugin wp-event-solution (*Eventin – Events Calendar, Event Booking, Ticket & Registration*). In versions up to and including 4.1.8, the plugin's REST path uses an improper capability check in get_item_permissions_check(), so an authenticated user as weak as Subscriber can iterate order IDs and read order records containing customer PII such as names, email addresses, and phone numbers. The fix landed in 4.1.9 and the plugin changelog for April 7, 2026 explicitly notes a security fix.

The vendor's MEDIUM 4.3 baseline is a little generous for fleet prioritization and too optimistic for privacy impact. In real enterprise conditions this is usually post-registration or post-compromise abuse on a plugin with about 10,000+ active installs, not internet-wide unauthenticated compromise. But if a site allows self-registration or creates customer accounts as part of ticketing, the friction drops fast and this becomes a practical bulk-PII scrape. Net: downgrade one bucket to LOW, but keep it out of the ignore pile.

Why this verdict

• Requires authenticated access: the attacker must already have a WordPress account at Subscriber level or higher, which implies either public registration, customer-account creation, credential theft, or prior foothold.
• Narrow exposed population: WordPress.org shows about 10,000+ active installs, and only the subset running <= 4.1.8 with reachable login and the vulnerable REST path is actually exposed.
• Confidentiality-only outcome: this leaks order/customer PII but does not directly provide code execution, admin creation, integrity loss, or service disruption.
• Low exploitation pressure: your EPSS is 0.00032, it is not KEV-listed, and no credible public campaign or PoC ecosystem surfaced during review.
• But not IGNORE: if an Eventin site allows self-registration or routinely creates attendee accounts, the credential hurdle collapses and the bug becomes a very practical scraping issue.

Why not higher?

This is not a pre-auth edge bug, not a privilege-escalation-to-admin bug, and not an RCE. The attacker needs a valid low-privilege account and the impact stays inside order-data disclosure, so there is too much real-world friction to justify MEDIUM-to-HIGH patch panic for a 10,000-host enterprise fleet.

Why not lower?

Calling it IGNORE would miss the privacy angle. On event sites where users can sign up or where ticket purchases create accounts, a random internet user may be able to become the required Subscriber and enumerate customer PII at scale with almost no technical sophistication.

1. Disable self-registration where unnecessary — If the site does not need open account creation, turn it off and remove the easiest path to satisfying the PR:L prerequisite. For a LOW verdict there is no SLA (treat as backlog hygiene), but this is the cleanest immediate risk reducer because it removes anonymous-to-subscriber conversion.
2. Restrict Eventin REST routes upstream — Block or tightly allowlist the Eventin plugin namespace at the reverse proxy or WAF if business workflows do not require internet exposure to those routes. For LOW, there is no SLA (treat as backlog hygiene), but this is useful when patch lead time is longer than you'd like.
3. Audit low-privilege account creation — Review who can become Subscriber, how customer accounts are provisioned, and whether stale attendee/customer accounts persist indefinitely. For LOW, there is no SLA (treat as backlog hygiene), but reducing unnecessary low-privilege accounts directly cuts exploitability.
4. Watch for sequential order access — Alert on authenticated users making repeated reads across ascending or wide-ranging order IDs through /wp-json/ paths. For LOW, there is no SLA (treat as backlog hygiene), but this is one of the few signals that can catch active abuse before exfiltration is complete.

Run this on the target WordPress host or from an admin shell in the container/VM that holds the site files. Invoke it as bash check-eventin-cve-2026-4109.sh /var/www/html and give it read access to the WordPress plugin directory; root is not required unless file permissions are locked down.

#!/usr/bin/env bash
# check-eventin-cve-2026-4109.sh
# Detects whether the Eventin WordPress plugin (wp-event-solution) is vulnerable to CVE-2026-4109.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

WP_ROOT="${1:-}"
PLUGIN_DIR=""
VERSION=""

if [[ -z "$WP_ROOT" ]]; then
  echo "UNKNOWN - usage: $0 /path/to/wordpress"
  exit 2
fi

PLUGIN_DIR="$WP_ROOT/wp-content/plugins/wp-event-solution"

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

# Try the main plugin file first.
for f in \
  "$PLUGIN_DIR/wp-event-solution.php" \
  "$PLUGIN_DIR/eventin.php" \
  "$PLUGIN_DIR/eventin/eventin.php"; do
  if [[ -f "$f" ]]; then
    VERSION=$(grep -iE '^\s*Version:\s*' "$f" 2>/dev/null | head -n1 | sed -E 's/^\s*Version:\s*//I' | tr -d '\r')
    if [[ -n "$VERSION" ]]; then
      break
    fi
  fi
done

# Fall back to readme stable tag.
if [[ -z "$VERSION" && -f "$PLUGIN_DIR/readme.txt" ]]; then
  VERSION=$(grep -iE '^\s*Stable tag:\s*' "$PLUGIN_DIR/readme.txt" 2>/dev/null | head -n1 | sed -E 's/^\s*Stable tag:\s*//I' | tr -d '\r')
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN - could not determine installed Eventin version"
  exit 2
fi

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

if verlte "$VERSION" "4.1.8"; then
  echo "VULNERABLE - Eventin version $VERSION is <= 4.1.8"
  exit 1
fi

echo "PATCHED - Eventin version $VERSION is >= 4.1.9"
exit 0

Sources

1. NVD entry for CVE-2026-4109
2. Wordfence vulnerability record
3. WordPress.org plugin page and changelog
4. WPScan plugin vulnerability listing
5. CISA Known Exploited Vulnerabilities Catalog
6. WordPress REST controller permission check reference
7. Tenable CVE page with risk metadata