If your business uses an online booking page — for appointments, classes, or events — a stranger on the internet may be able to silently plant malicious code on your website right now, without ever logging in.
Who's Affected and How Big Is This?
The vulnerability lives inside LatePoint, a widely used WordPress plugin that helps small businesses accept appointments and event bookings online. Think hair salons, personal trainers, therapists, tutors, and medical clinics — the kinds of businesses that rely on a "Book Now" button to keep their calendar full. LatePoint has tens of thousands of active installations worldwide, and every single one running version 5.5.0 or earlier is exposed.
For those businesses, the consequences are very real: a successful attack can redirect your customers to phishing pages, steal login credentials, silently install browser-based malware on visitors' devices, or deface the page they see when they try to book an appointment. For a small business, that's not just a technical problem — it's a reputation crisis and a potential liability.
What an Attacker Can Actually Do
Here's the scenario in plain terms. Imagine someone decides to target your booking website. They don't need your admin password. They don't need to know anything about you personally. All they need to do is visit your booking page and submit a specially crafted request — the kind your site is designed to accept from the public. Hidden inside that request is a chunk of malicious code disguised as a normal web address. Your website, trusting the input, swallows it whole and saves it to your database.
Now the trap is set. The next time any visitor — a potential customer, a returning client, even you — loads that booking page, their browser reads the stored code and executes it automatically. The visitor sees nothing unusual. There's no warning, no weird pop-up, nothing to make them suspicious. Behind the scenes, though, their browser could be quietly sending their session cookies to an attacker's server, redirecting them to a convincing fake login page, or downloading additional malicious scripts. This class of attack, where the malicious code is saved and then silently served to future victims, is particularly dangerous because a single successful injection can affect every person who visits the page from that moment on.
What makes this especially alarming is that the vulnerable code path fires even when the payment processor Stripe is not set up on the site. The flawed logic runs during the booking intent process — before any payment configuration check occurs — meaning you don't have to be taking online payments to be at risk. A bare-bones booking page with no payment integration is just as exposed as a fully configured e-commerce setup.
The Technical Detail Security Teams Need to Know
The root cause is a Stored Cross-Site Scripting (Stored XSS) vulnerability in the booking_form_page_url parameter, exploitable by completely unauthenticated users. The flaw stems from insufficient input sanitization and output escaping — user-supplied data is written directly to the database via the latepoint_order_intent_created action hook and later rendered in the browser without being safely encoded. This vulnerability is tracked as CVE-2026-7332 and carries a CVSS score of 7.2 (HIGH). The pre-authentication nature of the injection vector is what elevates severity: there is no access control barrier whatsoever between an anonymous internet user and the vulnerable write path.
Has This Been Used in the Wild?
As of publication, no active exploitation has been confirmed. There are no known victims and no documented attack campaigns leveraging this specific vulnerability — yet. That word "yet" matters enormously. History shows that once a WordPress plugin vulnerability is publicly disclosed, automated scanners and opportunistic attackers begin probing for it within hours, sometimes minutes. The window between "disclosed" and "actively exploited at scale" has collapsed dramatically over the past few years. Security teams should treat this as urgent, not as something to schedule for next month's patch cycle.
The vulnerability was responsibly disclosed through coordinated channels, giving the LatePoint development team time to prepare a fix prior to public disclosure.
What You Need to Do Right Now
Three concrete steps, in order of priority:
-
Update LatePoint immediately to version 5.5.1 or later. Log into your WordPress dashboard, navigate to Plugins → Installed Plugins, find LatePoint, and click "Update Now." If automatic updates are available, enable them. Version 5.5.1 contains the patch that properly sanitizes the
booking_form_page_urlparameter before it is written to the database and escapes output before it is rendered in the browser. Do not wait — this one step eliminates the vulnerability entirely. -
Audit your database for signs of prior injection. Even without confirmed active exploitation, it's worth checking whether your site was probed before you patched. In your WordPress database, examine the LatePoint activity log table for any entries containing unexpected
<script>tags, JavaScript event handlers (such asonerror=oronload=), or unusual URLs in fields that should contain only booking page addresses. Many managed WordPress hosts provide database access through phpMyAdmin or a similar tool. If you find anything suspicious, consider resetting your WordPress security keys and forcing a logout of all active sessions. - Enable a Web Application Firewall if you haven't already. Services like Cloudflare (free tier available), Wordfence (WordPress plugin), or Sucuri provide rule sets that can detect and block common XSS payloads before they ever reach your application. This won't replace patching, but it creates a critical second line of defense against this entire class of attack — not just this specific CVE. If you're running any public-facing WordPress site that accepts user input, a WAF is no longer optional.
The Bigger Picture
This vulnerability is a reminder of something the security community has been saying for years: the weakest link in most websites isn't the server software or the operating system — it's the third-party plugins and add-ons that extend functionality. WordPress powers roughly 43% of all websites on the internet, and its massive plugin ecosystem is both its greatest strength and its most persistent attack surface. Every plugin that accepts public input and stores it for later display is a potential injection point. The question is never whether developers intend for their code to be secure — they almost always do — but whether the specific implementation correctly handles untrusted data at every step of its journey from user input to browser output.
For LatePoint users, the fix is simple and available now. Apply it today.
CVE: CVE-2026-7332 | CVSS: 7.2 (HIGH) | Affected versions: LatePoint ≤ 5.5.0 | Fixed in: 5.5.1+