Update Forminator before comparing firewalls
A firewall is an additional layer, not a substitute for corrected upload logic.
- 1Install the latest supported Forminator release
NVD identifies versions through 1.24.6 as affected. Do not install an old historical release merely because it contains the original correction.
- 2Confirm the active version
Check the version displayed on the WordPress Plugins screen and verify that abandoned copies are not left elsewhere on the server.
- 3Review older exposed sites
If 1.24.6 or earlier accepted public post-image uploads, investigate unexpected executable files, especially beneath upload directories, and review related request and file-change logs.
- 4Treat suspicious files as an incident
Preserve logs and a backup, investigate persistence, rotate affected credentials after containment, and follow the malware cleanup guide.
The vulnerability in plain English
The affected post-image path wrote a file before finishing the check that decided whether its final file type was allowed.
In Forminator through 1.24.6, upload_post_image() read the uploaded data, selected a final filename, and wrote the file. Only afterward did the code call WordPress file-type checking to decide whether the final extension belonged to the allowed image list.
The WordPress changeset moved the write inside the successful validation branch. That order matters: validation can reject a dangerous final name only if it runs before the server creates the file.
Historical test scope
The archive preserves the table and prose, but not enough detail for a current or fully reproducible comparison.
- Test date
- September 2, 2023
- Target
- Forminator 1.24.6 post-image upload path
- Traffic source
- An AWS micro server, according to the original article
- Test input
- The public Exploit-DB sample referenced by the article; no payload is reproduced here
- Products
- Wordfence, NinjaFirewall, Shield Security, SiteGround Security, and BitFire
- Configuration claim
- The authors reported enabling all readily available security options
The updated table is a preservation of the dated BitFire-authored observation—not a retest. Every status below is a text replacement for the original legend: blocked, bypassed, not blocked, or manual rule. No missing result has been inferred.
Seven places the chain could be interrupted
Each control sees a different part of the same request. A useful design does not depend on all seven working.
Bot identity or request policy can stop the first connection.
Reject an extension that is clearly dangerous.
Check again after sanitizing or renaming.
Look beyond the extension for executable PHP.
Runtime policy can reject an unauthorized PHP write.
Server policy can keep upload directories non-executable.
Network policy can limit known command-and-control behavior.
Stages one through five can prevent the file from being created or accepted. Stage six allows ordinary uploads to exist but prevents the web server from running them as PHP. Stage seven occurs later and can limit one kind of post-compromise communication; it does not undo the earlier upload.
Results from the September 2023 test
Read every cell as “in this test,” with the missing-version limitation applied to the entire table.
| Security plugin | 1. Client restriction | 2. Extension check | 3. Final-name validation | 4. Content inspection | 5. Runtime write control | 6. Upload execution policy | 7. Outbound tool traffic |
|---|---|---|---|---|---|---|---|
| Wordfence | Not blocked in this test | Bypassed in this test | Not blocked in this test | Bypassed in this test | Not blocked in this test | Manual mitigation available but not enabled/tested | Not blocked in this test |
| NinjaFirewall | Not blocked in this test | Bypassed in this test | Not blocked in this test | Not blocked in this test | Not blocked in this test | Manual mitigation available but not enabled/tested | Not blocked in this test |
| Shield Security | Not blocked in this test | Not blocked in this test | Not blocked in this test | Not blocked in this test | Not blocked in this test | Not blocked in this test | Not blocked in this test |
| SiteGround Security | Not blocked in this test | Not blocked in this test | Not blocked in this test | Not blocked in this test | Not blocked in this test | Not blocked in this test | Not blocked in this test |
| BitFire | Blocked in this test | Blocked in this test | Manual mitigation available but not enabled/tested | Blocked in this test | Blocked in this test | Manual mitigation available but not enabled/tested | Blocked in this test |
How the old symbols were updated: the four original symbol categories are now written as “Blocked,” “Bypassed,” “Not blocked,” and “Manual mitigation available.” “Not recorded” is included in the legend for completeness but was not needed for a cell because the old table had a symbol in every position.
Per-product observations
These notes explain the historical table. They make no claim about current features or current default configuration.
Wordfence
Official plugin pageThe original test reported that client restriction did not stop the request. Its extension and file-content checks recognized part of the sample but were bypassed by the test variations. No final-name or runtime-write control stopped the request. The article reported that blocking direct PHP access beneath uploads was available through an optimized/manual server rule, but that mitigation was not part of the tested result. Outbound tool traffic was not blocked.
NinjaFirewall
Official plugin pageThe test request was not stopped by client restriction, final-name validation, content inspection, runtime write control, or outbound filtering. The extension check was bypassed in the test. The old article described a manual option for denying PHP access beneath uploads, but did not test it as an enabled control.
Shield Security
Official plugin pageNone of the seven observed stages blocked this particular request in the recorded configuration. That narrow result does not establish what Shield Security supports now, what another configuration would do, or whether unrelated controls were effective.
SiteGround Security
Official plugin pageNone of the seven stages blocked this particular request in the recorded configuration. The test was limited to this upload chain and should not be generalized to the product’s other security or account features.
BitFire
Official plugin pageThe recorded configuration blocked the request at client restriction, extension checking, file-content inspection, runtime write control, and outbound filtering. The original prose noted that bot policy could differ in a relaxed mode. It credited extension checking with evaluating the sanitized final name, while the dedicated sanitize-hook stage and server upload-directory rule were marked as manual mitigations rather than tested blocks.
Build independent controls around uploads
The table will age. The secure design principles do not depend on a particular product.
Remove the known mistake rather than asking every defensive layer to compensate for it forever.
Check both the original name and the final sanitized or generated filename before storage.
A filename is one signal. Uploaded bytes and expected media behavior provide additional evidence.
Where application and hosting requirements allow, configure upload directories so PHP cannot execute there.
A second boundary can reject executable writes that do not belong to an authenticated, expected operation.
Look for unexpected executable files, changes after upload, direct access, and unusual external connections.
Limits, commercial interest, and sources
A fair comparison makes uncertainty visible and gives readers the primary evidence.
Primary and official references
- NVD record for CVE-2023-4596
Affected versions through 1.24.6, vulnerability description, and CVSS 3.1 assessment.
- WordPress changeset 2954409 for Forminator
Moves file creation after the successful final file-type check.
- Historical public Exploit-DB reference
The sample cited by the original test. This article does not reproduce its payload.
- Official Forminator plugin page and changelog
Current release information. The historical changelog does not explicitly name this fix.
- Wordfence official page, NinjaFirewall official page, Shield Security official page, SiteGround Security official page, and BitFire official page
Use current vendor documentation rather than this 2023 table for present-day capabilities.