CVE-2026-107748 in User Profile Builder Plugin
Summary
by MITRE • 10/16/2026
The User Profile Builder – Beautiful User Registration Forms, User Profiles & User Role Editor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'display_name' parameter in all versions up to, and including, 4.0.3 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The payload persists in wp_comments.comment_author independently of the user account, so removing or changing the attacker's display name after the comment is posted does not neutralize the stored script.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The User Profile Builder plugin for WordPress, specifically versions up to and including 4.0.3, contains a critical security vulnerability classified as Stored Cross-Site Scripting (XSS). This flaw stems from insufficient input sanitization and output escaping mechanisms within the application code that handles user profile data. The specific vector of exploitation involves the display_name parameter, which is intended for storing the public-facing name of a user account. Due to the lack of proper validation against malicious script injection, an attacker can embed arbitrary JavaScript payloads directly into this field during the registration or profile update process. This represents a classic instance of CWE-79, Improper Neutralization of Input During Web Page Generation, where the application fails to neutralize special characters that could be interpreted as executable code by web browsers.
The operational impact of this vulnerability is significant because it allows for persistent attacks against any user who views the compromised content. Unlike reflected XSS, which requires tricking a victim into clicking a malicious link, stored XSS persists on the server side. In this specific case, the payload remains active in the wp_comments.comment_author database field independently of the attacker's main account status. This means that even if an attacker removes their profile or changes their display name after posting the malicious comment, the injected script continues to execute whenever a legitimate user views the page containing that comment. The attack requires authenticated access with at least subscriber-level privileges, which is often easily attainable through public registration forms on WordPress sites, thereby lowering the barrier for entry for potential attackers.
From an offensive security perspective, this vulnerability aligns closely with MITRE ATT&CK technique T1059.007, Command and Scripting Interpreter: JavaScript, as well as T1189 Drive-by Compromise if used in conjunction with other exploit kits to deliver malware upon execution. The persistence of the payload ensures that the attack is not a one-time event but rather an ongoing threat vector. When a victim user loads the affected page, their browser executes the injected script within the context of the vulnerable website. This can lead to session hijacking, where the attacker steals authentication cookies or tokens, allowing them to impersonate the victim and gain unauthorized access to sensitive areas of the application. It also facilitates credential harvesting through fake login forms embedded in the malicious script, as well as defacement of the site by altering its visual presentation.
Mitigation strategies must address both immediate remediation and long-term security hygiene. The primary solution is to upgrade the User Profile Builder plugin to a version later than 4.0.3, where these input validation and output escaping issues have been resolved by the developers. For organizations unable to patch immediately due to compatibility concerns, implementing Web Application Firewall rules can help detect and block requests containing common XSS payloads in user profile fields. Additionally, enforcing Content Security Policy headers on the WordPress site can significantly reduce the impact of successful XSS attacks by restricting the sources from which scripts are allowed to execute. Developers should also audit custom code for similar patterns, ensuring that all dynamic content is properly escaped using functions like esc_html or wp_kses_post before being rendered in HTML contexts. Regular security audits and penetration testing focused on input validation across user-facing forms are essential to prevent recurrence of such vulnerabilities.