CVE-2025-6546 is a stored Cross-Site Scripting (XSS) vulnerability affecting the Drive Folder Embedder plugin for WordPress, developed by azumbro. This vulnerability exists in all versions up to and including 1.1.0 and arises due to improper neutralization of input during web page generation, specifically through the 'tablecssclass' parameter. The plugin fails to adequately sanitize and escape user-supplied input, allowing authenticated users with Contributor-level access or higher to inject arbitrary JavaScript code into pages. Because this is a stored XSS, the malicious script is saved on the server and executed whenever any user accesses the compromised page. The vulnerability has a CVSS 3.1 base score of 6.4 (medium severity), with the vector indicating network attack vector (AV:N), low attack complexity (AC:L), privileges required (PR:L), no user interaction (UI:N), scope changed (S:C), and impacts on confidentiality and integrity (C:L/I:L) but no impact on availability (A:N). Exploitation does not require user interaction beyond visiting the infected page, and the scope change indicates that the vulnerability can affect components beyond the initially vulnerable plugin, potentially impacting other parts of the WordPress site or user sessions. No known exploits are currently reported in the wild. The vulnerability is significant because WordPress is widely used, and the Drive Folder Embedder plugin is used to embed Google Drive folders into WordPress sites, often in business or organizational contexts. An attacker with contributor access can leverage this flaw to execute scripts that could steal cookies, perform actions on behalf of users, or deliver further payloads, compromising confidentiality and integrity of site data and user information.

For European organizations, the impact of this vulnerability can be substantial, especially for those relying on WordPress sites with the Drive Folder Embedder plugin installed. Stored XSS can lead to session hijacking, unauthorized actions, and data theft, potentially exposing sensitive customer or internal data. This can result in reputational damage, regulatory non-compliance (e.g., GDPR violations due to data breaches), and financial losses. Since the vulnerability requires contributor-level access, insider threats or compromised contributor accounts pose a risk. The scope change in the vulnerability means that the attack could affect multiple components or users beyond the initial plugin context, increasing the potential damage. Organizations in sectors such as finance, healthcare, and government, which often use WordPress for public-facing or intranet sites, may face higher risks. Additionally, the ability to inject scripts without user interaction means automated exploitation is feasible once access is gained, increasing the threat level. Although no known exploits are currently reported, the medium severity rating and ease of exploitation suggest that attackers may develop exploits, making timely mitigation critical.

1. Immediate mitigation should involve updating the Drive Folder Embedder plugin to a patched version once available. Since no patch links are currently provided, organizations should monitor vendor communications closely. 2. Restrict Contributor-level access strictly to trusted users and review user roles regularly to minimize the risk of insider threats or compromised accounts. 3. Implement Web Application Firewall (WAF) rules that detect and block suspicious input patterns targeting the 'tablecssclass' parameter or typical XSS payloads. 4. Employ Content Security Policy (CSP) headers to restrict the execution of unauthorized scripts on WordPress sites, reducing the impact of potential XSS payloads. 5. Conduct regular security audits and penetration testing focusing on user input sanitization and output encoding in WordPress plugins and themes. 6. Educate site administrators and contributors about the risks of XSS and the importance of cautious input handling. 7. Consider disabling or limiting the use of the Drive Folder Embedder plugin if immediate patching is not feasible, especially on high-risk or sensitive sites. 8. Monitor logs and user activity for unusual behavior that could indicate exploitation attempts.