If you patched Forminator at the end of July because of CVE-2026-15748, you did the right thing, and you are still not finished.
On 20 August 2026 a second unauthenticated critical vulnerability was published in Forminator Forms: CVE-2026-66583, a CVSS 9.8 PHP object injection flaw affecting every version up to and including 1.57.0. The July fix landed in 1.56.2. This one needs 1.57.1.
Two pre-auth criticals, three weeks apart, in one plugin on 600,000 sites. That pattern is worth more of your attention than either individual bug.
What it is
| Field | Value |
|---|---|
| CVE | CVE-2026-66583 |
| CVSS v3.1 | 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), assessed by Patchstack |
| Class | CWE-502: deserialization of untrusted data |
| Authentication | None |
| Affected | Forminator ≤ 1.57.0 |
| Fixed in | 1.57.1 |
| Published | 20 August 2026 |
| Record | NVD: CVE-2026-66583 |
One honest caveat about the record
At the time of writing, the NVD entry is marked "Awaiting Analysis", and NVD has flagged the record as not scheduled for enrichment due to resource constraints. The 9.8 score above is Patchstack's assessment, not NIST's.
That is not a reason to discount it: Patchstack is the CNA here and assigns scores competently. It is a reason to know where your numbers come from. A growing share of WordPress CVEs now sit permanently un-enriched at NVD, which matters if your vulnerability management process treats an empty NVD record as "no data, no action". It is not the same thing.
We also have no public description of the specific vulnerable code path: no function name, no parameter. We are not going to invent one. What follows is what object injection is and what it does, which is enough to make the right decision.
What PHP object injection actually does
PHP can turn an object into a string (serialize()) and back again (unserialize()). The danger is entirely in the return trip.
unserialize() does not just rebuild data. It rebuilds objects of whatever class the input names, and rebuilding an object can run code, because PHP calls magic methods automatically at points in an object's life:
| Magic method | Runs when |
|---|---|
__wakeup() | the object is reconstructed |
__destruct() | the object is destroyed, including at script end |
__toString() | the object is used where a string is expected |
So an attacker who controls a serialized string does not need the target application to use the object for anything. Getting it built and later destroyed is enough.
They then hunt for a gadget chain: a sequence of classes already loaded in the application whose magic methods, called in the right order with attacker-chosen properties, do something useful: write a file, make a request, or ultimately execute a command.
attacker-supplied serialized string
│
▼
unserialize() ── rebuilds an object of a class the attacker names
│
▼
__wakeup() / __destruct() fires automatically
│
▼
gadget chain through classes already loaded
│
▼
file write / code execution
The critical implication for a WordPress site: the gadgets do not have to be in Forminator. WordPress core, WooCommerce, every other active plugin, and every bundled Composer dependency contribute classes to the same process. This is why object injection in a small plugin can be a full compromise on a large site, and why "we only use a couple of plugins" is not the mitigation it sounds like.
Why "patched in July" was not enough
The pattern here is the thing to internalise. Two unrelated critical bugs, three weeks apart, in the same component:
| Date | CVE | Class | Fixed in |
|---|---|---|---|
| 31 July 2026 | CVE-2026-15748 | Arbitrary file upload → RCE | 1.56.2 |
| 20 August 2026 | CVE-2026-66583 | PHP object injection | 1.57.1 |
A team that patched diligently in July and moved on is running 1.56.2 today and is vulnerable to the second flaw. A team that treats "we patched that plugin" as a durable state rather than a timestamp will miss this every time.
This is the practical argument for continuous plugin monitoring rather than periodic sweeps. The interval that matters is not how often you patch: it is how long you stay unaware. If your answer is "we check monthly", your worst case is a month of exposure on a pre-auth 9.8.
What to do today
- Update Forminator to 1.57.1 or later. Check your installed version rather than trusting that auto-updates ran; confirm it reads 1.57.1 or higher.
- If you are on 1.56.x, you are exposed to this one even though you patched the July flaw. Both fixes are needed, and 1.57.1 contains both.
- Re-run the July checks anyway: the uploads-directory scan from the earlier advisory is still the fastest way to spot a shell that arrived during either window.
- Do not rely on an empty NVD record to tell you a WordPress CVE is unimportant. Feed your process from a WordPress-specific source as well.
How to detect exploitation attempts
Object injection payloads are serialized PHP, and serialized PHP has a distinctive shape: O: for objects, a: for arrays, with lengths and colons:
grep -aE 'O:[0-9]+:"' access.log | grep -iE 'forminator|admin-ajax'
That pattern in a request body or parameter is not proof of exploitation, but it is never normal traffic for a contact form and every hit deserves eyes.
Also worth checking after any suspected object-injection attempt: unexpected files anywhere writable, new administrator accounts, and modified scheduled tasks. Deserialization gadget chains most often end in a file write, and the file is the evidence.
The governance question underneath
Forminator's two disclosures are a reminder that plugin risk is supply-chain risk. You did not write that code, you cannot review every release, and the vendor's disclosure cadence is now part of your risk profile.
For a site that takes payments or handles personal data, that has compliance weight as well as security weight: under PDPL, GDPR and the rest, a plugin that processes form submissions is processing personal data on your behalf. Knowing which components do that, and having a defensible answer for how they are kept current, is squarely a governance and compliance problem.
If you would rather someone else owned the monitoring, that is a large part of what our secure web development work covers, or talk to us and we will start by telling you which of your plugins are currently behind.
