CVE-2026-15404 in Lpagery Plugin
Summary
by MITRE • 07/23/2026
The Lpagery plugin for WordPress is vulnerable to Stored Cross-Site Scripting via post titles in versions up to, and including, 2.5.7. This is due to insufficient input sanitization and output escaping in the lpagery_add_filter_text_template_post() function, which is hooked to admin_footer and echoes the raw post_title of the post referenced by the ?lpagery_template query parameter directly inside a JavaScript single-quoted string literal, without esc_js(), esc_html(), or any other encoding. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a higher-privileged user (such as an administrator) accesses an admin page with the ?lpagery_template=<post_id> parameter pointing at the attacker's post.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/23/2026
The lpagery plugin for WordPress represents a critical security vulnerability through its implementation of stored cross-site scripting in versions up to and including 257. This flaw stems from inadequate input sanitization and output escaping mechanisms within the lpagery_add_filter_text_template_post() function that operates within the admin_footer hook context. The vulnerability manifests when the plugin processes post titles through the ?lpagery_template query parameter, creating a direct execution path for malicious script injection.
The technical implementation of this vulnerability occurs at the point where the plugin echoes raw post_title data directly into JavaScript single-quoted string literals without proper encoding or escaping mechanisms. This specific pattern violates fundamental web security principles and creates an environment where attacker-controlled content can be seamlessly executed within the browser context of authenticated administrators. The function's hook to admin_footer provides a privileged execution context that amplifies the impact of this vulnerability significantly.
Authenticated attackers with contributor-level access or higher can exploit this weakness by crafting malicious post titles containing embedded JavaScript payloads that will execute whenever an administrator visits an admin page with the specific lpagery_template parameter pointing to their compromised post. This vector creates a persistent threat model where the attacker's malicious code remains active until the vulnerable plugin is updated or deactivated, potentially allowing for session hijacking, privilege escalation, or data exfiltration operations.
The operational impact of this vulnerability extends beyond simple script execution as it enables attackers to establish persistent footholds within WordPress administrative environments. This weakness directly aligns with CWE-79 which categorizes cross-site scripting vulnerabilities and maps to ATT&CK technique T1059.007 for command and scripting interpreter. The vulnerability creates a pathway for attackers to manipulate the WordPress administration interface, potentially compromising entire sites through unauthorized access to sensitive administrative functions.
Organizations should immediately implement mitigations including updating to patched versions of the lpagery plugin, implementing role-based access controls that limit contributor privileges, and monitoring for suspicious post creation activities. Network-level protections such as web application firewalls can provide additional defense-in-depth measures, though these are less effective against this specific type of stored XSS. The vulnerability demonstrates the critical importance of proper input validation and output encoding practices in web applications, particularly within content management systems where user-generated content processing occurs.
Security teams should prioritize monitoring for exploitation attempts through log analysis of ?lpagery_template query parameter usage and implement comprehensive patch management procedures to address similar vulnerabilities across other WordPress plugins. The attack surface expands when considering that this vulnerability affects not just the plugin's direct functionality but also creates opportunities for further exploitation within the broader WordPress ecosystem. Regular security audits of plugin code quality and implementation practices remain essential defensive measures against such persistent threats.
This vulnerability exemplifies how seemingly minor implementation flaws in content management systems can create significant security risks, particularly when user input flows directly into execution contexts without proper sanitization. The weakness demonstrates that even basic security controls such as esc_js() and esc_html() function calls are critical for preventing cross-site scripting exploitation. Organizations must maintain awareness of the specific plugin versions affected and ensure complete remediation through official updates rather than partial workarounds that may leave systems vulnerable to further attacks.
The exploitation scenario creates a particularly dangerous condition where administrative privileges can be leveraged by lower-privileged users, potentially enabling privilege escalation attacks and comprehensive site compromise. This makes the vulnerability particularly concerning for WordPress installations where multiple user roles exist and administrative access is limited to trusted individuals. The persistent nature of stored XSS vulnerabilities means that once exploited, the malicious payloads remain active until explicitly removed through plugin updates or manual intervention by system administrators.