What is the CVSS score of EUVD-2025-28206?

EUVD-2025-28206 has a CVSS 3.1 base score of 7.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L. EPSS exploitation probability: 0.0%.

Which versions of WordPress are affected by EUVD-2025-28206?

WPQuark's eForm WordPress Form Builder plugin contains a reflected XSS vulnerability (CVE-2025-48333, CVSS 7.1) that enables unauthenticated attackers to inject malicious scripts into pages viewed by…. A patch is available.

How to fix or mitigate EUVD-2025-28206?

Within 24 hours: identify all WordPress instances using eForm plugin and document current version numbers. Within 7 days: apply available vendor patch immediately to all affected installations and verify patching through plugin update interface. Within 30 days: conduct site-wide security audit for signs of XSS exploitation (logs, malware scans) and implement Web Application Firewall (WAF) rules to filter malicious script injection attempts as preventive measure.

WordPress EUVD-2025-28206

| CVE-2025-48333 HIGH

Cross-site Scripting (XSS) (CWE-79)

2025-06-17 audit@patchstack.com

WordPress XSS

7.1

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.1 HIGH

AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

Low

Integrity

Low

Availability

Low

Lifecycle Timeline

Re-analysis Queued

Apr 23, 2026 - 15:42 vuln.today

cvss_changed

Analysis Updated

Apr 16, 2026 - 06:38 EUVD-patch-fix

executive_summary

Re-analysis Queued

Apr 16, 2026 - 05:29 backfill_euvd_patch

patch_released

Patch available

Apr 16, 2026 - 05:29 EUVD

4.19.1

EUVD ID Assigned

Mar 14, 2026 - 22:15 euvd

EUVD-2025-28206

Analysis Generated

Mar 14, 2026 - 22:15 vuln.today

CVE Published

Jun 17, 2025 - 15:15 nvd

HIGH 7.1

DescriptionCVE.org

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in WPQuark eForm - WordPress Form Builder allows Reflected XSS. This issue affects eForm - WordPress Form Builder: from n/a through n/a.

AnalysisAI

Reflected Cross-Site Scripting (XSS) vulnerability in WPQuark's eForm WordPress Form Builder plugin that allows unauthenticated attackers to inject malicious scripts into web pages viewed by other users. The vulnerability affects the eForm plugin across unspecified version ranges and can be exploited with user interaction to compromise confidentiality, integrity, and availability. No active KEV designation or confirmed POC availability is documented, but the network-accessible nature and low attack complexity present moderate real-world exploitation risk.

Technical ContextAI

This vulnerability is rooted in CWE-79 (Improper Neutralization of Input During Web Page Generation), a classic web application flaw where user-supplied input is not properly sanitized or encoded before being reflected back in HTTP responses. The WPQuark eForm plugin, a WordPress form-building component, fails to adequately escape or validate input parameters that are subsequently rendered in dynamically generated web pages. WordPress plugins are executed within the WordPress application context and have direct access to database and HTTP request/response handling. The vulnerability likely exists in form processing endpoints or parameter handling routines that construct page output without invoking WordPress security functions such as wp_kses_post(), esc_attr(), or esc_html(). As a reflected XSS (not stored), the attack vector requires crafting a malicious URL and social engineering the victim to click it.

RemediationAI

Immediate remediation steps: (1) Contact WPQuark or check their official security advisory/support channels for patched version availability and timeline; (2) Until patching, disable or deactivate the eForm plugin if not critical to operations; (3) Implement WordPress security hardening: enable Web Application Firewall (WAF) rules to detect XSS payload patterns in query parameters (e.g., ModSecurity CRS rules for Reflected XSS); (4) Apply WordPress-level protections: restrict form plugin capabilities using least-privilege user roles, implement Content Security Policy (CSP) headers to mitigate XSS execution, and use WordPress security plugins (e.g., Wordfence, Sucuri) with XSS filtering; (5) Patch to the latest eForm version once released by WPQuark. Specific patch version numbers are not provided in available metadata—monitor WPQuark's plugin page, GitHub releases (if applicable), or security mailing lists for update notifications.