Skip to content

Incident: TnE Connect WordPress — total admin lockout after Wordfence install

id: INC-2026-06-04-tneconnect-wp-lockout
status: resolved
severity: high
opened: 2026-06-04
resolved: 2026-06-04
detected_by: Vishnu Kant (reported by the team — no one could log in)
resolved_by: Vishnu Kant (with Claude)
host: E2 (EIDOSDev1 Dokploy VPS, 145.241.230.130)
app: tneconnect.app ([apps/13-tne-connect-wordpress.md](../../apps/13-tne-connect-wordpress.md))
related_kis: [KI-048, KI-004, KI-038, KI-034]
related_runbooks: [RB-007]
fix_applied: Force-deactivated Wordfence on disk via the container shell, then created an Eidos-owned administrator with wp_insert_user
duration: same-day (hours from report to recovery)

Summary

The TnE Connect marketing site (tneconnect.app, WordPress on E2 / Dokploy) became completely inaccessible for login. The external dev agency Red 13 Digital had rebuilt the site and installed Wordfence (plus other plugins). After the install, no one could log in to wp-admin — not Eidos, and not the developers. Previously-working passwords were rejected.

The public site stayed up throughout; this was a login-layer lockout, not an outage. It was resolved the same day by going in underneath the plugin via the Dokploy container shell: Wordfence was force-deactivated on disk and a fresh Eidos-owned admin account was created. A full backup was then taken and credentials were stored in Vault.

This is the incident that RB-007 was written from.

Impact

  • tneconnect.app admin was inaccessible to everyone — content could not be edited or published, and the lead-capture / forms config could not be touched.
  • Public site unaffected — the front-end continued to render and serve visitors; no customer-visible outage.
  • No data loss — the database and content were intact throughout (the oldest admin account dated to July 2024, confirming no DB wipe).
  • Latent exposure exposed: Eidos had no owned administrator account on the site at all. The only two admins both belonged to the third-party dev agency (alex@red13digital.co.uk, mark@red13digital.co.uk). Had the agency been unreachable and the host backend not available, recovery options would have been far worse. Tracked as KI-048.

Root cause

Wordfence was installed and configured by the dev agency without an allow-list for the operators' IPs and (most likely) with login-security features enabled — its brute-force lockout, 2FA enforcement, and/or breached-password rejection combined to block every login attempt, including with correct credentials. Because there was no Eidos-owned admin and no documented allow-list, the people who could have un-stuck it from inside wp-admin were themselves locked out.

Contributing conditions:

  • No Eidos-owned admin account — total dependency on the third-party dev for admin access (KI-048).
  • Unsupervised change — the agency installed/reconfigured plugins on a production site with no change gate (KI-004).
  • No off-host backup existed at the time of the lockout — taken only after recovery (KI-038).

What was on the box

WordPress on E2 (Apache 2.4.66 / PHP 8.3.30), container a4b09580571f, web root /var/www/html. Active plugins at the time included: advanced-custom-fields-pro, acf-content-analysis-for-yoast-seo, better-search-replace, duplicate-post, ewww-image-optimizer, ninja-forms (+ ninja-forms-zapier), wordpress-seo (Yoast), worker (ManageWP), wp-file-manager, wp-mail-smtp, and wordfence (the culprit). WP-CLI was not installed in the container.

Recovery (what was actually done)

Full procedure generalised into RB-007. The specific steps taken:

  1. Opened a shell into the WordPress container via Dokploy backend access. Confirmed WP-CLI was absent (wp: command not found).
  2. Listed wp-content/plugins; identified wordfence as the only security plugin.
  3. Force-deactivated Wordfence on disk (filesystem, reversible, no DB change): 
    mv wp-content/plugins/wordfence wp-content/plugins/wordfence.off
    The wordfence-waf.php auto-prepend in the web root is self-guarded, so the front-end did not break.
  4. Inventoried admin accounts with a small wp-load.php PHP script — found only the two Red 13 Digital admins; the 2024 registration date confirmed the DB was intact (not a fresh wipe).
  5. Created Eidos-owned administrators with wp_insert_user via a one-off PHP script (then deleted the script). Two owned admins now exist: eidosadmin (Adam) and vishnu (Vishnu).
  6. Logged in successfully at https://tneconnect.app/wp-login.php with the new accounts.

Hardening done after recovery

  • Full site backup taken and shipped off-host. All-in-One WP Migration export (.wpress) uploaded to the PECommon bucket (EIDOSDev1): tneconnect.app/allin1_bkp/tneconnect.app-20260604-202340-947.wpress (object-storage namespace lrqsoobrqq3r). This is the first off-host backup of this site. Recorded in backups.md.
  • Credentials stored in Vault at kv_pe/tneconnect.app (vault.448.global/ui/vault/secrets/kv_pe/kv/tneconnect.app) — admin login, DB / wp-config.php, and related secrets. Recorded in apps/13-tne-connect-wordpress.md.
  • Eidos now holds two owned admins on the site — eidosadmin (Adam) and vishnu (Vishnu) — breaking the sole dependency on the dev agency and giving a second owned account if one is lost.

Lessons learned

  • A security plugin guards the login form, not the host. With Dokploy / container backend access the operator is never truly locked out — go in underneath and disable the plugin on disk. Renaming the plugin folder is the safest, most reversible off-switch and needs no WP-CLI, MySQL client, or internet.
  • Own an admin account on every site you operate. Depending on a third party for the only admin login is a single point of failure that turns a five-minute plugin tweak into an incident. This is now KI-048; the standing fix is an Eidos-owned admin on all three Dokploy WordPress sites.
  • Back up before letting a third party rebuild a production site, not after. The first off-host copy of this site existed only because of this incident.
  • Allow-list operator IPs and stage 2FA before enforcing it. When Wordfence (or any login-security plugin) is re-enabled, the owned admin must be allow-listed and 2FA-enrolled first — see RB-007 Step 8.

Action items

  • Recover admin access to tneconnect.app (two Eidos-owned admins created: eidosadmin, vishnu).
  • Take a full off-host backup (.wpress → PECommon bucket).
  • Store credentials in Vault (kv_pe/tneconnect.app).
  • Write recovery runbook (RB-007).
  • Raise the standing risk as a KI (KI-048).
  • Ensure an Eidos-owned admin exists on the other two WordPress sites (projecteidos.com, eidos-global.com) and store their creds in Vault.
  • Re-enable Wordfence on tneconnect.app with operator IPs allow-listed, breached-password lockout reviewed, and 2FA enrolled for the owned admin first (RB-007 Step 8).
  • Define a change gate / pre-change backup expectation with Red 13 Digital before they touch production again.
  • RB-007 — WordPress admin lockout recovery runbook (written from this incident).
  • KI-048 — no Eidos-owned admin on the Dokploy WordPress sites.
  • KI-004 — Dokploy-hosted apps have no managed update / change control.
  • KI-038 — E2 has no block-volume backups.
  • KI-034 — TnE Connect code held by the external dev (related third-party-control theme).
  • apps/13-tne-connect-wordpress.md — the site's app doc.