Vibe Coding WordPress: Where AI-Written Code Breaks

Nonces and Capability Checks

A nonce proves the request came from a form your site generated for this user. It does not prove the user is allowed to do the thing. AI-written AJAX and admin-post.php handlers often check the nonce and stop there.

// What AI usually writes: a nonce check and nothing else.
add_action( 'wp_ajax_gt_save_settings', 'gt_save_settings' );

function gt_save_settings() {
	check_ajax_referer( 'gt_settings', 'nonce' );

	update_option( 'gt_settings', $_POST['settings'] );
	wp_send_json_success();
}

wp_ajax_ hooks fire for every logged-in user, subscribers included. If that nonce is ever printed on a screen a subscriber can open, a subscriber can rewrite your settings. Even without that, the handler saves raw $_POST data straight into an option.

function gt_save_settings() {
	check_ajax_referer( 'gt_settings', 'nonce' );

	if ( ! current_user_can( 'manage_options' ) ) {
		wp_send_json_error( array( 'message' => __( 'You are not allowed to do this.', 'gt-plugin' ) ), 403 );
	}

	$raw = isset( $_POST['settings'] ) ? wp_unslash( $_POST['settings'] ) : array();

	$clean = array(
		'title'   => isset( $raw['title'] ) ? sanitize_text_field( $raw['title'] ) : '',
		'enabled' => ! empty( $raw['enabled'] ),
	);

	update_option( 'gt_settings', $clean, false );
	wp_send_json_success();
}

The fixed version answers 3 questions the first one ignored:

• Did this request come from our form? (check_ajax_referer())
• Is this user allowed to change settings? (current_user_can())
• What exactly are we storing? (an allowlist of keys, each sanitized for its type)

David Perez of the Plugins Team put “REST, AJAX or admin-post endpoints without a capability check (a nonce alone is not authorization)” first among the patterns that push a release’s security score up, in a comment on the automated security review announcement. He also wrote that most of what the team sees isn’t malicious code. It’s “an endpoint that was written for an admin screen and ended up reachable by anyone.” That sentence describes vibe-coded WordPress code better than any thread on X.

REST API Permission Callbacks

Since WordPress 5.5, registering a REST route without a permission_callback triggers a _doing_it_wrong notice, because the REST API treats routes without one as public. The core team added the notice after missing callbacks had exposed endpoints “multiple times in the wild.”

AI models learned that lesson in the most literal way. They almost always include a permission_callback now, and often it is __return_true, because that’s the documented value that makes the notice go away.

// Public to the entire internet.
register_rest_route( 'gt/v1', '/export', array(
	'methods'             => WP_REST_Server::READABLE,
	'callback'            => 'gt_export_entries',
	'permission_callback' => '__return_true',
) );

__return_true is correct for data you would happily print on the homepage. For anything else, the callback should ask a real question:

add_action( 'rest_api_init', function () {
	register_rest_route( 'gt/v1', '/export', array(
		'methods'             => WP_REST_Server::READABLE,
		'callback'            => 'gt_export_entries',
		'permission_callback' => function () {
			return current_user_can( 'manage_options' );
		},
	) );
} );

For routes that act on one object, the check should be about that object, for example current_user_can( 'edit_post', $id ), so an Editor can’t touch something they couldn’t edit in the admin. You can find every public route on a site by searching the codebase for __return_true. It is a quick check and I’d run it on every AI-written plugin before activating it.

Sanitization and Escaping

The WordPress rule is to sanitize on input, validate what you can and escape on output, as late as possible. AI-written code tends to do one of the three, usually sanitizing the input and then trusting it forever.

// Unescaped output. $title and $url came from the database, so they "feel" safe.
echo '<a href="' . $url . '">' . $title . '</a>';

printf(
	'<a href="%1$s">%2$s</a>',
	esc_url( $url ),
	esc_html( $title )
);

The escaping functions are not interchangeable, and the AI mixes them up often enough that it is worth knowing which one goes where:

• esc_html() for text between tags
• esc_attr() for values inside HTML attributes
• esc_url() for anything in href or src
• wp_kses_post() when you genuinely need to allow post-style HTML
• wp_json_encode() when passing data to scripts, and esc_js() only for the rare inline handler

Remember the 15% cross-site scripting pass rate from Veracode. On WordPress, data stored in a post, an option or user meta is user input that happens to be sitting in the database. Escaping it at output is the only point where you know the context.

Database Queries

AI models know $wpdb->prepare() exists, and Veracode’s 83% SQL injection pass rate shows it. The failures are subtler than a missing call:

• interpolating a variable into the query string and then wrapping the already-built string in prepare()
• building a LIKE clause without escaping the wildcards
• putting a table or column name in a placeholder that only works for values

// Classic SQL injection. Works perfectly for every normal email address.
$rows = $wpdb->get_results(
	"SELECT * FROM {$wpdb->prefix}gt_entries WHERE email = '" . $_GET['email'] . "'"
);

$email  = isset( $_GET['email'] ) ? sanitize_email( wp_unslash( $_GET['email'] ) ) : '';
$search = isset( $_GET['s'] ) ? sanitize_text_field( wp_unslash( $_GET['s'] ) ) : '';

$rows = $wpdb->get_results(
	$wpdb->prepare(
		'SELECT id, email, created_at FROM %i WHERE email = %s AND message LIKE %s LIMIT %d',
		$wpdb->prefix . 'gt_entries',
		$email,
		'%' . $wpdb->esc_like( $search ) . '%',
		50
	)
);

%i is the identifier placeholder for table and column names, added in WordPress 6.2. esc_like() escapes % and _ in the user’s search term before you add your own wildcards. And before writing any direct query, it’s worth asking whether WP_Query, get_posts() or the meta APIs already do the job, because those come with caching and the AI reaches for raw SQL far more often than it needs to.

Hooks, Priorities and Load Order

This is where AI-written code breaks in ways that only show up on some sites. WordPress loads plugins, then fires plugins_loaded, init, wp_loaded and so on, and a lot of functions simply aren’t ready before a certain point.

// Runs the moment the plugin file is included.
if ( current_user_can( 'manage_options' ) ) {
	add_action( 'admin_menu', 'gt_add_settings_page' );
}

current_user_can() depends on pluggable functions that load after plugins, so calling it at file load is a fatal error waiting for the right request. The fix is to let the hook ask the question at the right time. add_options_page() already takes a capability argument:

add_action( 'admin_menu', function () {
	add_options_page(
		__( 'GT Settings', 'gt-plugin' ),
		__( 'GT Settings', 'gt-plugin' ),
		'manage_options',
		'gt-settings',
		'gt_render_settings_page'
	);
} );

Priorities are the other half. The default priority is 10, and two callbacks on the same hook at the same priority run in the order they were added, which depends on plugin load order. AI code almost never chooses a priority on purpose. If your the_content filter needs to run after another plugin’s filter, say so with a number and a comment explaining why, and test it with that other plugin active. Query Monitor’s hooks panel shows exactly which callbacks are attached to a hook and at what priority. My WordPress developer cheat sheet has the common hooks in the order they fire.

Transients and Caching

A transient is a cached value with an expiry date. AI writes transients that technically work and then misses the details that make them safe on a real host:

• A transient set without an expiration is autoloaded, so it loads on every request and never cleans itself up.
• With a persistent object cache like Redis, transients live in the object cache. AI-written cleanup code that runs DELETE FROM wp_options WHERE option_name LIKE '_transient_%' does nothing there.
• Caching per-user data under one shared key leaks one user’s data to the next user.
• get_transient() returns false on a miss, so storing false as a real value turns every request into a miss.

$stats = get_transient( 'gt_dashboard_stats' );

if ( false === $stats ) {
	$stats = gt_build_dashboard_stats(); // The slow part: queries, remote calls.
	set_transient( 'gt_dashboard_stats', $stats, 12 * HOUR_IN_SECONDS );
}

Transients should be used when the work is expensive and the answer can go a few hours stale. They should be skipped when the value is cheap to compute or must be fresh on every request, because then you’re paying for a cache write you never needed.

Autoloaded Options and Performance

Every option with autoload turned on is loaded on every single page request, front end and admin. WordPress 6.6 changed the Options API so the $autoload parameter defaults to null, which lets WordPress decide, and options over 150,000 bytes are no longer autoloaded unless you pass true explicitly.

AI-written plugins undo that protection in 2 ways. They pass true or 'yes' out of habit, and they store things in options that were never meant to be options:

• logs
• API responses
• import queues
• lists that grow with every form submission

The result is bloat, causing slow admin load and a heavier first query on every page. A setting that only one admin screen reads should be saved with false. Data that grows over time belongs in its own table or a custom post type. You can check what a plugin added with:

wp option list --autoload=on --search="gt_*" --format=table

If autoload bloat is already slowing a site down, my notes on WordPress speed optimization cover the cleanup.

Multisite

AI models are trained mostly on single-site code, and multisite breaks most of its assumptions. The usual mistakes are:

• $wpdb->prefix and $wpdb->base_prefix used interchangeably. The first is the current site’s prefix, the second is the network’s.
• get_option() used for settings that should be network-wide, where get_site_option() belongs.
• Custom tables created only on activation, so a network-activated plugin has no table on sites created later. New sites need the wp_initialize_site hook.
• switch_to_blog() without a matching restore_current_blog(), which leaves the rest of the request running on the wrong site.
• Capabilities like manage_options checked where the action should be limited to super admins.

If the plugin will ever run on a network, multisite has to be in the prompt and in the test plan. Otherwise, the Network: header should stay out of the plugin.

Internationalization

AI code usually wraps strings in __(), which looks like translation support. Then it breaks the rules the translation tools depend on:

// Translation tools can't extract any of these.
__( $message, 'gt-plugin' );
__( 'Saved ' . $count . ' entries', 'gt-plugin' );
__( 'Settings saved', $this->text_domain );

/* translators: %d: number of saved entries. */
$text = sprintf( _n( 'Saved %d entry', 'Saved %d entries', $count, 'gt-plugin' ), $count );

The text domain has to be a literal string matching the plugin slug, the string has to be literal too and plurals need _n(). Load timing matters as well. Since WordPress 6.7, core shows a _load_textdomain_just_in_time notice when a plugin triggers translation loading before init, which is exactly what happens when an AI puts translated strings in a class constructor that runs on plugin load. For plugins hosted on WordPress.org, the manual load_plugin_textdomain() call the AI likes to add isn’t needed at all.

Block Editor Dependencies

Block code is where AI output ages fastest, because the editor’s APIs change more often than PHP’s. These are the failures I’d look for:

• Hardcoded script dependencies like array( 'wp-blocks', 'wp-element' ) while the JavaScript imports from @wordpress/components or @wordpress/data, so the editor throws on a screen where those scripts weren’t loaded.
• A changed save() function with no deprecation, so every existing block in every post shows “This block contains unexpected or invalid content.”
• Blocks registered in JavaScript only, skipping block.json, which loses server-side registration and asset handling.

The fix for the first one is to let @wordpress/scripts generate the dependency list and use it:

$asset = include plugin_dir_path( __FILE__ ) . 'build/index.asset.php';

wp_enqueue_script(
	'gt-sidebar',
	plugins_url( 'build/index.js', __FILE__ ),
	$asset['dependencies'],
	$asset['version'],
	true
);

For blocks, register_block_type( __DIR__ . '/build/my-block' ) reads block.json and handles the rest. Any change to saved markup needs a deprecated entry, and an AI won’t add one unless you tell it that existing content matters.

PHP Version Compatibility

WordPress 7.0 raised the minimum PHP version to 7.4, and it is fully compatible with PHP 7.4 through 8.5. Modern models write modern PHP by default, and every one of these is a parse error on PHP 7.4:

• constructor property promotion
• match expressions
• the nullsafe operator ?->
• enums
• readonly properties

The plugin should either be written for its real minimum or say so in the Requires PHP: header, which WordPress checks before activation and before updates. Without the header, a parse error on an older host shows up at activation, or worse, after an automatic update on a plugin that was already active. I’d decide the minimum PHP version before the first prompt and put it in the agent’s rules file, because “write PHP 7.4-compatible code” is much easier to follow than “undo the PHP 8.2 syntax you just used everywhere.”

Plugin Conflicts

AI code is written as if it’s the only code on the site. On WordPress it never is. These are the conflicts I’d check for:

• Unprefixed function, class and constant names like save_settings() or Settings, which fatal the moment another plugin declares the same name.
• Bundled Composer libraries such as an HTTP client or a PDF library loaded globally. If 2 plugins ship different versions, whichever loads first wins, and the other plugin gets an API it wasn’t written for. Tools like PHP-Scoper or Strauss move your copy into your own namespace.
• Global wp_enqueue_script() calls on every admin page, where the script should load only on the plugin’s own screen.
• Output buffering, remove_all_filters() and other global changes that quietly break someone else’s plugin.

A namespace or a short unique prefix on everything is the cheapest insurance in WordPress development, and it costs one line in the prompt.

Security Disclosures and Maintenance

This is the part vibe coding has no answer for, because a published plugin has to be fixed every time someone finds a hole in it.

Patchstack’s 2026 report found that 46% of vulnerabilities in 2025 had no patch by the time they were publicly disclosed, and that the median time to mass exploitation for heavily exploited vulnerabilities was 5 hours. The same report notes that under the EU’s Cyber Resilience Act, every commercial WordPress plugin will need a vulnerability disclosure program to be sold to European users.

WordPress.org is closing part of the gap from its side. Since June 5, every plugin and theme release goes through a 6-hour cooldown during which several AI models and Jetpack Scan review the changes, and high-risk releases are blocked automatically. On July 28 that review caught a backdoor committed to a plugin with around 20,000 active installations before the release was distributed. It is a good system, and it is also a sign of how much AI-assisted code is now flowing into the directory.

None of that replaces you. When a researcher emails you a report about your plugin’s REST endpoint, you need to understand the endpoint well enough to fix it the same day. If the code was vibe-coded and never read, you’ll be asking an AI to fix code you don’t understand, based on a report you can’t verify, under a public deadline. Whoever plans to maintain a folder full of vibe-coded plugins that way must be having a lot of free weekends.