EUVD-2026-54477Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-delivered XSS with scope change to victim browser (S:C, C:L, I:L); user must visit affected page (UI:R); no attacker authentication required (PR:N).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
4DescriptionCVE.org
The ShareOpenly WordPress plugin prior to version 1.2.1 contains a Cross-Site Scripting vulnerability caused by the absence of WordPress's esc_url() escaping function on the $url variable before it is rendered into HTML content. This variable is constructed from home_url( add_query_arg( array(), $wp->request ) ) and is concatenated directly into an HTML href attribute on every singular post or page where the plugin's sharing link is displayed. WordPress's security handbook mandates that every URL placed in HTML output must be passed through esc_url(), which both HTML-encodes special characters (converting ", <, > into their safe HTML entity equivalents) and strips dangerous URI schemes such as javascript: and data:. The omission of this function means that if the $url value ever contains HTML-special characters or a dangerous URI scheme - through a home_url WordPress filter applied by another plugin or theme, through certain web server or hosting configurations, or through future code changes - the unescaped content will be injected verbatim into the rendered HTML of every post or page on the site. Version 1.2.1 contains a patch for the issue.
AnalysisAI
Cross-site scripting in the ShareOpenly WordPress plugin (versions prior to 1.2.1) allows JavaScript injection into every visitor's browser via an unescaped $url variable concatenated directly into an HTML href attribute on all singular posts and pages where the sharing link is rendered. The root cause is the absence of WordPress's mandatory esc_url() function on a URL constructed from home_url( add_query_arg( array(), $wp->request ) ), meaning any plugin, theme, or server configuration that taints that base URL via a home_url filter can introduce HTML-special characters or a javascript: URI scheme into the rendered page without sanitization. No public exploit has been identified at time of analysis; vendor-released patch version 1.2.1 is available and confirmed.
Technical ContextAI
The vulnerability resides in inc/add-sharing-link.php within the shareopenly_add_to_content() function (CPE: cpe:2.3:a:dartiss:shareopenly). The $url variable is built from home_url( add_query_arg( array(), $wp->request ) ) and concatenated directly into an anchor href pointing to https://shareopenly.org/share/?url=<$url> without passing through esc_url(). CWE-79 (Improper Neutralization of Input During Web Page Generation) applies: WordPress's esc_url() is required in all HTML attribute URL contexts because it both HTML-encodes special characters such as ", <, and > and strips dangerous URI schemes like javascript: and data:. The confirmed fix in commit faf58f0 wraps the entire constructed href string with esc_url(). The same patch also corrects several attribute-context escaping errors in settings.php, replacing esc_html() calls with the correct esc_attr() in HTML input value and id attributes, indicating the original code had broader escaping hygiene issues beyond the primary CVE.
RemediationAI
The vendor-released patch is version 1.2.1, confirmed available at https://github.com/dartiss/shareopenly/releases/tag/1.2.1. Administrators should update via the WordPress plugin dashboard or by downloading directly from the official release page. As an interim workaround pending update, deactivating the ShareOpenly plugin removes the vulnerable sharing link from all post and page output entirely, at the cost of losing the social sharing functionality the plugin provides. Administrators who cannot update immediately should also audit co-installed plugins and active themes for any use of the add_filter( 'home_url', ... ) hook, as any such filter that introduces HTML-special characters into the base URL is the primary precondition for exploitation. Removing or auditing conflicting filters reduces exposure without requiring plugin deactivation.
Same weakness CWE-79 – Cross-site Scripting (XSS)
View allShare
External POC / Exploit Code
Leaving vuln.today