v0.5.0
The login that worked, and two more moves an intruder makes.
New: the success after the failures (auth_success)
Failed logins each report auth_failure — but in a credential-stuffing run the one presentation that succeeds is the only one that matters, and it was silent. The plugin now remembers failures for 15 minutes — per account and per source address, as counters in transients keyed by hash, never the username itself — and when a login lands on the heels of failures it reports a single auth_success security event carrying both counts: login succeeded for m***i* after recent failures (account: 3, address: 7).
A clean login reports nothing, ever: that would be surveillance, not security. In the console, a watch rule on class auth_success is the "page me when a spray works" switch.
The kind joins the closed security-event vocabulary on both sides (console, php-library and node senders updated in lockstep); an older console refuses the unknown kind wholesale and everything else keeps working.
New: two more post-compromise moves in the privileged_action audit family
- File-editor saves (
wp_ajax_edit-theme-plugin-file) — the classic webshell-by-editor move, legitimate on almost no production site. The file name is reported, the content never; even a refused attempt is worth the line. - Application passwords minted for administrators — persistent API access is what an intruder creates for durability. App passwords for non-admin service users stay unreported.
Changed: role changes say created vs promoted
WP core fires set_user_role for brand-new users too, so a born-admin account was always seen — but it read like any role change. Now the message says which move it was: user created: #12 as administrator vs user role changed: #12 subscriber -> administrator.
Full Changelog: v0.4.9...v0.5.0