DEV Community: Loyal Security WP

Auditing WordPress Changes - What Core Hooks Don't Tell You

Loyal Security WP — Tue, 27 Oct 2026 14:07:12 +0000

WordPress core gives you hooks for a lot of individual events — wp_login_failed,
activated_plugin, profile_update — but no unified log. If you want to answer "what changed on
this site, and when," you're stitching together a dozen separate hooks yourself, or you're
guessing after the fact and hoping the answer is still in a log file somewhere.

The hooks worth capturing for a basic audit trail

You don't need to log everything WordPress fires — most of it is noise. A useful baseline audit
trail covers:

activated_plugin / deactivated_plugin — plugin changes are one of the most common vectors for "something changed and nobody admits to it."
switch_theme — same reasoning, lower frequency, still worth knowing.
set_user_role — privilege changes are the single highest-value thing to audit on any multi-admin site.
profile_update and added_user_meta filtered to role-adjacent meta keys — catches privilege escalation that doesn't go through set_user_role directly.
wp_login / wp_login_failed — who got in, and who tried to.
update_option, filtered to a sensitive-options allowlist — things like the site URL, active plugins list, or a security plugin's own settings. Logging every option write is how you end up capturing autosave noise and transient churn instead of signal.

Why storage, not capture, is the actual hard part

Hooking these actions is the easy 20%. The hard part is what happens six months later: a naive
"log everything to a custom table forever" approach quietly grows into a 40 MB table nobody can
query without timing out the admin page that's supposed to display it.

The fixes are boring but necessary:

A row cap or time-based pruning policy decided up front, not bolted on after the table becomes a problem.
A storage summary visible to the admin — "12,400 rows, oldest entry 90 days ago" — so nobody discovers the problem by way of a slow dashboard.
Pruning that runs on a schedule, not a button someone has to remember to click.

A worked example

As a learning example — not production-ready, but enough to see the shape of it — here's a
minimal table and dispatcher:

<?php
function prefix_create_audit_log_table() {
    global $wpdb;

    $table_name      = $wpdb->prefix . 'prefix_audit_log';
    $charset_collate = $wpdb->get_charset_collate();

    $sql = "CREATE TABLE {$table_name} (
        id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
        event_type VARCHAR(64) NOT NULL,
        event_data LONGTEXT NULL,
        user_id BIGINT UNSIGNED NULL,
        created_at DATETIME NOT NULL,
        PRIMARY KEY  (id),
        KEY event_type (event_type),
        KEY created_at (created_at)
    ) {$charset_collate};";

    require_once ABSPATH . 'wp-admin/includes/upgrade.php';
    dbDelta( $sql );
}

add_action( 'activated_plugin', 'prefix_log_activated_plugin' );

function prefix_log_activated_plugin( $plugin ) {
    prefix_write_audit_log_entry( 'activated_plugin', array( 'plugin' => $plugin ) );
}

function prefix_write_audit_log_entry( $event_type, $event_data ) {
    global $wpdb;

    $wpdb->insert(
        $wpdb->prefix . 'prefix_audit_log',
        array(
            'event_type' => $event_type,
            'event_data' => wp_json_encode( $event_data ),
            'user_id'    => get_current_user_id(),
            'created_at' => current_time( 'mysql' ),
        )
    );
}

Wire the same prefix_write_audit_log_entry() call into deactivated_plugin, switch_theme,
set_user_role, and the rest of the list above, and you have the shape of a real audit trail —
missing only the pruning job and the admin summary that make it sustainable long-term.

Loyal Security's free audit log solves this with
a storage cap, a clear summary, and WP-CLI commands for stats and pruning
(wp loyal-security logs stats, wp loyal-security logs prune) if you'd rather not build and
maintain this yourself.

The Two URLs Every WordPress Attacker Tries First (And How to Stop Guessing Being a Risk)

Loyal Security WP — Tue, 27 Oct 2026 14:02:01 +0000

If you've ever checked your WordPress server logs, you've seen it: a steady stream of requests to
/wp-login.php and /wp-admin from IPs you've never heard of, at all hours, with no referrer.
That's not targeted. It's automated. Every WordPress site on the internet gets this traffic,
because the login URL is the same on every default install, which means a bot written once works
against millions of sites forever.

Why the default login path is a structural problem, not a bug

WordPress can't ship a random login URL by default. Plugins link straight to wp-login.php,
documentation assumes it exists, and a huge number of integrations (password reset emails, SSO
redirects, staging-to-production migrations) depend on that path being predictable. Changing it
is an opt-in hardening step you take on your own site, not something core can fix for everyone at
once without breaking things that currently work.

That's why "just rename wp-login.php" isn't a core patch waiting to happen — it's a trade-off
between predictability (which every integration relies on) and obscurity (which only helps once
you've opted in).

What actually happens during a credential-stuffing run

Watch the pattern for a few minutes on an unprotected site and it's remarkably consistent:

Request rate is steady, not bursty — slow enough to stay under most rate limits you'd set by accident, fast enough to try thousands of combinations a day.
Usernames cluster around admin, the site's own domain name, and a handful of common first names — not random strings. These are credential lists built from breach dumps and common WordPress install conventions, not brute-force in the "try every character" sense.
No referrer, no JS execution — these are raw POST requests, not a browser driving a form.

This is also why rate-limiting beats CAPTCHA for this specific threat. A CAPTCHA assumes the
attacker is a human or a bot without a human fallback; credential-stuffing bots are neither —
they just don't have infinite patience for a 429 Too Many Requests response slowing them to a
crawl. Rate-limiting attacks the bot's actual constraint (time), where CAPTCHA attacks a
constraint it may not even have.

A minimal hook to see this on your own site

Before reaching for a plugin, you can see this pattern yourself with one hook:

<?php
add_action( 'wp_login_failed', 'prefix_log_failed_login' );

function prefix_log_failed_login( $username ) {
    $ip_address = isset( $_SERVER['REMOTE_ADDR'] ) ? sanitize_text_field( wp_unslash( $_SERVER['REMOTE_ADDR'] ) ) : 'unknown';
    error_log( sprintf( 'Failed login for "%s" from %s', $username, $ip_address ) );
}

Tail your error log for a day on a site that's been live for more than a few weeks, and the
pattern above will be staring back at you — not as a theory, but as your own traffic.

Where a custom login URL and rate-limiting actually fit

Moving the login endpoint doesn't stop a targeted attacker who already knows your real URL —
anyone who's phished a password or found it in a leaked database isn't slowed down by this.
What it does is silence the roughly 99% of traffic that's just scanning the default path on every
WordPress site it can find, with no idea yours exists at a different one. Once that noise is
gone, the signal that's left in your logs — the handful of requests actually aimed at your
specific site — becomes much easier to see and act on. Pair that with rate-limiting on whatever
login path you do use, and you've addressed both the volume problem and the determined-attacker
problem with two independent, complementary controls.

This is exactly the free feature set in Loyal Security custom login URL plus brute-force protection, no paywall, no upsell screen in the
way. If you'd rather build and maintain the above yourself, the hook above is a genuine starting
point; if not, that's what the plugin is for.

We also cover this topic in plain language, for a non-technical audience, on the company blog:
The Two URLs Every Bot Tries First on Your WordPress Site.