Security Center

Open CoreX → Operations & Security for the launch checklist, operating mode, login protection, lockouts, recovery, and security activity. Open CoreX → Access & Abilities for CoreX-owned abilities and access requests.

Launch checklist

Production mode uses the same readiness snapshot shown on screen. Review the checklist before switching modes. Blocking checks stop Production unless an owner intentionally types PRODUCTION.

Maintenance mode has its own confirmation because it affects real visitors. Administrators remain able to access wp-admin, and the recovery path does not rename WordPress core files.

Login protection rate-limits failed login attempts using hashed identity/network evidence. It can also block default login endpoints behind a custom slug. The policy panel shows the active settings and the exact serialized shape CoreX uses for the security workflow.

CoreX stores bounded login-attempt evidence for reporting and recovery. It does not store passwords, raw submitted credentials, or raw IP addresses.

With hiding enabled, a signed-out request to /wp-login.php or /wp-admin gets the site’s ordinary “not found” page, and the conventional shortcuts (/login, /dashboard, /admin) stop redirecting to the custom address. /wp-login.php is byte-identical to a genuine miss; /wp-admin carries the same page with fewer of WordPress’s per-block stylesheets, so response size can still reveal that the admin address is handled specially — though not where the login moved to.

On a single site, /wp-signup.php gets that same “not found” page, and /wp-register.php is answered as a file that was never there: both exist only to forward a visitor to the registration address, which is the custom one. (WordPress has no wp-register.php file, so a web server that answers missing .php files itself, as nginx commonly does, never asks WordPress about it.) /wp-admin/customize.php is answered like the rest of the admin area. On a network, /wp-signup.php is the public sign-up page and is left alone.

Three addresses run before WordPress loads any plugin, so CoreX cannot answer them: /wp-activate.php, which redirects to /wp-login.php (itself hidden), and /wp-admin/install.php and /wp-admin/upgrade.php, which answer that WordPress is already installed. They show that the site runs WordPress. None of them names the custom address. Only a rule in the web server can change what they answer.

Hiding is obscurity, not access control: it cuts automated probing, while the rate limiting above is what defends credentials.

Recovery

If a protected route or lockout blocks owner access, run:

wp corex security reset-login

The command restores the standard wp-login.php route by disabling CoreX login-protection gates and releasing active lockouts. It does not change users, roles, passwords, content, or unrelated settings.

Use COREX_LOGIN_UNGUARD only as a temporary emergency bypass and remove it after access is restored.

What every page says the site runs

Every front-end page’s head carries one line naming CoreX, printed beside WordPress’s own:

<meta name="generator" content="CoreX" />

Technology scanners such as Wappalyzer recognise a platform by this line. It names CoreX and carries no version, because a version tells anyone looking for a vulnerable site which release to try. Removing WordPress’s generator tag, as some security plugins do, leaves CoreX’s in place.

The line is not printed on admin screens, the login page, feeds, REST responses or the Coming soon page a visitor sees, which names no platform at all. The real site served to an administrator or a preview link while Coming soon is on still carries it.

To leave it out of every page of one site, add this to the site’s own plugin or theme:

add_filter('corex_generator_tag', '__return_false');

A page cache keeps the line it was cached with: clear it after adding the filter.

Behind a proxy, a load balancer or a CDN

A request that passes through a proxy reaches WordPress from the proxy’s address. Until CoreX is told which proxies to trust, that address is the client: login protection counts failed attempts against the proxy, and a form’s rate limit is one allowance shared by every visitor.

Name the proxies:

wp corex security trusted-proxies 127.0.0.1 ::1

Each argument is an address or a CIDR range, and the list given replaces the saved one. With no argument the command prints the list. --clear trusts no proxy. The Security screen has no field for this list; the command is how it is set.

For a request that arrives from a trusted proxy, CoreX reads X-Forwarded-For from the right and takes the first address that is not itself a trusted proxy. That address is used by:

login protection, for attempts and lockouts;
the rate limit of every form and flow;
the captcha check, as the address sent to the provider with a challenge.

In front of WordPress	Trust
A tunnel or proxy on the same machine	`127.0.0.1` and `::1`
A load balancer on a private network	Its address, or the network’s range
A CDN that connects to the origin directly	The ranges the CDN publishes
A CDN in front of a load balancer	Both

Three things decide whether the answer is right:

List every proxy between the visitor and WordPress. The first one that is not listed is taken for the visitor.
List only proxies that append to X-Forwarded-For. A trusted proxy is believed about who the visitor is. One that passes a visitor’s own header through unchanged lets the visitor choose an address.
A request from anywhere else is identified by its connection, whatever headers it carries.

An entry that is not an address or a range is refused, and nothing is saved:

Error: Not an address or a range: proxy.example.com. Nothing was changed.

Access requests

Denied CoreX admin screens now show a real request-access form. The request is stored with the requested CoreX ability, requester, reason, and expiry. Administrators review requests in Access & Abilities and approve or deny them through the Access workflow.

CoreX edits only CoreX-owned abilities. Native WordPress capabilities and third-party role plugins remain external compatibility inputs.