Audit #38 Suspicious

Endpoint timeline across the codeandcore portfolio

Walking the per-commit history of every codeandcore plugin (10 slugs total, 9 with the tracking framework) reveals that red-fly-431376.hostingersite.com and wordpress-plugins.pro are both codeandcore-operated infrastructure — not "old flagged host" + "new evasion host." The portfolio has ping-ponged between them:

Phase 1 — red-fly-431376.hostingersite.com was the original (Nov 2025 → Feb 2026)

Phase 2 — synchronized migration to wordpress-plugins.pro (Mar 2026)

Phase 3 — wysiwyg flips back to red-fly (May 2026)

The May 6 release is the first plugin in the portfolio to flip back to red-fly. The other 8 plugins remain on wordpress-plugins.pro. The changelog reads "Added automatic redirect to settings page" — the actual diff at acf-wysiwyg-character-limit.php:577-578:

-        'https://wordpress-plugins.pro/receiver.php',
+        'https://red-fly-431376.hostingersite.com/receiver.php',

Current state across the portfolio

Telemetry payload

// acf-wysiwyg-character-limit.php:496-517 (HEAD)
$base_payload = [
    'site_url'       => home_url(),
    'plugin_name'    => $info['Name'],
    'plugin_version' => $info['Version'],
    'event'          => $event,           // Activation / Optin Yes / Deactivation / Uninstall
    'php_version'    => phpversion(),
    'wp_version'     => get_bloginfo('version'),
    'theme_name'     => wp_get_theme()->get('Name'),
    'theme_version'  => wp_get_theme()->get('Version'),
    'is_multisite'   => is_multisite() ? 'yes' : 'no',
    'site_language'  => get_locale(),
    'timestamp'      => time(),
];

Wrapped in AES-256-CBC with a hardcoded secret (8jF29fLkmsP0V9as0DLkso2P9lKs29FjsP4k2F0lskM2k) and an HMAC-SHA256 signature using the same key. Because the secret ships in plugin source, the HMAC is reproducible by anyone reading the code — it is not a security boundary. Identical secret across every codeandcore plugin and across both endpoints, confirming both hosts are operated by the same vendor.

The main tracker enforces opt-in (acf-wysiwyg-character-limit.php:564):

if (get_option('acf_wysiwyg_cl_tracking_optin') !== 'yes') { return; }

The deactivation handler does not check this option — it fires whenever the user submits the deactivation feedback modal.

Live endpoint state (2026-05-08)

$ curl -X POST https://wordpress-plugins.pro/deactive-receiver.php -d 'data=test&signature=test'
HTTP/2 403
Invalid signature

$ curl -X POST https://red-fly-431376.hostingersite.com/receiver.php -d 'data=test&signature=test'
HTTP/2 stream error (active receiver, not a static page)

$ curl https://wordpress-plugins.pro/
HTTP/2 401
Authentication required.

Both receivers are operational. The signature-validation behavior at wordpress-plugins.pro confirms it actively processes payloads. The host root is behind HTTP basic auth — there is no public landing page identifying who operates it. Same for the red-fly Hostinger subdomain. Neither endpoint is branded to codeandcore.com, even though every other codeandcore plugin file references that domain in headers, support links, and "Author URI" fields.

Portfolio-wide attack-shape sweep

Across all 10 codeandcore plugins:

• No eval / assert / create_function / preg_replace /e / dynamic execution anywhere
• No move_uploaded_file / wp_handle_upload / $_FILES primitives anywhere
• No update-channel hijack (no PUC, no custom auto-updater)
• No authentication backdoor or hardcoded admin grant
• No obfuscation beyond the standard AES wrapper around the analytics payload
• No other anonymous-host endpoints (no Netlify / Vercel / fly.dev / cloudfront subdomains)
• No SVN-credential change or new committer — codeandcore is sole committer for every plugin in the portfolio

Hijack-indicator matrix

Five of six indicators clean. The one positive indicator is the anonymous nature of both telemetry hosts, not the swap itself.

Comparable cases

• Audit #34 — speedy-go v2.1.0 (codeandcore): same author, same telemetry framework. The wp.org-rule violation called out in #34 (a license-bypass refactor with the changelog literally announcing "Bypassed all API key and license verification") is independent of the endpoint question and remains unresolved.
• Audit #33 — mathewt 5-plugin Netlify telemetry cluster: hobbyist Freemius-style deactivation telemetry to a Netlify subdomain, BENIGN verdict. Architectural shape is similar (modal → admin-ajax → encrypted POST to anonymous host), but mathewt's host was at least branded to a single Netlify project; codeandcore uses two separate generic anonymous hosts.

What is not present

• No eval / include / require of remote response content
• No file upload primitives or writes outside the plugin's own directory
• No update-channel hijack
• No authentication backdoor or magic header
• No obfuscation beyond the standard AES wrapper
• No third anonymous endpoint we hadn't already discovered
• No SVN-credential change, no new committer, no compromised account signal

Why suspicious rather than benign

Even with the corrected understanding (ping-pong between two long-running vendor hosts, not detection-evasion), the pattern remains hygiene-problem shape:

1. Neither telemetry endpoint is branded to codeandcore.com despite the vendor having an established public domain 2. Endpoint swaps are systematically concealed in changelog copy ("Added automatic redirect to settings page" hides an endpoint swap; "Enhanced: Deactivation feedback popup UI" hid the original red-fly addition) 3. The pattern of portfolio-wide synchronized swaps (Mar 2026 wave) plus the May 2026 outlier suggests further migrations may follow without disclosure 4. HMAC secret hardcoded in source is security theater — the signature provides no integrity guarantee

A clean release that (a) consolidates onto a codeandcore.com subdomain and (b) accurately documents telemetry destinations in changelogs would resolve the suspicious classification. We have not contacted codeandcore directly; the vendor is welcome to respond.