IT and AI security incidents, checked against the primary source

Tag: changelog

Amelia’s booking plugin let anyone become a WordPress administrator, and its changelog has said “resolved a security vulnerability” six times this year

CVE-2026-9055 describes an unauthenticated path from anonymous visitor to WordPress administrator in Amelia Premium 8.0 through 9.6.2 — fixed on July 7, 2026 in a release the vendor’s changelog describes with the same eight words it has used all year.

What happened

Wordfence published CVE-2026-9055 as a CNA on Wednesday, September 2, 2026, and the National Vulnerability Database record carries a publication timestamp of 5:17 a.m. UTC. The product is “Booking for Appointments and Events Calendar – Amelia (Premium),” from the vendor melograno. Affected versions run from 8.0 through 9.6.2. The score is CVSS v3.1 9.8, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The weakness is CWE-269, improper privilege management. The finding is credited to a researcher identified as d.v4n_s3c.

The chain the record describes has three steps. Insufficient validation of an attacker-controlled type parameter in the plugin’s customer update endpoint lets an unauthenticated request elevate the caller to the plugin’s manager role. From there the attacker creates a provider entity linked to an administrator’s WordPress user ID. Creating that link overwrites the administrator’s password. The attacker then logs in to WordPress as that administrator, through the normal login form, with a password they set themselves.

No credentials are required at any point. No user interaction is required. The endpoint is network-reachable on any site running the plugin. The outcome is full administrative control of the WordPress installation, which on most sites means the ability to install arbitrary PHP and therefore control of the host.

The affected range stops at 9.6.2, which makes 9.6.3 the first release not covered by it. Amelia’s public changelog dates 9.6.3 to July 7, 2026 and describes it, in its entirety on the security side, as: “Resolved a security vulnerability.”

That sentence is not unusual for this changelog. It is the house style. Reading back through Amelia’s 2026 releases, version 9.3.1 in April says “Resolved a security vulnerability.” Version 9.4, later in April, says “Resolved security vulnerabilities. We strongly recommend updating to this version immediately.” Version 9.6.2 at the end of June says “Resolved security vulnerabilities” with the same recommendation. Version 9.6.3 in July says “Resolved a security vulnerability.” Version 9.8 in August, whose headline feature is a White Label capability with a new SuperAdmin role, says “Resolved a security vulnerability.” Version 9.8.1 later in August mentions security vulnerabilities again without specifics, alongside a precisely worded functional note about bookings failing when Stripe payments are combined with Google reCAPTCHA.

Six releases in a single year, six variations on the same eight words. From the changelog alone, an administrator cannot tell which of those releases closed an unauthenticated path to administrator and which closed something that required a logged-in editor and a chain of unlikely conditions.

Why it matters

The interesting thing here is not that one release note was vague. It is that the vagueness is uniform, and uniform vagueness destroys the only signal the document could carry.

A changelog that describes some security fixes tersely and others in detail is still usable: the terse ones are probably minor, the detailed ones probably are not, and an administrator can triage on that difference. A changelog that describes every security fix identically carries no information at all beyond “something was fixed.” Amelia’s does exactly this. The 9.4 and 9.6.2 entries even add “we strongly recommend updating to this version immediately” — advice that, applied to every release, tells you nothing about any of them.

The vendor is plainly capable of specificity. Version 9.2’s notes name an IDOR that could allow arbitrary user password changes and an SQL injection issue. That is a real disclosure, written by people who knew what was wrong and said so. And the 9.8.1 entry demonstrates the same capacity in the functional register: bookings failed when Stripe payments were used with Google reCAPTCHA enabled, which is about as precise as a bug description gets. The precision is available. It is spent on features and functional regressions, and withheld from security.

The distribution model makes this cost more than it would elsewhere. This record is scoped to the Premium edition, which is sold and updated by the vendor rather than through the wordpress.org plugin directory. Premium WordPress plugins generally update through a licensed in-dashboard updater, which means an expired or unrenewed license produces a site that simply stops receiving updates and does not loudly say so. That population — sites whose license lapsed, sites where automatic updates were never enabled, sites managed by an agency that left — is precisely the population that has been running an unauthenticated administrator takeover since at least the beginning of 2026. Booking plugins live on the sites of dentists, clinics, salons, tutors, and small clinics: businesses that installed a scheduling tool and have no security operations function at all.

Fifty-seven days separate the fix from the record. During that window, the accurate description of what 9.6.3 did existed nowhere public. The researcher had it. Wordfence had it, under coordinated disclosure. The vendor had it. The operator running the plugin had eight words. And the eight words are the ones the operator uses to decide whether to schedule the update this week or after the holiday.

This is the sixth instance Severity Daily has documented in a week of a critical fix described in the vendor’s own release notes as routine maintenance — after WPLP Cookie Consent, Nokri, GiveWP, TranslatePress, and Eclipse Theia. The charitable reading remains the right one and is worth restating: changelogs on a commercial product page are written for prospective buyers, and no vendor wants a purchase page that reads as a list of things that were once broken. But the same document is what existing operators read to make patching decisions, and those two audiences want opposite things from it. Amelia is the clearest case yet of the second audience losing, because here the vendor’s own record shows what specificity looks like when it chooses to provide it.

What to do

Check the installed version in the WordPress plugins screen. Anything from 8.0 through 9.6.2 is affected by the record’s own range. The current release line is 9.8.x.

Update to the latest release, not to 9.6.3. Two further releases have shipped since the fix, each of which also resolved unspecified security issues. Landing on 9.6.3 clears this record and nothing after it.

Verify the license is active before assuming the update will arrive. If the plugin is not offering an update, the most common reason on a premium plugin is a lapsed license key, not the absence of a newer version. Check the vendor account rather than the dashboard notice.

Audit administrator accounts on any site that ran an affected version. The attack ends with an existing administrator’s password overwritten, so look for administrator accounts whose passwords changed without a corresponding request, for unfamiliar users in the plugin’s manager or provider roles, for new administrator accounts, and for plugin or theme files with recent modification times. Force a password reset across administrator accounts and invalidate existing sessions.

Do not read the absence of reported exploitation as the absence of exploitation. No proof of concept was located and no exploitation has been reported, but the record is a day old, the fix is fifty-seven days old, and the endpoint requires no authentication. The window in which someone could have found this independently is the whole of 2026.

Sourcing note

Checked: the NVD record for CVE-2026-9055 (published September 2, 2026, CVSS v3.1 9.8, CWE-269, assigned by Wordfence as CNA, affected versions 8.0 through 9.6.2, credited to d.v4n_s3c) and Amelia’s public changelog at wpamelia.com, read for versions 9.2 through 9.8.1.

Not reachable: Wordfence’s own threat intelligence entry for this vulnerability, referenced by the CVE record, did not return content to automated retrieval. Any detail carried only there — including an explicit statement of the patched version and any active-installation figure — is therefore not reflected here. That 9.6.3 is the fix is inferred from the record’s affected range ending at 9.6.2 and from the 9.6.3 changelog entry noting a resolved security vulnerability; the CVE record does not name a fixed version.

Conflicting timestamps: the NVD record shows a publication time of 5:17 a.m. UTC on September 2, 2026, while a third-party mirror of the CVE Program record shows 4:26 a.m. UTC the same day. The difference is consistent with the ordinary lag between the CVE Program record and NVD ingestion, and neither is treated here as more authoritative than the other.

Unresolved: no vendor advisory for this CVE was found, no install-base figure for the Premium edition is published, and Amelia’s specific licensing and update terms were not independently verified — the point about lapsed licenses reflects how premium WordPress plugins update generally. There is no KEV listing and no federal deadline; the NVD record carries no CISA fields. CISA’s pages return 403 to automated fetching, so KEV state was checked through those fields rather than cisa.gov directly.

September 2, 2026
Team Password Manager’s March fix for unauthenticated account takeover was announced in a browser-extension release note, and the CVE arrived 176 days later

The fix shipped on March 10, 2026 and was announced five days later as the third bullet in a post about a Chrome extension release; the CVE describing it as unauthenticated account takeover appeared on September 2.

What happened

At 1:17 a.m. UTC on Wednesday, September 2, 2026, CVE-2026-84699 appeared in the National Vulnerability Database. Its description reads: “Team Password Manager before 14.184.308 fails to enforce authentication requirements in the local account password reset flow. Unauthenticated attackers can reset local account passwords and authenticate as those users to gain unauthorized access.”

The record is scored CVSS v3.1 9.1 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, and CVSS v4.0 9.3, both by [email protected]. VulnCheck assigned the identifier as a third-party CNA and published its own advisory dated September 1, 2026, crediting the finding to Aidan Stansfield. The weakness is CWE-640, a weak password recovery mechanism for a forgotten password. Affected versions are everything below 14.184.308. The fixed version is 14.184.308.

That fixed version is not new. Team Password Manager’s own changelog dates 14.184.308 to 20260310 — March 10, 2026 — and lists four items under it. The first reads, in full: “Corrected vulnerabilities in user password reset.” The other three are an upgrade of phpseclib to 2.0.51, a patch to Bootstrap’s JavaScript for several XSS issues, and a PHP 8.4 bug in the SAML library.

The vendor’s public announcement of that release came on March 15, 2026, in a blog post whose subject is the pairing of Chrome extension 6.42.27 with TPM 14.184.308. Its lead item is the browser extension: “Additional data for the browser extension. The application now provides the extension with additional information required for the new features.” Further down, under a heading of “Security improvements,” it says: “Several security-related updates have been implemented, including: Fixes for vulnerabilities in the user password reset functionality. Patches applied to Bootstrap JavaScript components to address multiple XSS vulnerabilities.”

Between the fix and the record describing it, 176 days elapsed. For all of them, the only public account of a 9.1-scored unauthenticated authentication bypass in a password manager was the phrase “vulnerabilities in the user password reset functionality,” sitting beneath a note about browser extension telemetry.

Why it matters

CWE-640 is a bad class of flaw in any product. In a password manager it is the worst available one, because the entire security value of the product is that a single authentication decision gates everything behind it. An attacker who can reset a local account’s password and log in as that account does not need to break any of the cryptography the product advertises; they walk through the door the product exists to guard. The CVSS vector reflects exactly that shape — confidentiality high, integrity high, availability none. Nothing goes down. Everything is read.

Team Password Manager is installed on the customer’s own server. Its changelog is full of the concerns that go with that: PHP 8.4 compatibility, a phpseclib upgrade, a SAML library bug, a session cookie name default. There is no vendor-side deployment that silently brings every tenant current. Somebody at the customer has to decide to apply the update, and the document they use to make that decision is the changelog and the release post.

Which is where the wording does its damage. “Corrected vulnerabilities in user password reset” is not false. It is not evasive in any legal sense. It is simply uninformative in the one dimension that determines behavior: whether the flaw requires an attacker to already have an account. An administrator reading “corrected vulnerabilities in user password reset” reasonably files it next to the Bootstrap XSS patches and the phpseclib bump in the same release — housekeeping, worth doing at the next maintenance window. An administrator reading “an unauthenticated attacker on the network can reset any local account’s password and log in as that user” schedules the change tonight, and audits afterward. Those are different Tuesdays, and the sentence the vendor published cannot distinguish between them.

This is now the sixth time in a week that Severity Daily has found a critical fix described in a vendor’s own release notes as routine maintenance. WPLP Cookie Consent called an unauthenticated file upload reaching code execution “security enhancements and improved validation across the codebase.” Nokri called an unauthenticated administrator takeover “hardened database queries and token generation.” The pattern holds across a WordPress plugin, a marketplace theme, an IDE, and now an enterprise credential store, which suggests it is not a property of any one market segment. It is what happens when release notes are written for prospective buyers rather than for the operators who already run the thing.

The 176-day record gap has a structural cause worth naming, because it is not the vendor sitting on something. Team Password Manager is not a CNA. Nobody inside the company had a mechanism for producing a machine-readable vulnerability record even if they had wanted one. The identifier exists today because an outside researcher reported the issue and a third-party CNA — VulnCheck, which has been generating a large share of the records this publication has covered in the past week — eventually assigned it. Vendors outside the CNA system do not produce late records. They produce no records, and the timing is then set entirely by whoever picks the work up.

Two details temper the urgency, and both should be read carefully rather than as reassurance. The first is scope: the record says “local account.” Team Password Manager supports LDAP, Active Directory, and SAML authentication in addition to local accounts, and organizations that authenticate everyone through an identity provider are less exposed by the plain reading of the description. Less, not un- — nearly every such deployment keeps at least one local break-glass administrator, and that account is the highest-value target in the system.

The second is that no exploitation has been reported. There is no proof of concept in the public sources reviewed, no KEV listing, and no federal deadline; the NVD record carries no cisaExploitAdd or cisaActionDue field. The catch is that the record is still in “Received” status at NVD, meaning it has not been analyzed and carries no CPE configuration data. Vulnerability scanners that match on CPE will not flag affected installations until that analysis completes. For an unknown number of additional days, the gap between the record existing and the record being actionable stays open.

One more line in the changelog is worth noting. The release after this one, 14.190.309, adds passkey authentication and “Protection against login timing attacks (for local users).” The local authentication path was evidently still receiving attention after March.

What to do

Check your version now. Anything below 14.184.308 is affected, which by the record’s own range means every release the product has ever shipped up to March 10, 2026. The version is visible in the application’s about or admin information page.

Upgrade to a current release, not merely to 14.184.308. The fixed version is nearly six months old, and at least two feature releases have followed it, one of which further hardened local authentication.

Treat the interval as potentially exposed, not as clean. If your installation ran a pre-14.184.308 build with the web interface reachable from anything broader than a management network at any point since 2026 began, review the password reset and authentication logs for that period, look for local accounts whose passwords changed without a corresponding user request, and check for sessions or API tokens you cannot account for.

Reduce the local-account surface. If your organization authenticates through LDAP, Active Directory, or SAML, enumerate the local accounts that still exist, remove the ones nobody uses, and make sure the break-glass account is not reachable from the same place an attacker would be.

Do not put the management interface on the public internet. The vector is network-reachable with no privileges and no user interaction. Everything about this flaw is bounded by who can reach the login page.

Sourcing note

Checked: the NVD record for CVE-2026-84699 (published September 2, 2026 at 1:17 a.m. UTC, CVSS v3.1 9.1 and v4.0 9.3, both scored by VulnCheck, CWE-640, status “Received,” no CISA KEV fields); VulnCheck’s advisory for the same issue, dated September 1, 2026, giving the affected range as everything below 14.184.308 and crediting Aidan Stansfield; Team Password Manager’s own changelog entry for 14.184.308 dated 20260310; and the vendor’s release post for Chrome extension 6.42.27 and TPM 14.184.308, dated March 15, 2026.

Unresolved: the vendor has published no security advisory for this issue under any identifier found in this review, and no vendor statement acknowledging CVE-2026-84699 exists as of publication. The exact technical mechanism — what check is missing in the reset flow — is not described in either the CVE record or the vendor’s notes, and no proof of concept was located. Whether any customer was exploited during the 176 days before the record appeared is unknown and, given the absence of a vendor advisory, likely to stay that way.

Install-base figures for Team Password Manager are not published by the vendor and none are asserted here. CISA’s pages return 403 to automated fetching, so KEV state was checked through the NVD record’s CISA fields rather than cisa.gov directly.

September 2, 2026
Nokri’s job board theme accepts an empty password-reset token again, eighteen months after Wordfence disclosed the same flaw

CVE-2026-18550 describes an unauthenticated administrator takeover through an empty reset token — the same root cause Wordfence published as CVE-2024-12824 in March 2025, in the same theme.

What happened

On Tuesday, September 1, 2026 at 12:17 p.m. UTC, NVD published CVE-2026-18550, assigned by Wordfence as CNA. It affects the Nokri – Job Board WordPress Theme, a commercial theme sold on ThemeForest, and it is scored 9.8 critical on CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

The record says the theme “is vulnerable to Privilege Escalation via Account Takeover in all versions up to, and including, 1.6.6. This is due to insufficient reset token validation in the nokri_reset_password() function, which allows empty attacker-supplied reset tokens to match empty or unset sb_password_forget_token user meta values. This makes it possible for unauthenticated attackers to reset the password of any user, including administrators, and gain access to their account.”

That is a complete, unauthenticated takeover of any WordPress site running the theme. No account, no interaction, no timing window — send a reset with an empty token against a user whose stored token is empty, which is the state of every user who has not recently requested a reset.

This has been published before

On March 1, 2025, NVD published CVE-2024-12824, also assigned by Wordfence, also scored 9.8 on the identical vector, also for this theme. Its description reads: the theme “is vulnerable to privilege escalation via account takeover in all versions up to, and including, 1.6.2. This is due to the plugin not properly checking for an empty token value prior updating their details like password. This makes it possible for unauthenticated attackers to change arbitrary user’s password, including administrators, and leverage that to gain access to their account.”

Strip the wording and the two records describe the same defect: an empty password-reset token is accepted as valid, so any unauthenticated visitor can set any user’s password. The 2025 record was scoped to versions up to 1.6.2. Today’s is scoped to versions up to 1.6.6. Versions 1.6.3 through 1.6.6 fall only under the new one.

Between them sits a third disclosure. Wordfence also carries an advisory for “Nokri – Job Board WordPress Theme <= 1.6.3 – Authenticated Subscriber Privilege Escalation via Account Takeover” — a variant of the same account-takeover behavior requiring a subscriber account rather than none at all.

Neither the new CVE record nor its Wordfence entry mentions CVE-2024-12824. A defender reading CVE-2026-18550 today has no indication from the record that this ground was covered eighteen months ago.

The fix, and what the release notes say about it

Version 1.6.7 shipped on August 18, 2026 — two weeks before the CVE appeared. The ThemeForest listing shows the theme was last updated on August 19, 2026, and shows 2,068 sales.

The 1.6.7 changelog is more forthcoming than most in this pattern, and still does not say what happened. Under “Improved,” it lists four items: “Strengthened access control to ensure resumes, applicant details, portfolio images, and account members are accessible only to authorized users.” “Hardened file upload endpoints by requiring authentication.” “Improved input validation for job listings and profile fields to prevent malicious input.” And, fourth: “Hardened database queries and token generation for enhanced security.”

Bullet four is the administrator takeover. Bullet two — “Hardened file upload endpoints by requiring authentication” — describes a separate unauthenticated file upload issue for which no public CVE record currently exists.

For comparison, the prior release, 1.6.6 on July 4, 2026, itemizes eight new homepage layouts, video and portfolio sections for candidate profiles, a working-hours section, a featured-candidates grid shortcode, and background color options for premium jobs. The vendor is capable of specificity. It spends it on features.

Why it matters

The recurrence is the story, and it should be stated with the uncertainty intact. There are two readings and the public record does not settle between them. Either the February 2025 fix was incomplete — closing one path into nokri_reset_password() while leaving another — or the empty-token check was removed or bypassed again somewhere in the 1.6.3 to 1.6.6 development line. Both are common. Only one of them is a regression in the strict sense. What is not in dispute is that a theme sold to 2,068 buyers accepted an empty password-reset token as valid in March 2025, and accepted an empty password-reset token as valid in August 2026.

Version 1.6.6 is the release that makes this concrete. It shipped on July 4, 2026, sixteen months after the first CVE, carrying eight new homepage layouts and a portfolio gallery — and the same authentication defect the vendor had already been told about and already shipped a fix for. Feature work moved. The check did not hold.

The distribution channel is what turns a 9.8 into an operational problem rather than a one-day patch cycle. Themes bought on ThemeForest do not update through the WordPress.org channel that powers one-click and automatic updates for free plugins and themes. Buyers update through the vendor’s own mechanism, through Envato’s marketplace plugin if they installed it, or by uploading a zip by hand. Many small sites do none of the three. A job board theme is bought once, configured, and left running, and its administrators are frequently the same people who run the business rather than anyone who reads a CVE feed.

Which brings the release notes back into it. This is now the fifth instance in five days where a release closing a critical, usually unauthenticated flaw is described in the vendor’s own public changelog as hardening or validation: GiveWP’s 10.0 unauthenticated RCE as “additional hardening”, TranslatePress omitting the fixing release from its changelog entirely, Eclipse Theia logging an agent-mode workspace escape as a refactor, and this morning WPLP Cookie Consent describing an unauthenticated file upload that reaches code execution as “improved validation”.

The charitable reading is the right one and is worth repeating: a marketplace changelog is sales copy written for prospective buyers, not an operator advisory. Nobody is hiding anything — the accurate description exists, in the CNA record, and it arrived today. But it arrived fourteen days after the fix, and in the interval the only document an existing buyer could read said “Improved.” “Hardened database queries and token generation” reads as maintenance. “An unauthenticated visitor can take over your administrator account” reads as tonight. Those two sentences describe the same commit and produce entirely different update behavior in the population that has to act on them.

What to do

Update Nokri to 1.6.7. Any version at or below 1.6.6 is affected. If the theme was installed by uploading a zip, check the installed version in Appearance → Themes rather than assuming an updater has run — premium themes frequently report an available update they never apply.

Before assuming the update is enough, audit administrator accounts. This flaw leaves no distinctive trace beyond a password change, so look for administrator or editor accounts created or modified since roughly March 2025, unexpected password-change events in any security plugin log, and users whose email address differs from the one your records show. Rotate administrator credentials after updating, not before.

Check for uploaded files with executable extensions in the uploads directory, given that 1.6.7 also closes unauthenticated file upload endpoints. Anything PHP under wp-content/uploads warrants investigation regardless of date.

If you cannot update immediately, a web application firewall rule blocking requests to the theme’s password-reset endpoint that carry an empty or absent token parameter is a workable stopgap. It is not a substitute for 1.6.7.

Sourcing note

CVE-2026-18550 and CVE-2024-12824 — descriptions, scores, vectors, CWEs, publication dates, and references — were read from the NVD API. The version numbers, release dates, sales figure, and changelog text for 1.6.6 and 1.6.7 were read from the theme’s ThemeForest listing, which is the vendor’s own published record. The existence of the intermediate Wordfence advisory for versions up to 1.6.3 is taken from Wordfence’s own threat intelligence listing.

Not established: Wordfence’s individual advisory pages for both CVEs would not render for this run, so the researcher credits, disclosure timelines, and any Wordfence firewall-rule dates are not reported here. Whether the 2025 fix was incomplete or the defect was reintroduced is unresolved, and this story does not assert either; a code comparison between 1.6.2, 1.6.3, and 1.6.6 would settle it, and the theme is not publicly distributed. No exploitation of CVE-2026-18550 has been reported, it does not appear in CISA’s Known Exploited Vulnerabilities catalog, and no federal deadline attaches to it. The unauthenticated file upload implied by the 1.6.7 changelog has no CVE record found in this check; that reading is inferred from the vendor’s own wording, not from an advisory.

September 1, 2026
WPLP Cookie Consent’s unauthenticated file upload reaches code execution on 10,000 sites, and its changelog calls the fix “improved validation”

A cookie-consent plugin on more than 10,000 WordPress sites shipped a fix for an unauthenticated path to remote code execution, and described it in its release notes as “Security enhancements and improved validation across the codebase.”

What happened

NVD published CVE-2026-75865 at 3:16 a.m. UTC on September 1, 2026. The record is scored by [email protected] — Wordfence is the CNA — at CVSS v3.1 9.8, Critical, with a vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The weakness is CWE-434, unrestricted upload of file with dangerous type. The record’s vulnStatus is still Received, meaning NVD has not enriched it.

The affected software is WPLP Cookie Consent – Cookie Banner & Consent Management for GDPR, CCPA & Google Consent Mode, distributed on WordPress.org under the slug gdpr-cookie-consent by wplegalpages. The plugin’s own listing reports 10,000+ active installations.

The description names two defects, not one. There is missing file type validation in a function called saas_upload_logo(), and there is an authorization bypass in the plugin’s WPLP connector REST endpoints. The record states that in combination they permit unauthenticated attackers to upload arbitrary files, which it describes as potentially enabling remote code execution. Affected versions are given as 0 through 4.4.1 — every release the plugin has ever shipped.

The fix is in 4.4.2. WordPress.org listed that release as roughly 19 hours old when this check read the page at midday UTC on September 1, which places it on August 31. The CVE followed the release by several hours, which is the normal order.

Here is the entire changelog for 4.4.2, as published on the plugin’s own WordPress.org page:

Security enhancements and improved validation across the codebase

Better data handling and export functionality

Performance and stability improvements

Minor bug fixes

There is no CVE number, no mention of file uploads, no mention of authorization, and nothing that distinguishes this release from routine maintenance. For comparison, the changelog for 4.4.1 — the last vulnerable version — is precise and enumerated. It names UK GDPR compliance support, support for 19 U.S. state privacy laws with the statutes listed by abbreviation, PIPEDA, the Australian Privacy Principles, and automatic detection of applicable privacy laws by visitor location. The release that added geo-targeting got five specific bullet points. The release that closed an unauthenticated route to code execution got “improved validation.”

The CVE record itself does not state a fixed version. NVD’s configuration data establishes the affected range as everything through 4.4.1; that 4.4.2 is the remediation is established from the vendor’s release, not from the authoritative record. That is a gap this publication has now reported on several vendors in a week, and it is worth naming each time.

Why it matters

Consent plugins are unauthenticated by design, and that is the whole problem. A visitor who has never logged in — who by definition has no account and no session — has to be able to see a banner, make a choice, and have that choice recorded. So the plugin necessarily exposes endpoints that accept requests from anonymous callers on every page load of every site that runs it. There is no way to build the feature otherwise.

What that design demands in return is that every administrative function reachable from the same surface be fenced off with its own authorization check. Uploading a banner logo is an administrative function. It writes a file to disk. According to the CVE record, the check that was supposed to keep anonymous callers away from it did not hold, and the function that received the file did not verify what kind of file it was. Those two failures are individually survivable — an upload function with no type check but sound authorization is an administrator-only problem, and an authorization bypass that only reaches read operations is a disclosure problem. Together they are a web shell.

The consequence lands somewhere with a particular irony. The database this plugin maintains holds consent logs: visitor IP addresses, timestamps, and the specific choices recorded. Under the GDPR those are personal data — that is the point of keeping them, since the log is the evidence of lawful basis. Code execution on the host storing them is therefore a personal data breach in the regulatory sense, carrying a 72-hour notification obligation under Article 33. A tool bought to demonstrate compliance becomes, if exploited, the compliance incident it was bought to prevent. Anyone who does discover a compromise here should not treat the consent log as incidental.

Then there is the changelog, which is the part worth arguing about. This is the fourth critical fix in the WordPress ecosystem in a week that this publication has found described in the vendor’s own release notes as something other than what it was. GiveWP called the fix for an unauthenticated CVSS 10.0 remote code execution flaw “additional hardening.” TranslatePress’s fixing release is missing from its public changelog entirely. Eclipse Theia logged an agent workspace escape as a refactor.

The charitable reading is the correct one, and it is not flattering either way. Nobody is hiding anything. Release notes on a marketplace listing are marketing copy, written for prospective installers browsing a directory, and “fixes unauthenticated remote code execution” is a sentence no product manager wants above the download button. The result is that the one document written by the people who know exactly what was wrong, published at the exact moment the fix becomes available, is the document least likely to say so.

That matters operationally because of how WordPress updates actually work. Automatic updates are opt-in per plugin, and a large share of small sites leave them off after being burned by a breaking release. Those administrators read the changelog to decide whether an update is worth the risk of doing it now. “Security enhancements and improved validation across the codebase” is a sentence that says: next maintenance window. “Fixes an unauthenticated arbitrary file upload that can lead to remote code execution” is a sentence that says: tonight. The information existed on August 31. It reached the operator, through NVD and through security vendors’ feeds, some hours into September 1 — and only for operators who monitor those feeds, which most 10,000-install-tier sites do not.

What to do

Update WPLP Cookie Consent to 4.4.2. Every prior version is in the affected range, so there is no safe older branch to sit on.

If the site has been running 4.4.1 or earlier with the plugin active, treat the window before the update as exposed and check for it. Look in the uploads directory — and specifically anywhere the plugin has written logo files — for PHP or other executable files that you did not put there, and check for files whose timestamps do not match any deployment you performed. Search web server access logs for POST requests to the plugin’s REST routes originating from clients with no authenticated session.

Turn on automatic updates for this plugin specifically. The reasoning in this story cuts both ways: if the changelog cannot be relied on to tell an administrator when a release is urgent, then deciding release by release on the basis of the changelog is not a workable process for a plugin of this exposure.

If you find evidence of compromise, scope the consent log into the assessment rather than treating it as low-value operational data.

Sourcing note

Checked: the NVD record for CVE-2026-75865, which is the authoritative published record and the source of the score, vector, CWE, description, and affected version range here; the plugin’s WordPress.org listing and its advanced statistics page, which are the source of the install count, the current version, the release timing, and the changelog text quoted above. The changelog is quoted exactly as published.

Could not reach: both references carried in the CVE record are closed to automated retrieval. The plugins.trac changeset NVD cites is disallowed by robots.txt, so the actual diff was not read on this run, and the description of which function and which endpoints are involved rests on the CNA’s prose rather than on inspected code. Wordfence’s own advisory page returned empty content, as it has on every attempt across several runs of this publication — a standing obstacle worth stating plainly, because Wordfence is the CNA for a large share of WordPress CVEs and its advisories are consistently not machine-retrievable from here.

Unresolved: whether the vulnerability has been exploited. Nothing in the record or the vendor’s materials asserts exploitation, and this story does not assert it either. The precise release time of 4.4.2 is derived from WordPress.org’s relative timestamp rather than an absolute one; it is August 31 with a margin of a few hours. Whether the authorization bypass and the missing type check were reported together or found separately is not stated anywhere in the public record.

September 1, 2026