LatePoint CVE-2026-13228: 5.6.9 is no longer enough, update to 5.6.10
A flaw in the WordPress booking plugin LatePoint (CVE-2026-13228) lets a staff-level account take over the whole site. 100,000+ sites are affected β update to version 5.6.4 now.
Table of contents
A flaw in the WordPress booking plugin LatePoint (CVE-2026-13228) lets a staff-level account take over the whole site. 100,000+ sites are affected β update to version 5.6.4 now.
Update, August 7, 2026 β the target is now 5.6.10
On July 29 we told you to go to 5.6.9. Since then, 5.6.10 has shipped (August 3, 2026), and the official changelog for it reads "Security β Addressed security bugs. Props to WordFence for reporting it." Staying on 5.6.9 leaves that fix unapplied.
That fix in 5.6.10 carries no CVE number. It is the kind of change you cannot spot by watching vulnerability databases alone. For this plugin, the changelog itself is the only reliable source.
Separately, CVE-2026-5391 was published on August 6 (severity 6.4, stored cross-site scripting, affecting 5.3.2 and earlier). The 5.6 line already covers it. As of August 7, 2026 the current release is 5.6.10, the plugin has 100,000 installs, and it is still being distributed on WordPress.org.
Correction, July 29, 2026 β update to 5.6.9 or later, not 5.6.4
When this article was published on July 1, 2026, its body and headline told readers to update to 5.6.4. The vendor has shipped two more security releases since. Per the official changelog, 5.6.7 (July 6) and 5.6.8 (July 9) are both security fixes, and neither is present in 5.6.4. If you updated to 5.6.4 on our advice, update again. The current release as of July 29, 2026 is 5.6.9 (published July 16).
CVE-2026-13228 itself is still fixed in 5.6.4 β that has not changed. The four CVEs disclosed after publication are also all covered by 5.6.4. What 5.6.4 lacks are the fixes the vendor described only as "Addressed security bugs" in 5.6.7 and 5.6.8. No CVE IDs were assigned to those, so there is no way to verify from outside what they closed. LatePoint has not been closed or pulled from the directory; it updates normally from WordPress.org.
A serious site-takeover vulnerability has been found in "LatePoint," a popular WordPress plugin used by hair salons, clinics, and professional services to automate appointment booking. Tracked as CVE-2026-13228, it carries a severity of 8.8 out of 10 ("High").
The flaw lets an account with only the limited "agent" role β meant for booking-site staff β hijack the site owner's administrator (top-level) account entirely. The developer released a fixed version, "5.6.4," on June 30, 2026, and has kept shipping fixes since β the current release as of August 7, 2026 is 5.6.10. LatePoint is used on more than 100,000 sites worldwide, so anyone running a booking site needs to get to the latest version right away.
| Item | Details |
|---|---|
| Tracking ID | CVE-2026-13228 |
| Affected software | LatePoint (WordPress booking plugin) |
| Affected versions | All up to and including 5.6.3 |
| Fixed version | 5.6.4 (released June 30, 2026) |
| Recommended target | 5.6.10 (released August 3, 2026) includes the 5.6.7 / 5.6.8 / 5.6.10 fixes |
| Severity | CVSS 8.8 / 10 ("High") |
| Type | Improper privilege management (CWE-269) |
| Precondition | A staff "agent" account is required |
| Exploitation | None reported so far (not in CISA KEV) |
| Installs | 100,000+ sites |
Who would exploit this, and why
This is not something just anyone can pull off from the outside. The people who can exploit it are those who hold a staff "agent" account on the booking site, or an attacker who has stolen a staff member's login. That covers part-time front-desk workers, contractors hired to manage bookings, or even a former employee whose account was never deactivated.
What such a person can do is rewrite the site owner's administrator email address to one they control, then use the password-reset feature to seize the entire administrator account. Staff who should only be able to check bookings and handle customers can instead grab the site's highest privileges.
The damage to the victim is severe. Shops and clinics running the booking site risk losing customer personal data (names, contact details, booking history), payment-service integration settings, and the site's contents all at once. For the ordinary people who booked appointments, it can mean their personal data falling into a stranger's hands and secondary harm such as fake booking pages or phishing (scam sites disguised as the real one). That is why the update described below should be your top priority.
What LatePoint is, and who "agents" are
LatePoint is a plugin (add-on software) that bolts appointment-booking features onto a WordPress site. It is widely used by businesses that take time-slot bookings: hair and nail salons, massage clinics, dental offices, counseling, and professional consultations. According to the vendor, over 21,000 businesses use it, and its active-install count in the official WordPress directory has reached more than 100,000.
The key to understanding this issue is LatePoint's concept of "roles." LatePoint has three main roles: the customer who books, the agent (staff) who provides the service, and the administrator who manages the whole site. An agent is a "person who owns booking slots," such as a stylist or practitioner; they can view their own schedule and manage their assigned customers, but are not granted the power to change site settings. Agents are internal accounts issued by the administrator β not something an outside third party can obtain on their own.
In other words, LatePoint is designed on the premise that "staff only do booking work and cannot touch the site's foundations." This vulnerability breaks that premise.
What actually happens: inside the flaw
At the center of the problem is the internal routine that creates and updates customer records (a function called create_or_update()). According to the U.S. National Institute of Standards and Technology (NIST) vulnerability database, two flaws overlapped here.
The first is an "insecure reference" (technically an IDOR: if you pass an ID pointing to someone else's data, the system acts on it without verifying ownership). When an agent updated a customer record, the check on "which customer are you rewriting" was too loose β allowing them to target not just customers outside their assignment, but even the customer record linked to an administrator account. The second is that the "do you actually have permission for this action?" role check was missing during that operation.
Combine the two, and the attack path is this: using agent privileges, rewrite the email address registered to the administrator account to an address the attacker controls. Then use the "reset password" feature, and the reset link is delivered to the attacker's now-substituted address. All that is left is to set a new password and log in β entering the site as an administrator without ever passing a role check. Hijacking an administrator by starting from an email-address change closely mirrors the takeover case in the WordPress plugin "Kirki" we reported earlier.
Once a WordPress administrator account is stolen, the attacker can do virtually anything: tamper with posts and pages, add rogue accounts, inject malicious code, even manipulate files on the server. The danger of stealing an administrator from a low-privilege role has come up repeatedly, as in the administrator-takeover flaw in the membership plugin "Ultimate Member" and the "WPCode" flaw that let an editor run arbitrary code.
How dangerous is it, really? Read the conditions correctly
The CVSS severity score is 8.8, classed as "High." A successful takeover is about as bad as it gets β but before you panic over the number, understand the preconditions precisely.
To exploit this, you need agent (staff) login credentials in advance. The severity breakdown lists "privileges required: low (but logged in)," meaning this is not a type you can trigger from outside in one shot without logging in. If you see coverage claiming "anyone can take over with no authentication," that is inaccurate.
That said, "it needs a login, so it's safe" does not hold. In reality there are plenty of ways agent privileges end up in a third party's hands: insider actions by staff, leftover accounts of former employees, poor management of contractor accounts, and phishing to steal staff logins. The more staff a shop chain employs, or the more a business outsources booking management, the more realistic the risk. Write-ups of past similar flaws also cite internal staff and outsourced personnel as the main expected attackers.
Is my site at risk? A version-by-version guide
First, check the LatePoint version in your dashboard's "Plugins" list. The table below helps you judge your situation.
| Your version | Has staff (agents) | Owner only (no staff) |
|---|---|---|
| 5.6.3 or earlier | High risk update now | High risk CVE-2026-57714 needs no login at all |
| 5.6.4 β 5.6.6 | Disclosed CVEs patched 5.6.7 / 5.6.8 fixes not applied | Disclosed CVEs patched 5.6.7 / 5.6.8 fixes not applied |
| 5.6.7 / 5.6.8 | Partly caught up go to the latest | Partly caught up go to the latest |
| 5.6.9 | Patched (missing the 5.6.10 fix) | Patched (same) |
| 5.6.10 (latest) | Patched | Patched |
| LatePoint not used | Not affected | Not affected |
If you run a solo site with no registered staff, the urgency of CVE-2026-13228 is lower, since there is no "agent" entry point to exploit. But CVE-2026-57714, disclosed after this article went out (see below), needs no login at all, so 5.6.3 and earlier are dangerous whether or not you have staff. Both are closed in 5.6.4 β don't stop there, though; go to the latest release.
An engineer's view: LatePoint keeps patching the same hole
The numbers make the pattern plain. Searching the US National Vulnerability Database (NVD) for LatePoint returns 35 entries in total as of August 7, 2026. Twenty-three of them landed in 2026 alone β three in February, four in March, three in April, four in May, three in June, five in July, one in August. Seven months in a row.
Read the official changelog directly and you also find security fixes that never got a CVE number: 5.6.3 (June 24), 5.6.4 (June 30), 5.6.7 (July 6), 5.6.8 (July 9) and 5.6.10 (August 3). Five of the eight releases since late June carry a security fix. The credits list Wordfence, Patchstack and independent researchers.
So tracking CVE numbers is not enough for this plugin, because fixes land without one. The rule is simple: when a release ships, take it. Nothing else is reliable.
This is the point we most want to make. CVE-2026-13228 is not a one-off accident. LatePoint has repeatedly patched the same family of "escalate from staff to administrator" flaws over the past several months. Lined up chronologically, the repetition is stark.
| Tracking ID | Affected versions | Description |
|---|---|---|
| CVE-2026-1566 | 5.2.7 or earlier | Staff-to-admin privilege escalation |
| CVE-2026-6741 | 5.4.1 or earlier | Improper linking of a customer to another account |
| CVE-2026-8176 | 5.5.1 or earlier | Staff-to-admin privilege escalation |
| CVE-2026-13228 | 5.6.3 or earlier | Staff-to-admin privilege escalation (this case) |
You can see the same "staff-to-administrator escalation" surfacing again and again across versions. Why does this happen? To an engineer's eye, this points less to individual bugs and more to weakness in the privilege design itself. LatePoint maintains its own "customer" and "agent" user system, separate from WordPress's own user accounts. Somewhere in the code that links this custom system to WordPress's native accounts, the check for "do you really have permission for this action?" is easy to omit.
There are multiple operation entry points (updating an email address, linking a customer to a user account, resetting a password), and each one has to be written with its permission check done correctly. Plug one hole and another entry point remains β which is why flaws of the same family keep resurfacing. This is not unique to one plugin; it is a weakness commonly shared by "add-on software that bolts on its own permission system." In June, several popular WordPress plugins had vulnerabilities disclosed in quick succession, and the pattern is the same: the more add-ons you install, the more attack entry points you create.
The practical lesson is clear. For a plugin that habitually ships flaws of the same family, you should not merely update to the latest version β you should also enable auto-updates. The realistic assumption is that the next CVE is only a matter of time.
Four more CVEs disclosed since publication
In the four weeks since the first edition went out on July 1, four additional CVEs have been disclosed for LatePoint. They became public after the article, but every one of them affects 5.6.3 or earlier and was fixed by 5.6.4. Readers who updated to 5.6.4 have no extra work to do for these four.
| Tracking ID | Disclosed | Severity | Affected versions | Description |
|---|---|---|---|---|
| CVE-2026-12657 | July 2, 2026 | 5.3 (Medium) | 5.6.2 or earlier | Insecure direct object reference outsiders can consume slots for admin/agent-only services |
| CVE-2026-11398 | July 3, 2026 | 5.3 (Medium) | 5.6.1 or earlier | Authorization bypass rewrites an existing customer's name and phone without logging in |
| CVE-2026-5356 | July 8, 2026 | 7.5 (High) | 5.4.0 or earlier | Stripe payment abuse replays an already-succeeded PaymentIntent to pay any amount |
| CVE-2026-57714 | July 13, 2026 | 9.3 (Critical) | 5.6.3 or earlier | Blind SQL injection no login required |
That last entry, CVE-2026-57714, is rated 9.3 (Critical). It outranks CVE-2026-13228 (8.8), the subject of this article, and requires no login whatsoever. It is an SQL injection β an outsider can alter the queries the plugin sends to the database β of the "blind" kind, where the contents are guessed one character at a time from differences in the response. It is slow, but it can pull out whatever the database holds: customer names, contact details, booking history, even WordPress password hashes. For a site still sitting on 5.6.3 or earlier, it is a more realistic threat than CVE-2026-13228, which at least needs staff credentials.
Five CVEs in one month, in a single plugin. Counting CVE-2026-13228, that is the rate at which LatePoint disclosures landed in July, plus two more security releases (5.6.7 and 5.6.8) that carry no CVE numbers at all. Read one way, that means Wordfence and Patchstack researchers are digging into this plugin hard and the vendor is turning fixes around quickly. Read the other way, operators are being asked to make an update decision several times a month. If booking is core to how your business runs, it is time to weigh keeping up via auto-updates against moving to a different booking plugin. What is getting hard to defend is staying on LatePoint while checking for updates only occasionally.
Has it been exploited?
As of now, there are no confirmed reports of this vulnerability being used in real attacks. CVE-2026-13228 is also not listed in the "Known Exploited Vulnerabilities (KEV)" catalog published by the U.S. cybersecurity agency CISA. We re-checked on July 29, 2026, and nothing has changed: neither Wordfence nor Patchstack has reported a rise in scanning against LatePoint or any compromised site, and the same holds for the 9.3-rated CVE-2026-57714.
However, the vulnerability details and the fix are public in the official changelog, and comparing the code before and after the fix makes it far from difficult to reconstruct an attack. The period right after a fix is released is exactly when attacks based on analyzing that diff tend to begin. "Not yet attacked" is not a reason to skip the update.
What to do now
The top priority is to update LatePoint to 5.6.10 (or later). Open "Plugins" in the WordPress dashboard, and if an update notice appears for LatePoint, you can update on the spot. According to the developer, 5.6.4 was fixed in response to reports from the security firms Wordfence and Patchstack, and the later 5.6.7 and 5.6.8 releases are security fixes as well. A site stopped at 5.6.4 is still missing two rounds of them.
Beyond updating, it is safe to review the following while you are at it. First, delete agent (staff) accounts you no longer need. Check whether accounts of former employees or ended contractors are still lying around. Second, strengthen staff-account passwords and enable two-step verification. If agent privileges cannot be stolen, this flaw's entry point is closed. Also check whether your administrator account's email address has received any unfamiliar change or reset notifications. If you notice anything suspicious, reset the password and review the login history.
Summary
CVE-2026-13228 is a vulnerability that lets a staff account in the LatePoint booking plugin seize the site's administrator privileges wholesale. The severity is a high CVSS 8.8, but exploitation requires staff privileges in advance. It is not a "anyone, one shot, from outside" type β yet it can genuinely occur via insider actions or a stolen staff account.
What you cannot overlook is that LatePoint has repeatedly patched escalation flaws of the same family. Four more CVEs landed in the four weeks after publication alone, including CVE-2026-57714, a 9.3-rated SQL injection that needs no login. Rather than treating this as a one-time issue and calling it done after updating, we recommend switching to an operation that enables auto-updates and cleans up unnecessary staff accounts. More than 100,000 shop and clinic booking sites are affected. Start by checking, right now, whether your LatePoint is on 5.6.10 or later.
References
- βΈNVD - CVE-2026-13228 Detail (U.S. NIST)
- βΈNVD - CVE-2026-57714 Detail (9.3, unauthenticated blind SQL injection)
- βΈLatePoint - WordPress plugin page (changelog / current 5.6.10, checked August 7, 2026)
- βΈPatchstack - LatePoint vulnerability database
- βΈLatePoint official site
- βΈSentinelOne - CVE-2026-1566 (earlier similar flaw / agent role explained)
- βΈFreshy - LatePoint CVE-2026-6741 Security Bulletin
- βΈCIRCL - CVE-2026-8176 (LatePoint 5.5.1 or earlier escalation)

Makoto Horikawa
Backend Engineer / AWS / Django