WordPress site owners have had a rough year with the Super Forms – Drag & Drop Form Builder plugin. In July 2026, researchers disclosed a critical unauthenticated file-upload flaw (CVE-2026-14894) that attackers began exploiting within days — security teams ultimately blocked more than 250,000 exploit attempts against it. Now, on October 8, 2026, a second critical vulnerability has surfaced in the same plugin: CVE-2026-17609, an unauthenticated arbitrary directory deletion flaw rated CVSS 9.1. An attacker with no account on your site can recursively delete any directory on the server — including the entire WordPress installation. Here is the full analysis.
Summary
CVE-2026-17609 affects the Super Forms – Drag & Drop Form Builder plugin for WordPress (vendor: Rens Tillmann / WebRehab), a form builder with an estimated 13,000+ active installations. The plugin's submit_form function fails to properly validate attacker-controlled JSON field declarations against the actual form schema, and a path guard meant to confine file operations inside the WordPress directory can be trivially bypassed. The result is that an unauthenticated attacker can recursively delete arbitrary directories on the server.
- CVE ID: CVE-2026-17609 (assigned by Wordfence; reserved July 27, 2026)
- Product: Super Forms – Drag & Drop Form Builder for WordPress
- Severity: CVSS 9.1 — Critical
- Disclosed: October 8, 2026; record updated October 10, 2026
- Exploitation: No public proof of concept confirmed; not in CISA KEV — but this plugin has a proven history of fast mass exploitation
- Fix: Update to 6.3.317 or later (stable line)
One important precondition: exploitation requires that an administrator has enabled the plugin's "Delete files from server after form submissions" setting. That is a documented, commonly-enabled feature — sites using Super Forms for job applications, support tickets, or any workflow with file uploads frequently turn it on to avoid disk bloat. If that setting is on and you are running 6.3.316 or earlier, you are exposed.
Severity
CVE-2026-17609 is rated CVSS 9.1 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H:
- Attack Vector: Network (AV:N) — any visitor who can reach a form on your site can attempt this.
- Attack Complexity: Low (AC:L) — no special conditions beyond the enabled setting.
- Privileges Required: None (PR:N) — unauthenticated. This is the detail that turns a bad bug into a critical one.
- User Interaction: None (UI:N) — the site owner does not need to do anything.
- Confidentiality: None (C:N) — this flaw does not directly read data, which is why it scores 9.1 instead of 9.8+.
- Integrity / Availability: High — the attacker can destroy data and take the site offline permanently.
Do not let the "no confidentiality impact" fool you into deprioritizing this. A vulnerability that lets a stranger delete your entire website — files, uploads, and potentially the database-adjacent content the application needs to run — is a business-ending event for a small site without backups. Integrity and availability at "High" with zero authentication is exactly the profile that gets mass-exploited by bots within days of disclosure.
Affected Versions
- Super Forms – Drag & Drop Form Builder 6.3.316 and earlier — affected
- Fixed in 6.3.317 (stable line), per the vendor's security release notes
- The 6.4 beta line received the same hardening in 6.4.008
The vendor's release notes for the security update confirm that this arbitrary directory deletion flaw was fixed on the stable line in 6.3.317, alongside fixes for an unauthenticated file read (CVE-2026-28167) and an upload extension bypass (CVE-2026-17196). If you are updating, go to the latest available release rather than stopping at 6.3.317 — the vendor hardened a long list of other file-handling paths in the same release, and you want all of it.
Technical Analysis
This is a beautifully ugly bug — the kind where two individually questionable decisions combine into something catastrophic. Let me walk through both halves.
Half 1: trusting the attacker's description of the form
When a visitor submits a Super Forms form, the browser sends the form data — including a JSON structure describing which fields were submitted and, for file-upload fields, where the uploaded files should go. The submit_form handler is supposed to check that JSON against the actual form definition stored on the server: "does this form really have a file field, and is this the directory that field is configured to use?"
In the vulnerable versions, that validation is insufficient. The server accepts the attacker's JSON field declarations at face value instead of strictly reconciling them with the form schema. Concretely, the request can smuggle a subdir value inside the file-upload parameters (the data[...][files][][subdir] parameter) that points somewhere the form was never configured to touch. The server trusts the attacker's map of the form instead of its own.
This is a classic instance of a principle every web developer should tattoo on their forearm: never trust client-supplied metadata about server-side resources. The browser is the attacker's computer. Anything it says about which directories exist or where files should be written is a suggestion, not a fact — and the server must re-derive it from its own configuration.
Half 2: the guard that guards nothing
The plugin did have a safety check: before deleting, it verified that the target path was inside the WordPress installation directory by comparing against the ABSPATH constant. In theory, even a smuggled subdir could only point somewhere under the site root — annoying, but contained.
In practice, the guard was defeated by PHP's dirname() function and a trailing slash. ABSPATH in WordPress ends with a trailing slash, and the guard's comparison depended on that exact form. Passing the path through dirname() strips the trailing slash, so the comparison against the expected ABSPATH value no longer matches the way the developer assumed — and the check that was supposed to confine deletions to the site directory is bypassed. The attacker-controlled path sails through, and the recursive deletion routine happily walks anywhere on the filesystem the web-server user can reach.
Either half alone would be a moderate bug. Together, they are critical: the attacker both chooses the directory (half 1) and escapes the containment (half 2).
Attack scenario
The attack needs nothing but a Super Forms form on the target site and the "delete files after submission" setting enabled. The attacker submits the form with a crafted request: the JSON field declarations include a file-upload entry whose subdir parameter traverses to the target directory — and because the guard is bypassed, that target can be the WordPress root itself, the uploads directory, the plugin directory, or anything else the PHP process can write to.
When the form processes, the plugin's cleanup routine recursively deletes the directory. Against the WordPress root, that is total site destruction: core files, themes, plugins, uploads — gone in one request, from an unauthenticated visitor. There is no ransom note, no defacement, no exfiltration. The site simply ceases to exist. Recovery means restoring from backups, and sites without tested backups are starting from zero.
Note the asymmetry that makes this a mass-exploitation candidate: the attack is a single HTTP request, it requires no authentication, and the precondition (the delete-files setting) is common on exactly the kinds of sites that use file-upload forms — job boards, support desks, contest entries. Bots can scan for the plugin version, check the setting indirectly, and fire.
Why the history of this plugin matters
Context turns this from "patch it" into "patch it today." In July 2026, this same plugin had CVE-2026-14894 — an unauthenticated arbitrary file upload leading to remote code execution. Attackers began exploiting it on July 14, 2026, the same day firewall rules shipped, and Wordfence's firewall alone blocked over 250,000 exploit attempts, with dropped webshells carrying "Mushr00w" branding linked to a group known for government-site defacements.
That history tells you three things. First, this plugin is actively watched by attackers — it is on the target lists, and new CVEs in it get attention fast. Second, the plugin's file-handling code has now produced multiple critical unauthenticated flaws in four months, which suggests the file-handling layer needed the deep hardening the vendor says it applied — and you should not assume 6.3.317 is the last security release you will need. Third, the 250,000 blocked attempts prove that WordPress plugin exploits at this severity get industrialized within days. The window between disclosure and mass scanning is measured in hours, not weeks.
Mitigation
- Update Super Forms to 6.3.317 or later immediately. This is the single action that fixes CVE-2026-17609. Do not stop at 6.3.317 if a newer release exists — the vendor's security release hardened many adjacent file-handling paths, and you want the complete set.
- Turn off "Delete files from server after form submissions" until you have confirmed you are on a patched version. This setting is the exploit precondition; disabling it removes the attack path even on vulnerable code. Re-enable it only after updating, and only if your workflow genuinely needs it.
- Put a web application firewall in front of the site. Wordfence (free or premium) and similar WAFs ship virtual patches for flaws like this. Given this plugin's exploitation history, a WAF is cheap insurance while you verify every site in your portfolio is updated.
- Verify your backups — then verify you can restore them. A directory-deletion flaw is the scenario backups exist for. Confirm that recent, complete backups exist and that you have actually tested restoring one. A backup you have never restored is a hope, not a plan.
-
Check for signs of prior exploitation. Review access logs for unusual
admin-ajax.phprequests hitting the form-submission action, and check for recently deleted or missing directories. If the site was running a vulnerable version with the setting enabled while exposed to the internet, assume the worst until the logs say otherwise. - Audit every WordPress site you manage for this plugin. With 13,000+ installs and a history of mass exploitation, check all of your sites — not just the one you are thinking of right now.
References
- Super Forms security release notes (GitHub) — fixes for CVE-2026-17609 on the 6.3 and 6.4 lines
- StackFlag — CVE-2026-17609 vulnerability details
- TheHackerWire — CVE-2026-17609 analysis
- NVD entry for CVE-2026-17609 (nvd.nist.gov)
Report by Faizan Akhtar — The Cyber Security Researcher
WordPress site owners have had a rough year with the Super Forms – Drag & Drop Form Builder plugin. In July 2026, researchers disclosed a critical unauthenticated file-upload flaw (CVE-2026-14894) that attackers began exploiting within days — security teams ultimately blocked more than 250,000 exploit attempts against it. Now, on October 8, 2026, a second critical vulnerability has surfaced in the same plugin: CVE-2026-17609, an unauthenticated arbitrary directory deletion flaw rated CVSS 9.1. An attacker with no account on your site can recursively delete any directory on the server — including the entire WordPress installation. Here is the full analysis.
Summary
CVE-2026-17609 affects the Super Forms – Drag & Drop Form Builder plugin for WordPress (vendor: Rens Tillmann / WebRehab), a form builder with an estimated 13,000+ active installations. The plugin's submit_form function fails to properly validate attacker-controlled JSON field declarations against the actual form schema, and a path guard meant to confine file operations inside the WordPress directory can be trivially bypassed. The result is that an unauthenticated attacker can recursively delete arbitrary directories on the server.
- CVE ID: CVE-2026-17609 (assigned by Wordfence; reserved July 27, 2026)
- Product: Super Forms – Drag & Drop Form Builder for WordPress
- Severity: CVSS 9.1 — Critical
- Disclosed: October 8, 2026; record updated October 10, 2026
- Exploitation: No public proof of concept confirmed; not in CISA KEV — but this plugin has a proven history of fast mass exploitation
- Fix: Update to 6.3.317 or later (stable line)
One important precondition: exploitation requires that an administrator has enabled the plugin's "Delete files from server after form submissions" setting. That is a documented, commonly-enabled feature — sites using Super Forms for job applications, support tickets, or any workflow with file uploads frequently turn it on to avoid disk bloat. If that setting is on and you are running 6.3.316 or earlier, you are exposed.
Severity
CVE-2026-17609 is rated CVSS 9.1 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H:
- Attack Vector: Network (AV:N) — any visitor who can reach a form on your site can attempt this.
- Attack Complexity: Low (AC:L) — no special conditions beyond the enabled setting.
- Privileges Required: None (PR:N) — unauthenticated. This is the detail that turns a bad bug into a critical one.
- User Interaction: None (UI:N) — the site owner does not need to do anything.
- Confidentiality: None (C:N) — this flaw does not directly read data, which is why it scores 9.1 instead of 9.8+.
- Integrity / Availability: High — the attacker can destroy data and take the site offline permanently.
Do not let the "no confidentiality impact" fool you into deprioritizing this. A vulnerability that lets a stranger delete your entire website — files, uploads, and potentially the database-adjacent content the application needs to run — is a business-ending event for a small site without backups. Integrity and availability at "High" with zero authentication is exactly the profile that gets mass-exploited by bots within days of disclosure.
Affected Versions
- Super Forms – Drag & Drop Form Builder 6.3.316 and earlier — affected
- Fixed in 6.3.317 (stable line), per the vendor's security release notes
- The 6.4 beta line received the same hardening in 6.4.008
The vendor's release notes for the security update confirm that this arbitrary directory deletion flaw was fixed on the stable line in 6.3.317, alongside fixes for an unauthenticated file read (CVE-2026-28167) and an upload extension bypass (CVE-2026-17196). If you are updating, go to the latest available release rather than stopping at 6.3.317 — the vendor hardened a long list of other file-handling paths in the same release, and you want all of it.
Technical Analysis
This is a beautifully ugly bug — the kind where two individually questionable decisions combine into something catastrophic. Let me walk through both halves.
Half 1: trusting the attacker's description of the form
When a visitor submits a Super Forms form, the browser sends the form data — including a JSON structure describing which fields were submitted and, for file-upload fields, where the uploaded files should go. The submit_form handler is supposed to check that JSON against the actual form definition stored on the server: "does this form really have a file field, and is this the directory that field is configured to use?"
In the vulnerable versions, that validation is insufficient. The server accepts the attacker's JSON field declarations at face value instead of strictly reconciling them with the form schema. Concretely, the request can smuggle a subdir value inside the file-upload parameters (the data[...][files][][subdir] parameter) that points somewhere the form was never configured to touch. The server trusts the attacker's map of the form instead of its own.
This is a classic instance of a principle every web developer should tattoo on their forearm: never trust client-supplied metadata about server-side resources. The browser is the attacker's computer. Anything it says about which directories exist or where files should be written is a suggestion, not a fact — and the server must re-derive it from its own configuration.
Half 2: the guard that guards nothing
The plugin did have a safety check: before deleting, it verified that the target path was inside the WordPress installation directory by comparing against the ABSPATH constant. In theory, even a smuggled subdir could only point somewhere under the site root — annoying, but contained.
In practice, the guard was defeated by PHP's dirname() function and a trailing slash. ABSPATH in WordPress ends with a trailing slash, and the guard's comparison depended on that exact form. Passing the path through dirname() strips the trailing slash, so the comparison against the expected ABSPATH value no longer matches the way the developer assumed — and the check that was supposed to confine deletions to the site directory is bypassed. The attacker-controlled path sails through, and the recursive deletion routine happily walks anywhere on the filesystem the web-server user can reach.
Either half alone would be a moderate bug. Together, they are critical: the attacker both chooses the directory (half 1) and escapes the containment (half 2).
Attack scenario
The attack needs nothing but a Super Forms form on the target site and the "delete files after submission" setting enabled. The attacker submits the form with a crafted request: the JSON field declarations include a file-upload entry whose subdir parameter traverses to the target directory — and because the guard is bypassed, that target can be the WordPress root itself, the uploads directory, the plugin directory, or anything else the PHP process can write to.
When the form processes, the plugin's cleanup routine recursively deletes the directory. Against the WordPress root, that is total site destruction: core files, themes, plugins, uploads — gone in one request, from an unauthenticated visitor. There is no ransom note, no defacement, no exfiltration. The site simply ceases to exist. Recovery means restoring from backups, and sites without tested backups are starting from zero.
Note the asymmetry that makes this a mass-exploitation candidate: the attack is a single HTTP request, it requires no authentication, and the precondition (the delete-files setting) is common on exactly the kinds of sites that use file-upload forms — job boards, support desks, contest entries. Bots can scan for the plugin version, check the setting indirectly, and fire.
Why the history of this plugin matters
Context turns this from "patch it" into "patch it today." In July 2026, this same plugin had CVE-2026-14894 — an unauthenticated arbitrary file upload leading to remote code execution. Attackers began exploiting it on July 14, 2026, the same day firewall rules shipped, and Wordfence's firewall alone blocked over 250,000 exploit attempts, with dropped webshells carrying "Mushr00w" branding linked to a group known for government-site defacements.
That history tells you three things. First, this plugin is actively watched by attackers — it is on the target lists, and new CVEs in it get attention fast. Second, the plugin's file-handling code has now produced multiple critical unauthenticated flaws in four months, which suggests the file-handling layer needed the deep hardening the vendor says it applied — and you should not assume 6.3.317 is the last security release you will need. Third, the 250,000 blocked attempts prove that WordPress plugin exploits at this severity get industrialized within days. The window between disclosure and mass scanning is measured in hours, not weeks.
Mitigation
- Update Super Forms to 6.3.317 or later immediately. This is the single action that fixes CVE-2026-17609. Do not stop at 6.3.317 if a newer release exists — the vendor's security release hardened many adjacent file-handling paths, and you want the complete set.
- Turn off "Delete files from server after form submissions" until you have confirmed you are on a patched version. This setting is the exploit precondition; disabling it removes the attack path even on vulnerable code. Re-enable it only after updating, and only if your workflow genuinely needs it.
- Put a web application firewall in front of the site. Wordfence (free or premium) and similar WAFs ship virtual patches for flaws like this. Given this plugin's exploitation history, a WAF is cheap insurance while you verify every site in your portfolio is updated.
- Verify your backups — then verify you can restore them. A directory-deletion flaw is the scenario backups exist for. Confirm that recent, complete backups exist and that you have actually tested restoring one. A backup you have never restored is a hope, not a plan.
-
Check for signs of prior exploitation. Review access logs for unusual
admin-ajax.phprequests hitting the form-submission action, and check for recently deleted or missing directories. If the site was running a vulnerable version with the setting enabled while exposed to the internet, assume the worst until the logs say otherwise. - Audit every WordPress site you manage for this plugin. With 13,000+ installs and a history of mass exploitation, check all of your sites — not just the one you are thinking of right now.
References
- Super Forms security release notes (GitHub) — fixes for CVE-2026-17609 on the 6.3 and 6.4 lines
- StackFlag — CVE-2026-17609 vulnerability details
- TheHackerWire — CVE-2026-17609 analysis
- NVD entry for CVE-2026-17609 (nvd.nist.gov)
Report by Faizan Akhtar — The Cyber Security Researcher
WordPress site owners have had a rough year with the Super Forms – Drag & Drop Form Builder plugin. In July 2026, researchers disclosed a critical unauthenticated file-upload flaw (CVE-2026-14894) that attackers began exploiting within days — security teams ultimately blocked more than 250,000 exploit attempts against it. Now, on October 8, 2026, a second critical vulnerability has surfaced in the same plugin: CVE-2026-17609, an unauthenticated arbitrary directory deletion flaw rated CVSS 9.1. An attacker with no account on your site can recursively delete any directory on the server — including the entire WordPress installation. Here is the full analysis.
Summary
CVE-2026-17609 affects the Super Forms – Drag & Drop Form Builder plugin for WordPress (vendor: Rens Tillmann / WebRehab), a form builder with an estimated 13,000+ active installations. The plugin's submit_form function fails to properly validate attacker-controlled JSON field declarations against the actual form schema, and a path guard meant to confine file operations inside the WordPress directory can be trivially bypassed. The result is that an unauthenticated attacker can recursively delete arbitrary directories on the server.
- CVE ID: CVE-2026-17609 (assigned by Wordfence; reserved July 27, 2026)
- Product: Super Forms – Drag & Drop Form Builder for WordPress
- Severity: CVSS 9.1 — Critical
- Disclosed: October 8, 2026; record updated October 10, 2026
- Exploitation: No public proof of concept confirmed; not in CISA KEV — but this plugin has a proven history of fast mass exploitation
- Fix: Update to 6.3.317 or later (stable line)
One important precondition: exploitation requires that an administrator has enabled the plugin's "Delete files from server after form submissions" setting. That is a documented, commonly-enabled feature — sites using Super Forms for job applications, support tickets, or any workflow with file uploads frequently turn it on to avoid disk bloat. If that setting is on and you are running 6.3.316 or earlier, you are exposed.
Severity
CVE-2026-17609 is rated CVSS 9.1 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H:
- Attack Vector: Network (AV:N) — any visitor who can reach a form on your site can attempt this.
- Attack Complexity: Low (AC:L) — no special conditions beyond the enabled setting.
- Privileges Required: None (PR:N) — unauthenticated. This is the detail that turns a bad bug into a critical one.
- User Interaction: None (UI:N) — the site owner does not need to do anything.
- Confidentiality: None (C:N) — this flaw does not directly read data, which is why it scores 9.1 instead of 9.8+.
- Integrity / Availability: High — the attacker can destroy data and take the site offline permanently.
Do not let the "no confidentiality impact" fool you into deprioritizing this. A vulnerability that lets a stranger delete your entire website — files, uploads, and potentially the database-adjacent content the application needs to run — is a business-ending event for a small site without backups. Integrity and availability at "High" with zero authentication is exactly the profile that gets mass-exploited by bots within days of disclosure.
Affected Versions
- Super Forms – Drag & Drop Form Builder 6.3.316 and earlier — affected
- Fixed in 6.3.317 (stable line), per the vendor's security release notes
- The 6.4 beta line received the same hardening in 6.4.008
The vendor's release notes for the security update confirm that this arbitrary directory deletion flaw was fixed on the stable line in 6.3.317, alongside fixes for an unauthenticated file read (CVE-2026-28167) and an upload extension bypass (CVE-2026-17196). If you are updating, go to the latest available release rather than stopping at 6.3.317 — the vendor hardened a long list of other file-handling paths in the same release, and you want all of it.
Technical Analysis
This is a beautifully ugly bug — the kind where two individually questionable decisions combine into something catastrophic. Let me walk through both halves.
Half 1: trusting the attacker's description of the form
When a visitor submits a Super Forms form, the browser sends the form data — including a JSON structure describing which fields were submitted and, for file-upload fields, where the uploaded files should go. The submit_form handler is supposed to check that JSON against the actual form definition stored on the server: "does this form really have a file field, and is this the directory that field is configured to use?"
In the vulnerable versions, that validation is insufficient. The server accepts the attacker's JSON field declarations at face value instead of strictly reconciling them with the form schema. Concretely, the request can smuggle a subdir value inside the file-upload parameters (the data[...][files][][subdir] parameter) that points somewhere the form was never configured to touch. The server trusts the attacker's map of the form instead of its own.
This is a classic instance of a principle every web developer should tattoo on their forearm: never trust client-supplied metadata about server-side resources. The browser is the attacker's computer. Anything it says about which directories exist or where files should be written is a suggestion, not a fact — and the server must re-derive it from its own configuration.
Half 2: the guard that guards nothing
The plugin did have a safety check: before deleting, it verified that the target path was inside the WordPress installation directory by comparing against the ABSPATH constant. In theory, even a smuggled subdir could only point somewhere under the site root — annoying, but contained.
In practice, the guard was defeated by PHP's dirname() function and a trailing slash. ABSPATH in WordPress ends with a trailing slash, and the guard's comparison depended on that exact form. Passing the path through dirname() strips the trailing slash, so the comparison against the expected ABSPATH value no longer matches the way the developer assumed — and the check that was supposed to confine deletions to the site directory is bypassed. The attacker-controlled path sails through, and the recursive deletion routine happily walks anywhere on the filesystem the web-server user can reach.
Either half alone would be a moderate bug. Together, they are critical: the attacker both chooses the directory (half 1) and escapes the containment (half 2).
Attack scenario
The attack needs nothing but a Super Forms form on the target site and the "delete files after submission" setting enabled. The attacker submits the form with a crafted request: the JSON field declarations include a file-upload entry whose subdir parameter traverses to the target directory — and because the guard is bypassed, that target can be the WordPress root itself, the uploads directory, the plugin directory, or anything else the PHP process can write to.
When the form processes, the plugin's cleanup routine recursively deletes the directory. Against the WordPress root, that is total site destruction: core files, themes, plugins, uploads — gone in one request, from an unauthenticated visitor. There is no ransom note, no defacement, no exfiltration. The site simply ceases to exist. Recovery means restoring from backups, and sites without tested backups are starting from zero.
Note the asymmetry that makes this a mass-exploitation candidate: the attack is a single HTTP request, it requires no authentication, and the precondition (the delete-files setting) is common on exactly the kinds of sites that use file-upload forms — job boards, support desks, contest entries. Bots can scan for the plugin version, check the setting indirectly, and fire.
Why the history of this plugin matters
Context turns this from "patch it" into "patch it today." In July 2026, this same plugin had CVE-2026-14894 — an unauthenticated arbitrary file upload leading to remote code execution. Attackers began exploiting it on July 14, 2026, the same day firewall rules shipped, and Wordfence's firewall alone blocked over 250,000 exploit attempts, with dropped webshells carrying "Mushr00w" branding linked to a group known for government-site defacements.
That history tells you three things. First, this plugin is actively watched by attackers — it is on the target lists, and new CVEs in it get attention fast. Second, the plugin's file-handling code has now produced multiple critical unauthenticated flaws in four months, which suggests the file-handling layer needed the deep hardening the vendor says it applied — and you should not assume 6.3.317 is the last security release you will need. Third, the 250,000 blocked attempts prove that WordPress plugin exploits at this severity get industrialized within days. The window between disclosure and mass scanning is measured in hours, not weeks.
Mitigation
- Update Super Forms to 6.3.317 or later immediately. This is the single action that fixes CVE-2026-17609. Do not stop at 6.3.317 if a newer release exists — the vendor's security release hardened many adjacent file-handling paths, and you want the complete set.
- Turn off "Delete files from server after form submissions" until you have confirmed you are on a patched version. This setting is the exploit precondition; disabling it removes the attack path even on vulnerable code. Re-enable it only after updating, and only if your workflow genuinely needs it.
- Put a web application firewall in front of the site. Wordfence (free or premium) and similar WAFs ship virtual patches for flaws like this. Given this plugin's exploitation history, a WAF is cheap insurance while you verify every site in your portfolio is updated.
- Verify your backups — then verify you can restore them. A directory-deletion flaw is the scenario backups exist for. Confirm that recent, complete backups exist and that you have actually tested restoring one. A backup you have never restored is a hope, not a plan.
-
Check for signs of prior exploitation. Review access logs for unusual
admin-ajax.phprequests hitting the form-submission action, and check for recently deleted or missing directories. If the site was running a vulnerable version with the setting enabled while exposed to the internet, assume the worst until the logs say otherwise. - Audit every WordPress site you manage for this plugin. With 13,000+ installs and a history of mass exploitation, check all of your sites — not just the one you are thinking of right now.
References
- Super Forms security release notes (GitHub) — fixes for CVE-2026-17609 on the 6.3 and 6.4 lines
- StackFlag — CVE-2026-17609 vulnerability details
- TheHackerWire — CVE-2026-17609 analysis
- NVD entry for CVE-2026-17609 (nvd.nist.gov)
Report by Faizan Akhtar — The Cyber Security Researcher
Test paragraph for snippet insertion.
WordPress site owners have had a rough year with the Super Forms – Drag & Drop Form Builder plugin. In July 2026, researchers disclosed a critical unauthenticated file-upload flaw (CVE-2026-14894) that attackers began exploiting within days — security teams ultimately blocked more than 250,000 exploit attempts against it. Now, on October 8, 2026, a second critical vulnerability has surfaced in the same plugin: CVE-2026-17609, an unauthenticated arbitrary directory deletion flaw rated CVSS 9.1. An attacker with no account on your site can recursively delete any directory on the server — including the entire WordPress installation. Here is the full analysis.
Summary
CVE-2026-17609 affects the Super Forms – Drag & Drop Form Builder plugin for WordPress (vendor: Rens Tillmann / WebRehab), a form builder with an estimated 13,000+ active installations. The plugin's submit_form function fails to properly validate attacker-controlled JSON field declarations against the actual form schema, and a path guard meant to confine file operations inside the WordPress directory can be trivially bypassed. The result is that an unauthenticated attacker can recursively delete arbitrary directories on the server.
- CVE ID: CVE-2026-17609 (assigned by Wordfence; reserved July 27, 2026)
- Product: Super Forms – Drag & Drop Form Builder for WordPress
- Severity: CVSS 9.1 — Critical
- Disclosed: October 8, 2026; record updated October 10, 2026
- Exploitation: No public proof of concept confirmed; not in CISA KEV — but this plugin has a proven history of fast mass exploitation
- Fix: Update to 6.3.317 or later (stable line)
One important precondition: exploitation requires that an administrator has enabled the plugin's "Delete files from server after form submissions" setting. That is a documented, commonly-enabled feature — sites using Super Forms for job applications, support tickets, or any workflow with file uploads frequently turn it on to avoid disk bloat. If that setting is on and you are running 6.3.316 or earlier, you are exposed.
Severity
CVE-2026-17609 is rated CVSS 9.1 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H:
- Attack Vector: Network (AV:N) — any visitor who can reach a form on your site can attempt this.
- Attack Complexity: Low (AC:L) — no special conditions beyond the enabled setting.
- Privileges Required: None (PR:N) — unauthenticated. This is the detail that turns a bad bug into a critical one.
- User Interaction: None (UI:N) — the site owner does not need to do anything.
- Confidentiality: None (C:N) — this flaw does not directly read data, which is why it scores 9.1 instead of 9.8+.
- Integrity / Availability: High — the attacker can destroy data and take the site offline permanently.
Do not let the "no confidentiality impact" fool you into deprioritizing this. A vulnerability that lets a stranger delete your entire website — files, uploads, and potentially the database-adjacent content the application needs to run — is a business-ending event for a small site without backups. Integrity and availability at "High" with zero authentication is exactly the profile that gets mass-exploited by bots within days of disclosure.
Affected Versions
- Super Forms – Drag & Drop Form Builder 6.3.316 and earlier — affected
- Fixed in 6.3.317 (stable line), per the vendor's security release notes
- The 6.4 beta line received the same hardening in 6.4.008
The vendor's release notes for the security update confirm that this arbitrary directory deletion flaw was fixed on the stable line in 6.3.317, alongside fixes for an unauthenticated file read (CVE-2026-28167) and an upload extension bypass (CVE-2026-17196). If you are updating, go to the latest available release rather than stopping at 6.3.317 — the vendor hardened a long list of other file-handling paths in the same release, and you want all of it.
Technical Analysis
This is a beautifully ugly bug — the kind where two individually questionable decisions combine into something catastrophic. Let me walk through both halves.
Half 1: trusting the attacker's description of the form
When a visitor submits a Super Forms form, the browser sends the form data — including a JSON structure describing which fields were submitted and, for file-upload fields, where the uploaded files should go. The submit_form handler is supposed to check that JSON against the actual form definition stored on the server: "does this form really have a file field, and is this the directory that field is configured to use?"
In the vulnerable versions, that validation is insufficient. The server accepts the attacker's JSON field declarations at face value instead of strictly reconciling them with the form schema. Concretely, the request can smuggle a subdir value inside the file-upload parameters (the data[...][files][][subdir] parameter) that points somewhere the form was never configured to touch. The server trusts the attacker's map of the form instead of its own.
This is a classic instance of a principle every web developer should tattoo on their forearm: never trust client-supplied metadata about server-side resources. The browser is the attacker's computer. Anything it says about which directories exist or where files should be written is a suggestion, not a fact — and the server must re-derive it from its own configuration.
Half 2: the guard that guards nothing
The plugin did have a safety check: before deleting, it verified that the target path was inside the WordPress installation directory by comparing against the ABSPATH constant. In theory, even a smuggled subdir could only point somewhere under the site root — annoying, but contained.
In practice, the guard was defeated by PHP's dirname() function and a trailing slash. ABSPATH in WordPress ends with a trailing slash, and the guard's comparison depended on that exact form. Passing the path through dirname() strips the trailing slash, so the comparison against the expected ABSPATH value no longer matches the way the developer assumed — and the check that was supposed to confine deletions to the site directory is bypassed. The attacker-controlled path sails through, and the recursive deletion routine happily walks anywhere on the filesystem the web-server user can reach.
Either half alone would be a moderate bug. Together, they are critical: the attacker both chooses the directory (half 1) and escapes the containment (half 2).
Attack scenario
The attack needs nothing but a Super Forms form on the target site and the "delete files after submission" setting enabled. The attacker submits the form with a crafted request: the JSON field declarations include a file-upload entry whose subdir parameter traverses to the target directory — and because the guard is bypassed, that target can be the WordPress root itself, the uploads directory, the plugin directory, or anything else the PHP process can write to.
When the form processes, the plugin's cleanup routine recursively deletes the directory. Against the WordPress root, that is total site destruction: core files, themes, plugins, uploads — gone in one request, from an unauthenticated visitor. There is no ransom note, no defacement, no exfiltration. The site simply ceases to exist. Recovery means restoring from backups, and sites without tested backups are starting from zero.
Note the asymmetry that makes this a mass-exploitation candidate: the attack is a single HTTP request, it requires no authentication, and the precondition (the delete-files setting) is common on exactly the kinds of sites that use file-upload forms — job boards, support desks, contest entries. Bots can scan for the plugin version, check the setting indirectly, and fire.
Why the history of this plugin matters
Context turns this from "patch it" into "patch it today." In July 2026, this same plugin had CVE-2026-14894 — an unauthenticated arbitrary file upload leading to remote code execution. Attackers began exploiting it on July 14, 2026, the same day firewall rules shipped, and Wordfence's firewall alone blocked over 250,000 exploit attempts, with dropped webshells carrying "Mushr00w" branding linked to a group known for government-site defacements.
That history tells you three things. First, this plugin is actively watched by attackers — it is on the target lists, and new CVEs in it get attention fast. Second, the plugin's file-handling code has now produced multiple critical unauthenticated flaws in four months, which suggests the file-handling layer needed the deep hardening the vendor says it applied — and you should not assume 6.3.317 is the last security release you will need. Third, the 250,000 blocked attempts prove that WordPress plugin exploits at this severity get industrialized within days. The window between disclosure and mass scanning is measured in hours, not weeks.
Mitigation
- Update Super Forms to 6.3.317 or later immediately. This is the single action that fixes CVE-2026-17609. Do not stop at 6.3.317 if a newer release exists — the vendor's security release hardened many adjacent file-handling paths, and you want the complete set.
- Turn off "Delete files from server after form submissions" until you have confirmed you are on a patched version. This setting is the exploit precondition; disabling it removes the attack path even on vulnerable code. Re-enable it only after updating, and only if your workflow genuinely needs it.
- Put a web application firewall in front of the site. Wordfence (free or premium) and similar WAFs ship virtual patches for flaws like this. Given this plugin's exploitation history, a WAF is cheap insurance while you verify every site in your portfolio is updated.
- Verify your backups — then verify you can restore them. A directory-deletion flaw is the scenario backups exist for. Confirm that recent, complete backups exist and that you have actually tested restoring one. A backup you have never restored is a hope, not a plan.
-
Check for signs of prior exploitation. Review access logs for unusual
admin-ajax.phprequests hitting the form-submission action, and check for recently deleted or missing directories. If the site was running a vulnerable version with the setting enabled while exposed to the internet, assume the worst until the logs say otherwise. - Audit every WordPress site you manage for this plugin. With 13,000+ installs and a history of mass exploitation, check all of your sites — not just the one you are thinking of right now.
References
- Super Forms security release notes (GitHub) — fixes for CVE-2026-17609 on the 6.3 and 6.4 lines
- StackFlag — CVE-2026-17609 vulnerability details
- TheHackerWire — CVE-2026-17609 analysis
- NVD entry for CVE-2026-17609 (nvd.nist.gov)
Report by Faizan Akhtar — The Cyber Security Researcher
Top comments (1)
Official Platform Update
Security protocols have been updated for all developer accounts.