Security Advisory · Published 2026-05-29

WP Travel Pro CVE-2026-4290: how to check (in five minutes) if a stranger already deleted your admin

On May 29, 2026 Wordfence published CVE-2026-4290 — an unauthenticated arbitrary user deletion bug in the WP Travel Pro WordPress plugin (versions ≤ 10.6.0). The vulnerable endpoint can be reached without a password or session. The plugin's permission check returns true unconditionally, so a random scanner from anywhere on the internet can wipe your admin account, your editors, and your customers. If you run a travel agency, tour operator, or booking site on WordPress with this plugin, read the next 1,200 words before lunch.

Why I wrote this in two hours instead of two days

I get one of these calls every couple of months. Travel agency owner opens their laptop on a Tuesday morning, can't log in. Password reset bounces with "no user found with that email." Their booking site is up, but the admin user is gone — and so are the two staff accounts that manage tour itineraries. They assume their hosting got hacked.

In maybe one out of three cases, the hosting is fine. What happened is a buggy plugin let a scanner delete users over the REST API without any authentication. The site is technically "not compromised" — nothing was uploaded, no backdoor, no malicious PHP — but the owner is locked out of their own admin and has no functioning admin user to restore anything. CVE-2026-4290 is exactly that pattern, freshly delivered by WP Travel Pro. If you run this plugin and it's before 10.6.1 (the patched line), assume scanners are already trying.

What CVE-2026-4290 actually does, in plain English

WP Travel Pro adds a custom REST API namespace called wp-travel/v1. One of those routes, /wp-travel/v1/travel-guide/{user_id}, was meant to let a logged-in admin delete a travel guide profile. The plugin author wired the route to a function called check_permission(). That function is supposed to verify the caller is allowed to delete users. It doesn't. It returns true for every request, no matter who's asking. Worse, the delete handler takes the user_id straight from the URL and hands it to WordPress's wp_delete_user() without checking whether that ID is a travel guide or, say, the site owner.

Net result: any HTTP request shaped like DELETE /wp-json/wp-travel/v1/travel-guide/1 sent to your domain by anyone, anywhere, with no cookies and no API key, will delete user ID 1 — which is the first admin you ever created. ID 2 is probably your second admin. ID 3 might be your developer. You see where this goes.

Wordfence rates this 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H). Network attack vector, low complexity, no privileges required, no user interaction. The integrity and availability impact are both "High" — once your admin is gone, you can't log in to recover anything until you wp-cli or database-edit your way back in.

Step 1 — Am I even running WP Travel Pro?

Not every WordPress site running travel content uses this plugin. Open Plugins → Installed Plugins in wp-admin and search for WP Travel Pro. If you don't see it, you are not affected by CVE-2026-4290 and you can stop reading. (If you see "WP Travel" without the "Pro", you're running the free version; the vulnerable REST endpoint lives in Pro. Worth double-checking — some bundles ship both.)

Don't have wp-admin access right now? From SSH: 

cd /path/to/wordpress
wp plugin list | grep -i travel

If you see wp-travel-pro in the list with a version of 10.6.0 or lower, this guide is for you.

Step 2 — Check whether anyone has tried it yet

Look at your access log for DELETE requests to the wp-travel/v1/travel-guide route. On most LAMP / LiteSpeed / NGINX stacks the log lives in /var/log/nginx/access.log or /var/log/apache2/access.log or /usr/local/apache/logs/access_log: 

grep -E 'DELETE .*/wp-json/wp-travel/v1/travel-guide/' /var/log/nginx/access.log* | tail -50

Any line that returns a 200 status code is a successful deletion. Anything else (401, 403, 404) means the request landed but didn't execute — possibly because the user ID didn't exist, possibly because a security plugin blocked it. Save those lines. They tell you who knew about this and when. If you see 200s, jump to Step 4 (recovery) immediately.

Don't have shell? Wordfence Live Traffic, Defender, Solid Security, or any access log viewer in cPanel will work — search the same string.

Step 3 — Count your users

From wp-admin, Users → All Users. Note the totals at the top: All (X) | Administrator (Y) | .... Compare against what you remember. If Administrator count dropped, you have a problem.

From wp-cli:

wp user list --role=administrator --field=user_login
wp user list --field=ID,user_login,user_email,roles | head -30

Cross-check user IDs 1 through 5 — those are the most likely targets, because attackers iterate small IDs first when they don't know your usernames.

If a user you remember having is gone and there's a matching DELETE request in your access log, that's your confirmation. The user record and everything tied to it (posts, comments authored, profile metadata) will be in your most recent database backup if you have one.

Step 4 — Patch immediately

WP Travel Pro 10.6.1 is the patched line. From wp-admin: Plugins → WP Travel Pro → Update Now. From wp-cli: 

wp plugin update wp-travel-pro

If you have automatic updates enabled and the plugin already updated itself overnight, that's great — but you still need to run Step 2 and Step 3, because the patch closes the door, it doesn't restore users that were already deleted before you patched.

Can't update right now (custom modifications, paused subscription, version conflict)? Block the endpoint at the web server layer until you can. NGINX: 

location ~ ^/wp-json/wp-travel/v1/travel-guide/ {
    if ($request_method = DELETE) { return 403; }
}

Apache:

<LocationMatch "^/wp-json/wp-travel/v1/travel-guide/">
    <Limit DELETE>
        Require all denied
    </Limit>
</LocationMatch>

Reload the web server after editing. Then verify with curl -X DELETE -s -o /dev/null -w "%{http_code}\n" https://yourdomain/wp-json/wp-travel/v1/travel-guide/9999 — should return 403.

Step 5 — If a user was deleted

If Step 2 or Step 3 found something:

  1. Restore the user from your most recent clean database backup. The relevant tables are wp_users and wp_usermeta for that user ID. Don't restore the entire site — just those rows for the affected users.
  2. Reset passwords for every remaining admin. Even though the vulnerability didn't leak passwords, it's worth resetting the ones you might have set casually months ago.
  3. Audit other plugins on the site. If an attacker found WP Travel Pro, they'll check what else is installed. Patchstack and Wordfence both have free vulnerability scanners that run in 30 seconds — Wordfence is in the plugin directory.
  4. Add a security plugin if you don't have one. Wordfence and Solid Security both block scanner traffic and write entries to a security log you can review later.

If you have no backup at all and lost your admin, you can promote a secondary user back to admin via wp-cli: 

wp user create newadmin you@yourdomain.com --role=administrator --user_pass="long-random-here"

Then disable the offending endpoint with the web-server rules above, and log back in. Don't panic — the bug deletes users, not posts, media, or settings. Your bookings and content are intact.

Indicators of compromise

Three things to grep for in logs from the last 30 days:

  • Any DELETE request to /wp-json/wp-travel/v1/travel-guide/ returning 200.
  • Bursts of requests to that endpoint with sequential numeric IDs (1, 2, 3, 4…) — that's a scanner sweeping for admins.
  • Login failures from accounts you don't remember creating, paired with successful registrations from the same IP. Some attackers register a new account before they nuke yours, so they can log in afterward.

If this is over your head

If you want someone to audit your site for you, our Quick Patch Call is $49 — 30 minutes on a screenshare, we walk through the steps above on your actual server, patch the plugin, and verify nothing was deleted. If you find your admin was deleted, our Compromise Check at $99 includes the database surgery to put it back.

Want to know about the next critical CVE before everyone else? Subscribe to free alerts — Telegram channel or weekly email digest, your choice. We pushed CVE-2026-4290 to the channel two hours after Wordfence published.

References

Author: Ping7 security team · Published: 2026-05-29 · Last updated: 2026-05-29. Sources: Wordfence advisory, NVD CVE-2026-4290, WP Travel Pro changelog.