Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSubmit crafted comment with script payload
-
DeliveryPayload stored unsanitized in comment DB
-
ExploitAdministrator approves innocuous-looking comment
-
ExecutionVisitor loads affected post
-
PersistStored script executes in victim browser
-
ImpactSession hijack or admin action abuse
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Output encoding, context-aware escaping
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the target site to run the DoFollow Case by Case plugin (version ≤3.6.0) with the public comment submission feature enabled, and the attacker injects the payload through the Comment Content field - no attacker authentication is needed (PR:N). The key LIMITING factor, explicit in the description, is comment moderation: a stored payload does not execute until an administrator approves the comment, so sites that auto-approve or weakly moderate comments are at materially higher risk than those enforcing manual review. Execution then occurs automatically for any subsequent visitor to the affected post (victim needs only to view the page), and impact is bounded to script execution in the browser context (C:L/I:L, no availability impact). |
| Impact | This is a genuine but moderate-priority issue rather than a critical emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N, base 7.2) describes a network-reachable, low-complexity, unauthenticated stored XSS with a scope change, which accounts for the elevated score. However, no EPSS probability was provided, the CVE is NOT listed in CISA KEV, and no public proof-of-concept is referenced in the supplied intelligence - so there is no public exploit identified at time of analysis. The CVSS vector marks PR:N and UI:N, but the description itself establishes a significant real-world limiting factor the base score does not fully capture: comment moderation. An administrator must approve the malicious comment before the payload becomes live, meaning exploitation depends on a human workflow step and is not fully automatable. SSVC-style framing: exploitation status is 'none' (no KEV/POC), automatable is effectively 'no' (requires admin approval to publish), technical impact is 'partial' (C:L/I:L, no availability loss). Net: a legitimate flaw worth patching on a normal cycle, but the combination of no confirmed exploitation, no POC, a niche plugin footprint, and a required moderation step argues against treating it as an urgent, widely-exploited threat. |
| Exploit ScenarioDerived | An unauthenticated attacker submits a blog comment on a post served by a site running DoFollow Case by Case (≤3.6.0), embedding a script payload in the comment content that is stored without adequate sanitization. The comment sits in the moderation queue appearing visually innocuous; once an administrator approves it, the stored script executes in the browser of every subsequent visitor to that post, enabling session/cookie theft or admin-targeted actions. No public exploit code is identified, and successful exploitation hinges on the comment passing manual moderation. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 02, 2026
Stored cross-site scripting in the DoFollow Case by Case WordPress plugin (all versions up to and including 3.6.0) allows unauthenticated attackers to inject arbitrary JavaScript through the public comment content field, with the payload persisting and executing in the browser of every subsequent visitor to the affected post once an administrator approves the comment. Exploitation requires the site to have public comment submission enabled and depends on a moderation workflow that approves the tainted comment - no attacker authentication is needed (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N, 7.2), and impact is bounded to script execution in victims' browsers with no availability impact. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; this is a genuine but moderate-priority issue whose practical risk is dictated by how permissive a site's comment moderation is.
RemediationAI
No patched release version is independently confirmed from the available data; the input includes a plugin Subversion changeset reference (https://plugins.trac.wordpress.org/changeset?reponame=&old=3721278%40dofollow-case-by-case&new=3721278%40dofollow-case-by-case), which indicates upstream fix activity - treat this as 'upstream fix available (changeset/commit); released patched version not independently confirmed' and verify on the WordPress plugin page whether a version newer than 3.6.0 has been published before upgrading. Until a fixed build is confirmed, the highest-value control is to eliminate the injection surface: disable public/anonymous comment submission on the site (Settings → Discussion, or use a plugin option/theme filter to require registration and log-in before commenting) and strip HTML and script-capable markup from all comment content via a comments-focused sanitization plugin or a comment_text/preprocess_comment filter that runs wp_kses with a strict allow-list; the trade-off is reduced community engagement and possible loss of legitimate formatting in comments. Note that manual comment moderation is only a partial mitigation, not a fix - the payload is not neutralized and will execute as soon as the comment is approved, so moderation must be combined with sanitization/escaping rather than relied on alone. If the site does not use the plugin's DoFollow Case by Case functionality, deactivate and remove the plugin entirely (the safest option, eliminating the affected code path but losing its link-attribute feature). Finally, a WAF or security plugin rule that blocks script/event-handler patterns in POST bodies to wp-comments-post.php adds defense in depth, though it can produce false positives on legitimate comment text.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause class is CWE-79 (Improper Neutralization of Input During Web Page Generation / cross-site scripting) in the WordPress plugin DoFollow Case by Case, published by Apasionados (CPE cpe:2.3:a:apasionados:dofollow_case_by_case, affected version range through 3.6.0 per the CPE wildcard and the ENISA EUVD record listing DoFollow Case by Case 0 ≤3.6.0). The plugin handles comment data and constructs markup around it, but fails to sanitize attacker-controlled comment content on input and/or escape it on output - the references point directly at the 3.6.0 source in the plugin's main file (dofollow-case-by-case.php lines 733, 748 and 797), which is where the unsanitized comment content is processed and rendered. Because WordPress stores comment text in the database and re-renders it on every page view, the injected script is persistent rather than reflected, and it renders in the context of the affected post for all visitors. The CVSS vector carries a Scope change (S:C), reflecting that the injected script can act beyond the vulnerable component's own privilege boundary - modifying page content or performing actions in the victim's authenticated session on the wider site - while Confidentiality and Integrity are limited (C:L/I:L) and Availability is unaffected (A:N).
Know when Dofollow Case By Case gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
Network-reachable unauthenticated comment injection (AV:N/PR:N); scope change (S:C) as script runs in visitors' browser context with limited confidentiality/integrity impact and no availability loss.
Primary rating from Vendor (Wordfence).
CVSS VectorVendor: Wordfence
DescriptionCVE.org
The DoFollow Case by Case plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Comment Content in all versions up to, and including, 3.6.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. Comment moderation delays but does not prevent exploitation - once an administrator approves the visually innocuous comment, the stored payload executes in the browser of every subsequent visitor to the affected post.
Executive ViewAI
The DoFollow Case by Case WordPress plugin, present on our public-facing websites up to version 3.6.0, contains a high-severity vulnerability that allows unauthenticated attackers to inject malicious scripts via comments, which can then execute in the browsers of every visitor to an affected post once an administrator approves the comment. This could lead to theft of visitor data, session hijacking, or defacement, damaging customer trust and our brand reputation. With no vendor-released patch identified at time of analysis, leadership should prioritize implementing interim mitigations to secure our web properties and protect our users.
Disable public comment submission or restrict commenting to authenticated users; disable the DoFollow Case by Case plugin if not essential; implement WAF rules to filter malicious input; enforce strict manual comment moderation; use security plugins to sanitize comment content.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.
More in Dofollow Case By Case
View allImproper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in apasionados DoFoll
Cross-Site Request Forgery (CSRF) vulnerability in Apasionados, Apasionados del Marketing, NetConsulting DoFollow Case b
Cross-Site Request Forgery (CSRF) vulnerability in apasionados DoFollow Case by Case allows Cross Site Request Forgery.5
EUVD-2026-91242
GHSA-3hqm-f925-jf2f
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB