প্লাগইনের নাম	addfreespace
দুর্বলতার ধরণ	সিএসআরএফ
সিভিই নম্বর	CVE-2026-6701
জরুরি অবস্থা	কম
সিভিই প্রকাশের তারিখ	2026-05-04
উৎস URL	CVE-2026-6701

Cross-Site Request Forgery (CSRF) chained to Stored Cross‑Site Scripting (XSS) in addfreespace <= 0.1.3 — What WordPress Site Owners Must Know and Do

A recently disclosed vulnerability impacting the addfreespace WordPress plugin (versions <= 0.1.3) has been assigned CVE‑2026‑6701. The vulnerability is a CSRF (Cross‑Site Request Forgery) issue that can be chained into a stored XSS (Cross‑Site Scripting) condition. While the overall CVSS rating is relatively low (4.3), the real-world risk can be higher than the number suggests — especially when attackers target sites in mass campaigns or rely on tricking privileged users into interacting with a crafted link or page.

As the security team for WP‑Firewall, we want to explain, in plain language and with specific guidance, what this issue means, how it can be abused, how to detect exploitation, and — most importantly — what you can do right now to protect your sites. This guide is written for site owners, administrators, developers and hosting teams.

---

নির্বাহী সারসংক্ষেপ (দ্রুত গ্রহণযোগ্যতা)

• A vulnerability in addfreespace (<= 0.1.3) allows an attacker to submit requests that are not protected against CSRF. If a privileged user (administrator or other high‑privileged role) is tricked into visiting a malicious page or clicking a malicious link, the attacker can store JavaScript payloads in the site (stored XSS).
• Stored XSS executed in an admin context can lead to account takeover, privilege escalation, data theft, or installing persistent backdoors.
• There is no official plugin patch available at publication time. Immediate mitigations are strongly advised.
• Recommended immediate actions: deactivate or remove the plugin; restrict access to plugin administration pages; apply WAF rules or virtual patches; scan for injected scripts and suspicious modifications; reset admin credentials and rotate keys; and implement longer‑term hardening.
• WP‑Firewall users can apply virtual patching, managed WAF rules and active scanning to reduce risk immediately.

---

Why CSRF chained with stored XSS is dangerous (in human terms)

CSRF and XSS are different attack types, but when combined they become powerful:

• CSRF: CSRF: An attacker tricks a logged‑in user (often an administrator) into performing an action they didn’t intend — for example, by getting them to click a link or visit a web page that makes a request to the vulnerable site. Properly coded WordPress admin actions include nonce checks and capability checks to prevent this. In this case, the plugin failed to properly validate the origin/nonce.
• সংরক্ষিত XSS: If an attacker can cause arbitrary JavaScript to be saved in the website’s database (e.g., in a plugin option or custom field), that code will run whenever the stored content is displayed in the admin or frontend context without proper escaping.

চেইনিং: An unauthenticated attacker crafts a page that submits a POST/GET to the vulnerable plugin endpoint in the background or when a site admin visits. If the plugin stores the attacker’s JavaScript payload (and later displays it without escaping), the payload executes in the context of the admin’s browser. From there an attacker can steal authentication cookies, perform actions as that user (create posts, install plugins/themes, export data), and establish persistent access.

Even if an attacker needs the admin to perform one interaction (e.g., click a link), that single click can be all they need to pivot to a full compromise.

---

Technical root causes (what went wrong)

From the reported details and typical exploit patterns, the chain usually indicates the following failures in plugin code:

1. Missing CSRF protection
   • No use of WordPress nonces (e.g., wp_create_nonce / check_admin_referer) for state‑changing actions.
   • No validation of request origin or referer header to ensure the request came from a trusted admin interface.
2. Insufficient capability checking
   • Plugin endpoints may not have proper user capability checks (current_user_can) or enforce the appropriate capability for the task.
3. Missing or insufficient data sanitization and output escaping
   • Dangerous user‑supplied data is saved to the database without sanitizing (e.g., using sanitize_text_field, wp_kses_post) and is output later without escaping (e.g., esc_html, esc_attr, or proper kses filtering).
4. Admin interfaces exposing writeable endpoints accessible via unauthenticated HTTP methods
   • Action hooks or AJAX endpoints that accept POST requests without proper protections.

The net result: an attacker can trigger a state change (store content) using a victim’s browser, and the stored content can later be rendered and executed.

---

How an attack would typically play out (high level)

1. Attacker identifies the vulnerable plugin endpoint (for example, an admin action URL used by addfreespace).
2. Attacker crafts a web page that makes a POST (or GET) to that endpoint with a payload containing JavaScript (a stored XSS vector). The form submission includes the parameters expected by the plugin.
3. An administrator (or another privileged user) visits the malicious page or clicks a link while authenticated to the vulnerable WordPress site.
4. Because the plugin lacks CSRF protection, the request is accepted and the malicious JavaScript is saved in the database (e.g., in an option, post meta, or plugin‑controlled field).
5. When the site (or the admin page) later displays that stored value without sanitization/escaping, the JavaScript executes in the context of the admin’s browser.
6. The JavaScript can then:
   • Read cookies or local storage (and exfiltrate them);
   • Make authenticated requests using the admin’s credentials (e.g., create new admin users, install plugins);
   • Load external scripts to run further actions or to maintain persistence.

বিঃদ্রঃ: The key step is the privileged user performing an action (e.g., visiting a page). Without that interaction, CSRF cannot normally be triggered. That said, many admins click on links or open pages, and threat actors exploit that behavior at scale.

---

Impact — what attackers can achieve

Stored XSS executed in an administrative browser session can enable:

• Account takeover (steal session cookies or OAuth tokens).
• Creation of new administrative users.
• Installation of backdoors (malicious plugins/themes) or scheduled tasks that maintain persistence.
• Data exfiltration: export of posts, media, or user data.
• Defacement of the site or injection of drive‑by malware to infect visitors.
• Pivoting to hosting control or database access via further exploitation.

Although the CVSS is low, the business impact can be severe if the attacker achieves persistence or takes over a production site.

---

Immediate actions you must take (incident‑response style)

If you run WordPress sites that use addfreespace (<= 0.1.3), treat the situation as urgent:

1. Deactivate the plugin now
   • Log into wp-admin and deactivate addfreespace. If you cannot access wp-admin, rename the plugin folder via SFTP/SSH (wp-content/plugins/addfreespace -> addfreespace.disabled).
2. Remove the plugin
   • If you don’t strictly need it, remove it from the codebase. Sometimes removing the plugin is the safest short‑term option until a patched version is released.
3. Put the site into maintenance mode while you investigate
   • Reduce the attack surface while you scan.
4. অবিলম্বে WAF/ভার্চুয়াল প্যাচিং প্রয়োগ করুন।
   • Block requests to the plugin’s admin endpoints and disallow suspicious POSTs containing script-like payloads.
   • If you use WP‑Firewall, enable the managed WAF ruleset and virtual patching for this vulnerability to block exploitation attempts even while the plugin remains present.
5. Scan for injected payloads and suspicious DB entries
   • Search posts, options, usermeta, and other storage for <script, ত্রুটি =, লোড হলে, or other JS event handlers that look unexpected.
   • Example (defensive, run as admin via WP‑CLI or database client):
     • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'"
     • wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%'"
   • বিঃদ্রঃ: The exact queries above assume standard table prefixes. Adjust for custom prefixes and production safety.
6. শংসাপত্র এবং গোপনীয়তাগুলি ঘোরান
   • সমস্ত প্রশাসক ব্যবহারকারীদের জন্য পাসওয়ার্ড পুনরায় সেট করুন।.
   • Rotate API keys, service account credentials, and keys in wp-config.php যদি আপনি আপসের সন্দেহ করেন।.
7. ব্যবহারকারী অ্যাকাউন্ট এবং ভূমিকা পর্যালোচনা করুন
   • Look for unexpected administrator accounts or users with elevated privileges.
8. সার্ভার এবং অ্যাক্সেস লগ পর্যালোচনা করুন
   • Inspect webserver logs and audit trails for suspicious POSTs or requests to plugin endpoints.
9. Restore from a known good backup if you detect changes that you cannot safely clean
   • If you find backdoors or unexplained modifications, a clean restore may be the fastest remediation.
10. প্রশাসক অ্যাক্সেস শক্তিশালী করুন
    • Enforce 2‑factor authentication (2FA) for all privileged accounts.
    • Limit admin area access by IP if possible.
    • Use strong, unique passwords and an account lockout policy.

---

How to detect a stored XSS from this vulnerability (indicators of compromise)

Look for the following signs:

• Unexpected JavaScript in posts, pages, options or widget content.
• New admin users or unexpected changes in user roles.
• Admin interface content that displays strange alerts, popups or redirects.
• Outgoing requests from the site to unfamiliar third‑party domains (indicating exfiltration or callback).
• Server logs showing POSTs to plugin endpoints from unusual referrers or user agents.
• Elevated CPU or cron jobs scheduled unexpectedly (indicating backdoors).

Helpful defensive checks:

• WP‑CLI search for script tags in posts and options:
  • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'" --limit=100
  • wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%'" --limit=100
• Scan with a trusted malware scanner (site-side or host-level) to detect known backdoors and webshells.
• Compare current files against a clean snapshot or the plugin’s original distributed files to find altered files.

When you find suspicious content, isolate it and do not execute it in a live browser. Treat it as malicious until proven otherwise.

---

Code‑level remediation guidance for developers

If you maintain the plugin or develop themes/plugins, these are the essential defensive coding practices to follow to prevent both CSRF and stored XSS:

1. Use nonces and verify them on every state‑changing request
   • When generating a form or a link that performs a state change:

     $nonce = wp_create_nonce( 'my_plugin_action' );

     Include it in forms or AJAX:

     <input type="hidden" name="_wpnonce" value="<?php echo esc_attr( $nonce ); ?>" />

   • On request handling:

     check_admin_referer( 'my_plugin_action' ); // or check_ajax_referer for AJAX

2. ব্যবহারকারীর সক্ষমতা পরীক্ষা করুন
   • Before performing actions, verify:

     if ( ! current_user_can( 'manage_options' ) ) { wp_die( 'অপর্যাপ্ত অনুমতি' ); }

3. Sanitize input before saving
   • Use appropriate sanitizers:
     • sanitize_text_field(), sanitize_email(), intval(), floatval()
     • For HTML input: wp_kses_post() or wp_kses() with a safe allowed list
4. আউটপুটে পলায়ন
   • Always escape data when printing:
     • esc_html(), esc_attr(), wp_kses_post() depending on context.
5. Use the REST API and check permission callbacks
   • For REST endpoints, implement permission_callback that verifies capabilities and nonces.
6. Validate expected data types and lengths
   • Enforce maximum lengths and allowed characters.

Example (defensive pseudo‑code):

// In the form:
wp_nonce_field( 'my_plugin_save_settings', '_wpnonce', true );

// In the submit handler:
if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'Unauthorized' );
}
check_admin_referer( 'my_plugin_save_settings' );

$clean_value = sanitize_text_field( $_POST['my_setting'] );
update_option( 'my_plugin_setting', $clean_value );

For HTML input that needs to allow limited tags:

$allowed = array(
  'a' => array( 'href' => true, 'title' => true, 'rel' => true ),
  'strong' => array(),
  'em' => array(),
  'p' => array(),
);

$clean_html = wp_kses( $_POST['custom_html'], $allowed );
update_option( 'my_plugin_custom_html', $clean_html );

---

WAF and virtual patching — practical rules to deploy now

If you have a WAF (application firewall) such as WP‑Firewall, you can create defensive rules that block exploitation attempts even before an official plugin patch is released. Consider the following high‑level approaches:

1. Block suspicious POST/GET contents to plugin endpoints
   • Create a rule to inspect requests targeting plugin admin actions or plugin files. If the request body contains script tags or common XSS event handlers (onerror, onload, javascript:) block the request.
2. Enforce referer or origin presence for admin POSTs
   • Block or challenge (CAPTCHA) POSTs to wp-admin/admin-post.php, admin-ajax.php, or plugin-specific endpoints that do not include a valid referer or _wpnonce parameter.
3. Rate‑limit and challenge anonymous requests to administrative endpoints
   • Many exploit attempts are automated. Rate limiting reduces large automated attacks.
4. Virtual patching: intercept known exploit patterns
   • Block requests matching the exact parameter names or URL patterns used by the vulnerable plugin when containing suspicious content.
5. Block requests that try to create/modify options with script content
   • If a request attempts to update wp_options or fields commonly used by the plugin with <script in payload, block it.

Example of a conceptual firewall rule (pseudo):

IF request.path MATCHES "/wp-admin/admin-post.php" OR "/wp-admin/*addfreespace*" AND request.method IN (POST, GET) THEN
  IF request.body CONTAINS "<script" OR "onerror=" OR "javascript:" THEN BLOCK

নোট:

• Avoid overly broad rules that could result in false positives. Test in monitor mode first.
• Use rules combined with logging and alerts so you can adapt quickly.

If you are a WP‑Firewall user, enable the managed ruleset that targets CSRF/XSS exploitation patterns and enable virtual patching for addfreespace vulnerabilities. This provides immediate protection while you follow longer‑term remediation.

---

Post‑remediation checklist (what to do after you remove the plugin or apply a patch)

1. Confirm the plugin is removed or updated to a patched version when available.
2. Re-scan the entire site for malicious code, webshells, and modified files.
3. Review the database for stored payloads and remove or sanitize them.
4. Rotate credentials: admin passwords, SSH keys, API keys.
5. Reissue any leaked tokens or keys that may have been exposed.
6. Restore a clean backup if you cannot fully ensure the site is clean.
7. Monitor logs and intrusion detection for repeat attempts.
8. Document the incident, your actions, and any lessons learned.

---

How to communicate to clients and stakeholders (if you manage other sites)

• Brief and factual: explain the plugin affected, the versions, the risk level, and the actions you’ve taken (deactivated/removed, scanned, implemented WAF rules).
• Provide reassurance: list exact mitigations (WAF rules in place, scanning completed, credentials rotated, backups used).
• Provide guidance: instruct end users to change passwords if they logged in during the window of exposure, and to watch for suspicious activity.
• Offer follow‑up: schedule a full security review if any indicators of compromise are found.

---

Hardening checklist that should be standard practice (preventing similar issues)

• Enforce 2FA for every administrative account.
• Limit admin area access via IP allowlist where feasible.
• wp-admin এ ফাইল সম্পাদনা নিষ্ক্রিয় করুন:

  সংজ্ঞায়িত করুন ( 'DISALLOW_FILE_EDIT', সত্য );

• Enforce the principle of least privilege: give users only the capabilities they absolutely need.
• WordPress কোর, থিম এবং প্লাগইন আপডেট রাখুন।.
• Install and run a reputable site scanner and a managed WAF.
• Use strong, unique passwords and a centralized secret management policy.
• Backup daily (or more frequently) with immutable backups stored offsite.
• Review plugin code before installing plugins from unknown authors or low‑download items.

---

If you find suspicious JavaScript in your DB — safe cleanup guidance

• Do not visit pages that render the suspicious content in an admin browser session before cleaning.
• Export the suspicious row(s) from the DB to a safe quarantine area and analyze them offline or on an isolated machine.
• Remove or sanitize entries using safe functions (wp_update_post with sanitized content, update_option with sanitized content).
• If you’re uncertain about the extent of compromise, restore from a verified clean backup and reapply patches and hardening.

---

Why low CVSS doesn’t mean “no big deal”

Automated mass exploitation and social engineering rely on chained, low‑complexity steps. A vulnerability that requires “only” that an admin click a link can be extremely powerful when attackers send tens of thousands of phishing emails or compromise other websites to embed the exploit. Stored XSS executed under an admin context is particularly sensitive. Treat vulnerabilities with a practical risk assessment: ease of exploitation, number of affected sites, and the potential gain for the attacker. In many cases, immediate virtual patching and plugin removal are prudent even for low CVSS scores.

---

Quick incident response playbook (one page)

1. Deactivate plugin (or rename plugin folder).
2. Enable maintenance mode and block traffic if necessary.
3. Enable WAF/virtual patch rules for the plugin.
4. Scan database for script tags and suspicious entries; quarantine found items.
5. Scan filesystem for modified files and webshells.
6. প্রশাসক পাসওয়ার্ড এবং API কী পরিবর্তন করুন।.
7. Review logs and user accounts.
8. প্রয়োজন হলে পরিষ্কার ব্যাকআপ থেকে পুনরুদ্ধার করুন।.
9. Harden admin access (2FA, IP allowlist).
10. Reintroduce plugin only when patched and after full QA.

---

Try the WP‑Firewall Basic (Free) plan — Essential protection without the price tag

If you’re looking for immediate, practical protection while you follow the steps above, consider signing up for the WP‑Firewall Basic (Free) plan. It includes essential protections that help block exploitation attempts and rapidly reduce your exposure:

• পরিচিত শোষণ প্যাটার্ন ব্লক করতে পরিচালিত ফায়ারওয়াল এবং WAF
• Unlimited bandwidth — the firewall doesn’t throttle your traffic
• Malware scanner to detect common backdoors and malicious payloads
• Mitigation for OWASP Top 10 risks to reduce common attack vectors

You can register for the free plan and deploy these protections quickly at: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

WP‑Firewall এর নিরাপত্তা দলের শেষ কথা

Vulnerabilities like the addfreespace CSRF→stored‑XSS chain are a reminder that even small or niche plugins can introduce outsized risk. The good news: you can take effective action right away. Deactivate or remove the plugin, apply WAF rules and virtual patches, scan for injections, rotate credentials, and harden administrative access. If you manage multiple websites (as an agency or host), automate scanning and virtual patching to reduce the window of exposure across all sites.

We’re committed to helping site owners reduce risk quickly and confidently. If you need hands‑on assistance, threat hunting or tailored virtual patching rules, WP‑Firewall is available to support cleanup and long‑term defense.

Stay safe, and prioritize rapid mitigation when a vulnerability is disclosed — the time between disclosure and active exploitation is often shorter than you expect.

— WP-ফায়ারওয়াল সিকিউরিটি টিম

---

Appendix: Quick reference commands (defensive)

• Search for script tags in posts (adjust table prefix if necessary):

  wp db কোয়েরি "wp_posts থেকে ID, post_title নির্বাচন করুন যেখানে post_content '%' এর মতো

• Search wp_options for script-like content:

  wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%';"

• List recently modified files (last 7 days) on a UNIX host:

  find /path/to/wordpress -type f -mtime -7 -print

Remember: run these commands only with appropriate access and backups, and avoid exposing the site to further risk while investigating.