CVE-2026–10092: Unauthenticated Stored XSS in Cincopa Video and Media Plug-in

When WordPress comments become a persistent shortcode execution surface

Cincopa video and media plug-in is a WordPress plugin used to embed and manage video, image, and media galleries through WordPress content.

Like many media plugins, it relies on shortcodes to render dynamic content inside posts, pages, and other WordPress output areas. Shortcodes are powerful because they allow non-technical users to insert complex functionality with a simple tag.

But that power also creates risk.

CVE-2026–10092 is a Stored Cross-Site Scripting vulnerability affecting Cincopa video and media plug-in versions up to and including 1.163. The issue exists because the plugin processes the [cincopa] shortcode inside post comments through the comment_text filter hook, without sufficient input sanitization and output escaping.

This allows unauthenticated visitors who can post comments to inject malicious shortcode arguments that persist in the WordPress database and execute when the affected page is viewed.

In other words, a comment can become a stored JavaScript delivery mechanism.

Vulnerability summary

CVE: CVE-2026–10092 Product: Cincopa video and media plug-in Platform: WordPress plugin Affected versions: Up to and including 1.163 Vulnerability type: Unauthenticated Stored Cross-Site Scripting Affected area: [cincopa] shortcode in post comments Relevant WordPress hook: comment_text CWE: CWE-79 — Improper Neutralization of Input During Web Page Generation CVSS 3.1: 7.2 HIGH Vector: AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N Patch status: No known patch available at the time of disclosure

The most important detail is that exploitation does not require authentication. If a vulnerable site allows unauthenticated users to submit comments that are later rendered, an attacker may be able to store a malicious payload inside a comment.

What is the issue?

The vulnerability is caused by the way the plugin handles the [cincopa] shortcode in comments.

In WordPress, comments are normally treated as user-generated content. They may contain text, links, limited markup depending on configuration, and other values controlled by site visitors. Because of that, comment output must be handled carefully.

CVE-2026–10092 becomes possible when the plugin processes shortcode syntax inside comment text. This means a visitor can submit a comment containing a [cincopa] shortcode with attacker-controlled arguments.

If those arguments are not sanitized and escaped correctly, they may break out of the intended output context and inject JavaScript into the rendered page.

The simplified attack flow is:

A vulnerable WordPress site uses Cincopa video and media plug-in version 1.163 or earlier.
The site allows visitors to submit comments.
An unauthenticated attacker submits a comment containing a malicious [cincopa] shortcode.
The plugin processes that shortcode through the comment rendering flow.
The malicious argument is stored in the database as part of the comment.
When the affected page is viewed, the payload is rendered and executes in the visitor's browser.

This is Stored XSS because the payload is saved server-side and delivered later to users who access the page.

Why this vulnerability is more serious than a normal comment issue

At first glance, a comment-based XSS might sound limited. After all, comments are commonly moderated, filtered, or protected by anti-spam tools.

But this vulnerability is not just about ordinary comment HTML. It involves shortcode processing.

That distinction matters because a shortcode is not passive text. It is an instruction that tells WordPress or a plugin to execute rendering logic.

A comment containing normal text is one thing. A comment that can trigger plugin shortcode logic is something else entirely.

When plugins allow shortcodes to be processed in comments, they expand the attack surface from "user-submitted text" to "user-submitted input interpreted by plugin code."

If that plugin code was originally designed for trusted authors editing posts or pages, it may not be safe when exposed to unauthenticated commenters.

That is the core problem behind CVE-2026–10092.

Why shortcodes in comments are dangerous

Shortcodes are common in WordPress because they are convenient. They allow site owners to embed galleries, forms, videos, sliders, maps, buttons, and other dynamic elements without writing code.

However, shortcodes are also dangerous when exposed to untrusted users.

A shortcode usually accepts attributes. For example, a media plugin might accept IDs, gallery names, layout options, URLs, dimensions, titles, or configuration values.

Those attributes are input.

If the shortcode is used only by administrators or editors, the risk is still present but partially limited by permissions. If the shortcode can be submitted by unauthenticated commenters, the trust model changes completely.

Now the attacker is not a logged-in content creator. The attacker is any visitor who can submit a comment.

That means every shortcode argument must be treated as hostile.

The plugin must validate expected values, reject unexpected structures, and escape all output according to the exact browser context where it appears.

When that does not happen, XSS becomes possible.

Stored XSS and persistence

Stored XSS is especially dangerous because the malicious payload does not disappear after a single request.

Once the payload is saved in the database, it can execute repeatedly whenever the affected content is viewed.

In this case, the payload may persist as part of a WordPress comment. That creates several risks:

visitors may be attacked when reading the page;
logged-in users may trigger the payload while reviewing comments;
administrators may execute the payload while moderating or viewing affected content;
the attack may remain active until the malicious comment is removed;
cached pages may continue serving the payload even after cleanup if cache is not purged.

This persistence changes the operational impact. The attacker does not need to lure every victim individually. The vulnerable site itself becomes the delivery channel.

Understanding the CVSS score

CVE-2026–10092 has a CVSS 3.1 score of 7.2, classified as High.

The vector is:

AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N

This tells us several important things.

Attack Vector: Network The attack can be performed remotely over the network.

Attack Complexity: Low The conditions are not considered complex once the vulnerable configuration is present.

Privileges Required: None The attacker does not need a WordPress account.

User Interaction: None The attacker does not need a specific victim to perform a separate interaction like clicking a crafted link. Once the payload is stored, users who load the affected page may trigger it through normal browsing.

Scope: Changed The vulnerability crosses a security boundary because attacker-controlled content can execute in another user's browser context.

Confidentiality and Integrity: Low The vulnerability may allow limited data exposure or manipulation in the browser context.

Availability: None The issue is not primarily a denial-of-service vulnerability.

The key point is that this is not about taking the server offline. It is about injecting persistent client-side code into pages served by the WordPress site.

Potential impact

The impact depends on who views the affected page and what privileges they have.

If the payload executes in the browser of a normal visitor, an attacker may attempt to:

modify visible page content;
inject phishing elements;
redirect users;
load malicious external scripts;
steal data available to the browser;
manipulate links or forms;
damage the trustworthiness of the site.

If the payload executes in the browser of an authenticated WordPress user, the impact may become more serious.

For example, if an administrator views the affected page or comment, JavaScript may attempt to interact with WordPress functionality available to that administrator's session. The exact impact depends on nonces, browser protections, plugin configuration, WordPress hardening, and the user's role.

Stored XSS in WordPress should always be treated carefully because privileged users often browse public pages while logged in.

Why media plugins are attractive targets

Media plugins often process complex data.

They may handle:

gallery IDs;
remote media references;
video embeds;
player configurations;
playlist metadata;
layout options;
image captions;
user-defined titles;
HTML wrappers;
JavaScript initialization code.

This complexity makes output handling harder.

A value may start as a shortcode attribute, pass through plugin logic, become part of a JavaScript configuration object, then end up rendered in HTML. Each transformation changes the required escaping context.

That is where many XSS vulnerabilities appear.

A developer may escape a value for HTML text, but later use it inside an attribute. Or sanitize a value as a string, but later place it inside JavaScript. Or assume a value is trusted because it came from a shortcode.

The browser does not care about developer assumptions. If attacker-controlled data reaches an executable context, the payload can run.

No known patch: what should site owners do?

The remediation situation is important: there is no known patch available at the time of disclosure.

That means site owners should not simply wait for an automatic update.

Recommended actions:

Check whether Cincopa video and media plug-in is installed.
If installed, verify whether the version is 1.163 or earlier.
Consider disabling and removing the plugin until a patched version is available.
Replace it with a maintained alternative if the functionality is required.
Review comments on pages and posts that use or reference Cincopa shortcodes.
Search the database for suspicious [cincopa] shortcode usage inside comments.
Remove suspicious comments and purge page caches.
Temporarily disable comments if they are not needed.
Require moderation for all comments.
Restrict allowed markup in comments.
Use a Web Application Firewall as a compensating control.

Because the vulnerability is unauthenticated, public-facing sites with open comments are the highest priority.

If the plugin is inactive but still installed, removal is still recommended. Unused plugins increase long-term attack surface and are often forgotten during maintenance.

Detection ideas

Defenders can start with simple checks.

Search WordPress comments for shortcode patterns such as:

[cincopa

That alone does not prove compromise, because legitimate comments could theoretically contain shortcode text. But in many sites, shortcode usage inside comments is unusual and should be reviewed.

Site owners can also inspect:

recently submitted comments;
pending comments;
spam comments;
trashed comments;
pages with unexpected scripts;
unusual redirects;
modified cached HTML;
suspicious external JavaScript domains;
admin activity after viewing affected pages.

If exploitation is suspected, cleanup should include both the database and any caching layers.

Removing the malicious comment may not be enough if a page cache, CDN cache, or optimization plugin continues serving the old rendered page.

Lessons for WordPress developers

CVE-2026–10092 highlights a recurring WordPress security lesson:

Shortcodes are code-like behavior, not plain text.

If a plugin registers a shortcode, the developer must think carefully about where that shortcode can execute.

A shortcode that is safe in administrator-created pages may not be safe in comments, user bios, widgets, imported content, forum posts, or other user-controlled fields.

Developers should ask:

Can unauthenticated users reach this shortcode?
Can low-privileged users submit shortcode attributes?
Are attributes validated according to strict expectations?
Is output escaped at the last moment?
Is the correct escaping function used for the correct context?
Are values inserted into JavaScript, HTML attributes, URLs, or raw HTML?
Is shortcode processing enabled in areas that should only display text?

The safest approach is to avoid processing powerful shortcodes in untrusted content areas such as comments unless there is a strong reason and strict validation.

Lessons for security researchers

From a vulnerability research perspective, this bug is interesting because it appears at the intersection of three common WordPress surfaces:

shortcode processing;
comment rendering;
media/plugin output generation.

Each of these areas is already security-sensitive. Combined, they create a strong target for XSS testing.

When reviewing WordPress plugins, researchers should look for cases where a plugin adds shortcode processing to unexpected hooks such as comment output, widget text, custom fields, profile descriptions, or imported content.

The important question is not only "does the shortcode sanitize input?" but also "who can reach the shortcode?"

The same shortcode may be low-risk when only administrators can use it, but high-risk when unauthenticated users can trigger it through comments.

Final thoughts

CVE-2026–10092 is a clear example of how a convenience feature can become a persistent XSS vector.

The vulnerable plugin processes [cincopa] shortcodes in WordPress comments. Because comments can be submitted by unauthenticated visitors on many sites, the shortcode parser becomes exposed to untrusted input.

The result is an unauthenticated Stored Cross-Site Scripting vulnerability that can persist in the database and execute whenever affected pages are viewed.

For site owners, the safest action is to disable or remove the plugin until a secure patched version is available, review existing comments, and clean any suspicious shortcode usage.

For developers, the lesson is broader: never process plugin logic in untrusted content areas unless every input is strictly validated and every output is escaped for the exact browser context.

In WordPress security, the dangerous boundary is often not where users log in. It is where untrusted content becomes executable behavior.

Contents