EUVD-2026-34054
GHSA-4r7r-w926-gm5j
Severity by source
AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N
Lifecycle Timeline
2DescriptionCVE.org
The Passeum Ticketing plugin for WordPress is vulnerable to Stored Cross-Site Scripting in all versions up to, and including, 1.0. This is due to the get_shop_url() method returning the shop_name setting value without sanitization when it begins with "http", combined with insufficient validation in the validate_shop_name() function which only checks for empty values and string type. This makes it possible for authenticated attackers, with Administrator-level access and above, to inject arbitrary external scripts by setting the shop_name to an attacker-controlled URL (e.g., https://attacker.com), which causes the plugin to enqueue external JavaScript and CSS from the attacker-controlled domain via wp_register_script() and wp_register_style(). The injected scripts execute on every frontend page containing any Passeum Ticketing shortcode, affecting all site visitors. Please note that this does not affect single-site installations as administrators already have the unfiltered_html capability.
AnalysisAI
Stored Cross-Site Scripting in the Passeum Ticketing WordPress plugin (all versions ≤ 1.0) allows authenticated administrators on multisite installations to load attacker-controlled JavaScript and CSS on every frontend page that renders a plugin shortcode. The attack path runs through the plugin's shop_name setting: the validate_shop_name() function accepts any non-empty string, and get_shop_url() passes URLs beginning with 'http' directly to wp_register_script() and wp_register_style() without sanitization, causing the site to enqueue external resources from an attacker-controlled domain for all site visitors. No public exploit identified at time of analysis, and the vulnerability is explicitly scoped to WordPress multisite environments - single-site administrators are unaffected because they already hold the unfiltered_html capability.
Technical ContextAI
The vulnerability is rooted in two cooperating functions within the Passeum Ticketing WordPress plugin. In inc/settings.php at line 141, validate_shop_name() performs only rudimentary input validation - checking that the value is non-empty and a string - without any URL-safety check or allowlist enforcement. In passeum-ticketing.php at line 202, get_shop_url() returns the raw shop_name setting value without sanitization when that value begins with the string 'http'. The unsanitized URL is then passed to WordPress core functions wp_register_script() and wp_register_style() (passeum-ticketing.php line 40), which enqueue the external resource globally across the frontend. CWE-79 (Improper Neutralization of Input During Web Page Generation - Stored XSS) is the root cause class: the malicious value is persisted in plugin settings and replayed on every page render containing the plugin's shortcode, with no per-request re-validation or output encoding. The affected CPE is the Passeum Ticketing plugin for WordPress up to version 1.0, as indexed in the WordPress plugin repository.
RemediationAI
No vendor-released patched version has been identified at time of analysis - the NVD references point to version 1.0 source code and the trunk branch, with no tagged fixed release confirmed. Monitor the Wordfence advisory at https://www.wordfence.com/threat-intel/vulnerabilities/id/48363f1f-dae8-4efa-824f-098550245ca3 and the WordPress plugin repository for a patched release. As an interim compensating control, audit all WordPress multisite super-administrator accounts to ensure no unauthorized or compromised accounts exist with access to plugin settings - this is the only vector through which the shop_name setting can be modified. If Passeum Ticketing shortcodes are not strictly required on public-facing pages, temporarily removing them will prevent any stored payload from executing on the frontend, breaking the delivery chain without disabling the plugin entirely. Note that restricting network access will not mitigate this vulnerability because the payload is delivered by the site's own server enqueuing the external script - blocking outbound connections at the perimeter or via a Content Security Policy (CSP) that restricts script-src to known-safe origins would prevent browsers from fetching the attacker-controlled scripts and is the most effective network-layer control available without a vendor patch.
The isMail transport in PHPMailer before 5.2.20 might allow remote attackers to pass extra parameters to the mail comman
The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1
The Hash Form - Drag & Drop Form Builder plugin for WordPress is vulnerable to arbitrary file uploads due to missing fil
The GiveWP - Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to PHP Object Injection in all
The Simple File List plugin for WordPress through version 4.2.2 contains an unauthenticated remote code execution vulner
The AI Engine WordPress plugin through version 3.1.3 exposes Bearer Token values through the /mcp/v1/ REST API endpoint
The Ninja Forms plugin before 2.9.42.1 for WordPress allows remote attackers to conduct PHP object injection attacks via
The Business Directory Plugin - Easy Listing Directories for WordPress plugin for WordPress is vulnerable to time-based
SQL injection in the NotificationX WordPress plugin (versions up to and including 2.8.2) allows unauthenticated remote a
The POST SMTP Mailer - Email log, Delivery Failure Notifications and Best Mail SMTP for WordPress plugin for WordPress i
The MasterStudy LMS WordPress Plugin - for Online Courses and Education plugin for WordPress is vulnerable to union base
The Country State City Dropdown CF7 plugin for WordPress is vulnerable to SQL Injection via the ‘cnt’ and 'sid' paramete
Same weakness CWE-79 – Cross-site Scripting (XSS)
View allShare
External POC / Exploit Code
Leaving vuln.today