The unauthenticated deserialization was fixed on September 1 in a release whose only security bullet describes a different change, and the one file the record cites outside the plugin’s own code is a bundled third-party analytics SDK.
What happened
CVE-2026-10196 was published to the National Vulnerability Database at 12:16 p.m. UTC on Saturday, September 5, 2026, with Wordfence as the assigning CNA. It scores 9.8 on vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and is classified CWE-502, deserialization of untrusted data.
The product is Mail Mint – Email Marketing, Newsletter, Email Automation & WooCommerce Emails, published by getwpfunnels, which WordPress.org lists at more than 4,000 active installations. The record’s description says the plugin “is vulnerable to PHP Object Injection in all versions up to, and including, 1.31.0 via deserialization of untrusted input in the ‘handle_form_submission’ function,” and adds the sentence that carries the score: “The additional presence of a POP chain allows attackers to execute code on the server.”
That sentence is doing all the work. An unauthenticated attacker who can get arbitrary serialized data into unserialize() has object instantiation, which on its own is often a nuisance. It becomes remote code execution only when the running codebase also contains a property-oriented programming chain — a class whose magic methods, invoked as PHP tears the object down, do something useful to an attacker. Without a chain the finding is high; with one it is 9.8.
The record does not say where the chain is. Its source-code references do point somewhere specific. Wordfence cites three files, each twice — once at the 1.21.0 tag and once at trunk:
app/API/Actions/Frontend/FormAction.phpat line 59app/Database/models/ContactModel.phpat line 460vendor/posthog/posthog-php/lib/Consumer/ForkCurl.phpat line 96
The first two are Mail Mint’s own code — the form handler named in the description, and the model it writes through. The third is not Mail Mint’s code at all. It is PostHog’s PHP analytics SDK, vendored into the plugin’s vendor/ directory by Composer. Upstream, that class builds a curl command as a string and hands it to PHP’s exec(); the version on PostHog’s master branch calls exec() twice, at lines 64 and 77, and defines no magic methods of its own. We could not read the copy bundled inside Mail Mint at line 96 — the WordPress plugin repository’s code browser refuses automated retrieval — so we cannot confirm what that specific line contains or that it is the chain.
The fix exists. WordPress.org shows the current version as 1.31.1, released September 1, 2026, four days before the CVE was published. The affected range stops at 1.31.0, so 1.31.1 is the version to be on. Two changesets are referenced in the record, 3545065 and 3675453; both returned rate-limit errors to us and are unread.
The 1.31.1 changelog does use the word “security.” It attributes it to something else: “Contact action links now use unguessable tokens,” a link-forgery fix. The entry covering the code this CVE is about is worded as an improvement to form submission error handling. Neither deserialization nor object injection appears.
Why it matters
The severity of a deserialization bug is not a property of the deserialization bug. It is a property of everything else that happens to be loaded in the same PHP process at the same time. That is the uncomfortable part of CWE-502 and it is why these findings are so hard to triage from a distance.
Mail Mint’s own code, on the record’s own account, supplies the sink: a form handler that unserializes attacker-controlled input without authentication. What lifts that from a serious bug to a 9.8 is a chain — and the only file the record points at that Mail Mint’s developers did not write is a bundled analytics library whose entire purpose is to shell out to curl. We are not asserting that PostHog’s SDK is vulnerable; a class that calls exec() is not a vulnerability, it is a design choice appropriate to a library that ships HTTP payloads. The point is narrower and more awkward: a plugin author’s exposure to this class of bug is set partly by the contents of a vendor/ directory they did not audit and may not think of as theirs.
This is a recurring shape in the WordPress ecosystem specifically, because plugins ship their dependencies rather than resolving them at runtime. Every plugin on a site contributes its vendored classes to one shared autoloader and one shared process. A gadget introduced by plugin A can be reachable from a sink introduced by plugin B. Nothing in a CVE record for either plugin will tell you that, and nothing in a scanner’s output will either.
The practical consequence for a defender is that “we removed the vulnerable plugin” and “we are safe” are different claims. If the sink is gone, that install is fixed. But the same vendored SDK ships inside other plugins, and the presence of a usable chain on a given site is a function of the whole plugin set, not of any one entry in it.
The changelog point is smaller but worth recording, because it is the second time today this site has run into it. This morning we covered three WordPress plugins that reintroduced comment XSS after core had sanitized it, none of whose changelogs said security. Mail Mint’s does say security — about a different change in the same release. A site owner reading the 1.31.1 notes to decide whether to update urgently would conclude the security content was a link-tokenization improvement, and would have no way to know that the same release closed an unauthenticated path to code execution. The four-day gap between the release and the CVE is the window in which the changelog was the only public description of what 1.31.1 did.
What to do
- Update Mail Mint to 1.31.1 or later. The affected range is everything up to and including 1.31.0, and 1.31.1 has been available since September 1, 2026. This is the whole fix for the sink.
- Check WooCommerce sites first. The plugin’s transactional and abandoned-cart features mean it is most often installed on stores, where the same process also holds order and customer data.
- Treat the pre-update window as reachable. The path is unauthenticated with no user interaction, so exposure did not require a logged-in user. If the site was on 1.31.0 or earlier and public, review web server logs for POSTs to the plugin’s form endpoint and look for unexpected files under
wp-content. - Inventory vendored dependencies, not just plugins. Grep your plugin directory for
vendor/posthog, and more usefully for any vendored class that callsexec,shell_exec,proc_openorsystem. That set is your site’s gadget surface and it does not appear in any plugin list. - Do not read the changelog as the severity signal. Read the CVE record and the affected range.
Sourcing note
Checked against primary sources: the NVD record for CVE-2026-10196, retrieved September 5, 2026, which supplied the description, score, vector, CWE, affected range and the full reference list quoted above; the WordPress.org listing and changelog for the mail-mint plugin, which supplied the current version, its release date and install count; and PostHog’s posthog-php repository on GitHub for the upstream contents of lib/Consumer/ForkCurl.php.
Could not reach: the WordPress plugin repository’s code browser, which refuses automated retrieval, so none of the six trac source references in the record were read, including the ForkCurl.php line 96 that this story discusses. The two referenced changesets returned HTTP 429 rate-limit errors and are unread, so what 1.31.1 actually changed is taken from the changelog rather than from a diff. Wordfence’s own threat-intelligence entry for this vulnerability does not render to automated retrieval.
Unresolved: the record states a POP chain is present but does not name it, and we have not confirmed that the chain runs through the bundled PostHog SDK — that reading is inferred from the record’s reference list and is stated as an inference, not a finding. getwpfunnels has published no security advisory 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.