A critical CVE published Saturday morning against a plugin on more than 30,000 WordPress sites contains two version ranges that contradict each other, and the higher one tops out above any release the plugin has ever shipped.
What happened
CVE-2024-11080 was published to the CVE Program at 8:27 a.m. UTC on Saturday, September 5, 2026, and appeared in the National Vulnerability Database about fifty minutes later. Wordfence is the assigning CNA. The score is 9.8, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and the CWE is CWE-94, code injection. The affected product is “Post Grid and Gutenberg Blocks – ComboBlocks,” published by PickPlugins, which WordPress.org lists at more than 30,000 active installations.
The record’s description reads, in full: “The Post Grid and Gutenberg Blocks – ComboBlocks plugin for WordPress is vulnerable to Unauthenticated Hook Injection in versions 2.2.32 to 2.3.1 via several functions in the ~/includes/blocks/form-wrap/function.php file. This makes it possible for unauthenticated attackers to execute actions with hooks in WordPress, granted no other security controls are present in the function.”
The machine-readable half of the same record says something different. In the CNA container retrieved from the CVE Program API, the affected block carries a single entry: vendor pickplugins, product Post Grid, "version":"2.2.85", "lessThanOrEqual":"2.3.32", "versionType":"semver", status affected. NVD reproduces the same range and carries no separate CPE configuration of its own.
So one record states two ranges. The prose says the flaw runs from 2.2.32 to 2.3.1 — implying a site on anything from 2.3.2 upward is clear. The structured data says it runs from 2.2.85 to 2.3.32 — implying nothing below 2.3.33 is clear. The two ranges do not overlap at either end. We retrieved the record three times, twice from NVD with different query forms and once from the CVE Program API, and got the same two ranges every time.
The upper bound is the part that will not resolve by picking the more cautious number. WordPress.org lists the plugin’s current version as 2.3.24, last updated July 19, 2026, with a changelog entry reading “fixed – Cross Site Scripting (XSS).” The version selector on the plugin’s advanced page runs down from 2.3.23 and shows nothing above 2.3.24. There is no 2.3.32. The affected range’s ceiling names a release that does not exist.
That propagates. WPScan’s page for the plugin lists the same finding as “Post Grid and Gutenberg Blocks – ComboBlocks 2.2.85 – 2.3.32 – Unauthenticated Hook Injection,” dated September 4, 2026, at 9.8, and states it is fixed in 2.3.33. A site owner acting on that is being told to install a version one increment above another version that has never been released.
Two smaller defects sit in the same record. The description points at ~/includes/blocks/form-wrap/function.php, singular. All three source references in the record point at form-wrap/functions.php, plural, at lines 116, 262 and 3249. And the CVE identifier itself is a 2024 one: the CVE Program record gives dateReserved as November 11, 2024, while its own disclosure timeline says the vendor was notified on September 2, 2026 at 1:42 p.m. UTC and the finding was disclosed on September 4, 2026 at 7:52 p.m. UTC. The researcher credited is Chloe Chamberland.
Why it matters
The two halves of a CVE record are read by two different audiences, and here they give opposite answers to the only question that matters.
A human reading the NVD page sees “versions 2.2.32 to 2.3.1,” checks the site’s plugin screen, sees 2.3.24, and closes the tab. A scanner ingesting the record does not read the prose at all — it reads the affected block, sees a ceiling of 2.3.32, and flags 2.3.24 as vulnerable. Both are behaving correctly on the data in front of them, and one of them is wrong. Nothing in the record tells you which.
Because the ceiling is above every shipped release, the structured data effectively says the plugin is unpatched, and the prose effectively says it was patched twenty-two releases ago. That is a two-year gap in a 9.8 rated as unauthenticated with no user interaction. And the plugin’s own changelog gives no help: the last release, 2.3.24 on July 19, 2026, predates by seven weeks the September 2, 2026 vendor notification recorded in this very CVE. Absent a release we cannot see, the vendor has not shipped anything since being told.
The downstream effect is the interesting part, and it is not hypothetical. WPScan has already rendered “≤ 2.3.32” into “fixed in 2.3.33,” which is what a well-behaved aggregator does with an upper bound: it adds one. That is a reasonable rule applied to an unreasonable input, and the output is a remediation instruction pointing at a version nobody can install. This site has been tracking a family of these all week — Coolify, where the affected ceiling is also the current release; SonicWall’s SMA1000 records, which name no fixed version at all; goose, whose CVE names none either. Those records fail by saying too little. This one fails by saying two things.
The description’s own hedge deserves a mention too. It ends “granted no other security controls are present in the function” — a conditional that materially changes exploitability, since a hook-injection primitive that lands in a function with its own capability or nonce check is not the same finding as one that does not. The 9.8 score carries no such conditional; CVSS has nowhere to put one. Readers who triage on the number alone will not see it.
Finally, the identifier. CVE-2024-11080 will be read by a lot of people as a 2024 vulnerability, and it is not. The year in a CVE ID marks when the identifier was reserved, not when the flaw was found or fixed, and CNAs that handle volume reserve blocks well in advance and draw from them later. That is normal practice, not a defect. It becomes a practical problem when the record is otherwise ambiguous: an operator trying to work out whether 2.3.24 is affected cannot use the ID’s year to bound the answer, and here that was the last piece of context left.
What to do
There is no version you can confidently upgrade to, so this is a containment question rather than a patching one.
- Inventory first. Find WordPress sites running Post Grid / ComboBlocks (slug
post-grid) and record the exact version. Anything in the 2.2.x or 2.3.x range is inside at least one of the two published ranges. - Do not treat 2.3.2 or later as clear on the strength of the description. The record’s own structured data disagrees with it, and the structured data is what your scanner is using.
- Do not go looking for 2.3.33. WordPress.org shows 2.3.24 as current as of September 5, 2026. If your tooling tells you to install 2.3.33, that instruction is derived from the disputed ceiling, not from a release.
- Look at
includes/blocks/form-wrap/functions.php, with the plural filename, around lines 116, 262 and 3249 — the three locations the record’s own references cite. If you maintain the site, that is the code to review or to gate. - Restrict unauthenticated access to the plugin’s form-wrap handlers at the WAF or reverse proxy if the plugin is load-bearing and cannot come out. This stands in for a patch and is not one.
- Expect a scanner finding that will not clear. Until the range is corrected or a release above 2.3.32 exists, tools reading the structured data will keep flagging current installs. Document the dispute rather than suppressing the rule.
Sourcing note
Checked against primary sources: the CVE Program record for CVE-2024-11080 retrieved from cveawg.mitre.org on September 5, 2026, which supplied the affected block, the reserved and published dates, the disclosure timeline and the researcher credit; the NVD record for the same CVE, retrieved twice with different query forms; and the WordPress.org listing and version-history page for the post-grid plugin, which supplied the current version, last-updated date, changelog and install count. The WPScan entry is included as a secondary source and is cited for what it publishes, not as confirmation of the flaw.
Could not reach: Wordfence’s own threat-intelligence entry for this vulnerability, which the CVE record links, does not render to automated retrieval, so the patched version Wordfence states on that page — which may resolve the contradiction — is not established here. We also could not retrieve the plugin’s raw readme.txt from the plugin repository’s version-control host, so the changelog above comes from the rendered WordPress.org page, which can lag a release by some hours.
Unresolved: which of the two version ranges is correct, and whether a release above 2.3.24 exists that WordPress.org had not yet published at the time of writing. PickPlugins has issued no public statement we could find. There is no indication in any source that this flaw has been exploited, and it is not in CISA’s Known Exploited Vulnerabilities catalog.