The group was supposed to leave at 7 AM. Forty-three people, two weeks in the mountains, fully paid. The tour operator had confirmed every booking personally, sent the itineraries, arranged the guides. The night before departure she did one final check on the agency’s booking site.
The bookings were gone.
Not corrupted, not mixed up. Gone. The WooCommerce orders, the customer profiles, the payment records, the itinerary notes built up over weeks of back-and-forth with forty-three different people. All of it wiped.
Two hours in the server logs later, the developer had an answer. Someone had been in the database. Not a crash. Not a botched update. A deliberate, targeted extraction and deletion. The cause? A plugin running on a version that had a published critical vulnerability – one with a patch available for months.
The Vulnerability
WP Travel Engine is one of the most widely used tour booking plugins for WordPress, with over 20,000 active installations. It handles tour listings, itineraries, booking forms, pricing, customer data, and payment integration. For most small travel agencies running on WordPress, it is the entire business backend.
In March 2024, CVE-2024-30502 was published: an unauthenticated SQL injection vulnerability in WP Travel Engine versions up to and including 5.7.9. CVSS score: 9.3, Critical. Unauthenticated means no account is needed. No login, no credentials, no foothold. Anyone on the internet can run the exploit directly against the site.
SQL injection at this severity level gives an attacker direct command over the database – read every record, modify any value, delete any table. In a WP Travel Engine installation that means every booking, every customer name and email address, every payment reference, every operational record the business depends on. The attack is automated. Bots continuously scan WordPress sites for vulnerable version strings and fire the exploit the moment they find a match. The window between “site identified” and “database compromised” is measured in seconds, not minutes.
Version 5.8.0 contained the fix. The site was running 5.7.9.
The Part That Doesn’t Make the News
The thing about a CVSS 9.3 vulnerability is that it sounds dramatic in a security report and completely invisible in a WordPress dashboard. A pending plugin update looks the same whether it’s a cosmetic tweak or a patch for a critical database exploit. There’s no urgency signal, no red banner, no indication that one of those queued updates is the difference between your business data being intact and someone spending twenty minutes in your database at 2 AM.
Most WordPress compromises don’t happen because site owners are careless. They happen because the gap between “vulnerability disclosed” and “site updated” is filled with ordinary life. Busy season. Other priorities. A dashboard notification that looked the same as the fifteen before it.
What a 9.3 Costs in Practice
The tour ran, just about – rebuilt from email threads and payment processor records at 5 AM, some of it done over the phone with clients already on their way. The developer invoice and the week of cleanup that followed cost more than the trip had made.
But that’s the short-term version of this story.
This agency’s real business wasn’t individual tours. It was repeat clients – people who’d traveled with them twice, three times, who referred friends, who responded to seasonal offers because they’d had a good experience. Those relationships lived in the database. Names, email addresses, travel history, notes about preferences, records of past trips. All of it gone.
You can reconstruct a booking from an email thread. You can’t reconstruct seven years of client relationships from a payment processor export. The people who would have booked a summer tour because they got a well-timed email in April – they won’t book. They just won’t hear from the agency at all. That doesn’t show up as a line item anywhere. It shows up eighteen months later when you’re wondering why repeat business is down.
For a travel business built on referrals and returning clients, losing the CRM isn’t a cleanup problem. It’s a slow revenue bleed with no clear end date.
A Two-Minute Update That Wasn’t Made
CVE-2024-30502 had a CVE ID, a CVSS score of 9.3, a patched version, and months of public disclosure before this site was hit. The information needed to act on it was entirely available. What was missing was something actively surfacing whether the installed version was vulnerable – not a mailing list, not manual patch notes, just a scanner that checks your plugins against a live CVE database and flags what needs attention.
The gap between disclosure and exploitation isn’t a knowledge problem. It’s a visibility problem. The patch existed. The site didn’t know it needed it.