Description

The Topcontent WordPress plugin through 1.2.1 does not properly authorise one of its request handlers and disables HTML sanitisation before storing the submitted content, allowing unauthenticated attackers to publish arbitrary posts containing malicious JavaScript on any site where its API key has never been configured.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-10-11T07:17:27.377Z",
  "pubdate": "2026-10-11T07:17:27.377Z",
  "executiveSummary": "The Topcontent WordPress plugin through version 1.2.1 contains a critical security vulnerability involving improper authorization and insufficient input sanitization.\nThis flaw manifests as an unauthenticated Stored Cross-Site Scripting (XSS) vulnerability, allowing remote, unauthenticated attackers to inject malicious JavaScript into the site database.\nThe vulnerability is primarily triggered on installations where the Topcontent API key has not been configured, leaving the vulnerable request handler accessible to unauthorized entities.\nBy bypassing standard WordPress security controls and disabling HTML sanitization, an attacker can force the application to store arbitrary content, including malicious scripts.\nUpon successful exploitation, these scripts execute within the context of the victim's browser when they view the compromised post, potentially leading to session hijacking, unauthorized administrative actions, or defacement.\nThe risk is severe as it requires no prior authentication or administrative access, targeting the underlying site architecture before initial configuration is completed.\nOrganizations using this plugin should treat this as a high-priority risk and implement immediate mitigations to prevent unauthorized code execution.",
  "technicalDetails": "The vulnerability originates from a flaw in the Topcontent plugin's request handler, which fails to implement mandatory authentication checks for API-related requests.\nSpecifically, the plugin's REST API or admin-ajax endpoints do not verify the legitimacy of the requester, allowing any unauthenticated network user to interact with internal content submission functions.\nThe root cause is twofold: a lack of 'current_user_can()' authorization checks on the specific request handler and the deliberate disabling of WordPress's native 'kses' or related HTML sanitization filters prior to database insertion.\nIn a default state, when the API key has not been configured, the plugin's security guardrails for content validation are effectively bypassed.\nThe exploitation flow begins with the attacker sending a crafted HTTP POST request to the plugin's exposed endpoint. Because the endpoint lacks authentication gating, the server accepts the payload without validating the user's session or permissions.\nWithin the request body, the attacker embeds malicious JavaScript payloads disguised as valid post content. The plugin then processes this data and, due to the explicit disabling of sanitization, stores the raw malicious code directly into the WordPress 'wp_posts' table.\nOnce the post is saved, any user or administrator who navigates to the affected post or a page listing the post will have the malicious JavaScript rendered by their browser.\nBecause the execution occurs in the context of the victim's session, the attacker can perform actions on behalf of the user, such as creating new administrative accounts, exfiltrating sensitive data, or redirecting visitors to malicious domains.\nThis vulnerability is particularly dangerous because it persists in the database until the specific record is manually deleted by an administrator, providing a long-term vector for client-side attacks.\nThe exposure is global, as the endpoint is reachable via standard web protocols (HTTP/HTTPS) by any remote actor with network connectivity to the target WordPress installation, provided the specific conditions regarding the missing API key configuration are met."
}