WP Sudo adds action-gated reauthentication to WordPress so high-risk operations require fresh confirmation before they proceed.

Playground demo credentials are admin / password. When WP Sudo asks for reauthentication, enter the same password: password.

3.2.0 security hardening: governance capabilities, WPGraphQL classifier hardening, per-user IP lockout, cookie Secure-flag fallback via FORCE_SSL_ADMIN, request-stash minimization, and more. See CHANGELOG.md and docs/release-status.md for details.

• Governance capabilities: sudo_can() helper, Access tab for managing who can administer sudo settings, and WordPress capability integration for WP-CLI and audit plugins
• WPGraphQL gate hardening: CR/CRLF comment tokenizer, block-string escaping, BOM stripping, persisted-query fail-safe, multipart and GET query param coverage
• REST plugin gate: folder-based plugins (e.g. akismet/akismet) are now correctly gated on the REST surface
• Per-user IP lockout: shared egress IPs (office NAT, VPN, CGNAT) can no longer be used to DoS all admins with five failed attempts from one account
• Cookie Secure-flag hardening: FORCE_SSL_ADMIN fallback + wp_sudo_cookie_secure filter for TLS-terminating proxy setups
• Request-stash minimization: $_GET removed from stash, per-rule POST allowlists, suffix-based secret redaction for compound field names, unsafe-replay blocking
• App Password policy validation: UUID format + existence check before persisting; automatic cleanup on password deletion
• Admin email gating: new_admin_email writes are now challenge-gated on interactive and REST surfaces

WordPress has roles, capabilities, and authentication, but it has no native way to say:

this action is consequential enough that a valid session alone should not be enough.

WP Sudo adds that missing layer on the covered paths it intercepts.

It is designed to reduce risk when an attacker has:

• a stolen browser session cookie,
• access to an unattended authenticated browser,
• or a delegated request path that reaches a high-impact operation.

On those covered paths, a valid session without an active sudo window is not enough.

What this is not: a general fix for broken authorization in plugin code. WP Sudo gates specific known operations on specific known surfaces. A plugin vulnerability that performs a privileged state change through its own code path — without routing through a surface WP Sudo intercepts — is outside this layer. WP Sudo is the guard at the door of the operations it knows about; it is not a monitor of arbitrary plugin execution.

WP Sudo currently gates built-in operations across categories such as:

• plugin and theme management,
• user creation, deletion, and role changes,
• file editor access,
• critical option changes,
• WordPress core updates,
• export flows,
• WP Sudo settings themselves,
• selected Multisite network actions,
• and connector credential writes saved through the REST settings endpoint.

For the canonical current rule totals and surface counts, see docs/current-metrics.md.

For wp-admin flows, WP Sudo redirects the user to a challenge screen. After successful reauthentication, the original request can continue.

These receive a sudo_required error instead of silently proceeding.

WP Sudo supports configurable policies for:

• WP-CLI
• Cron
• XML-RPC
• REST Application Passwords
• WPGraphQL (when active)

Each surface can be set to Disabled, Limited, or Unrestricted.

WP Sudo is deliberately narrow. It is not:

• a replacement for WordPress capabilities,
• a firewall or exploit detector,
• a fix for arbitrary broken access control inside third-party plugin code,
• or a sandbox for malicious in-process code.

It is strongest when an attacker has a valid session but does not have an active sudo window and must cross one of the plugin's covered action paths.

Active sudo is per browser session, not site-wide.

• WordPress: 6.2+
• PHP: 8.0+
• Multisite: supported

For current release posture, supported lanes, and forward main notes, see docs/release-status.md.

1. Install and activate WP Sudo.
2. Go to Settings → Sudo.
3. Choose a session duration.
4. Review the default policies for non-interactive surfaces.
5. Optionally install the bundled mu-plugin loader from the settings page for earlier hook registration.
6. Test a covered action such as plugin activation or a protected settings change.

• Two Factor — strongly recommended for password + second-factor challenge flows.
• WP Activity Log or Stream — recommended if you want audit visibility from WP Sudo's action hooks.

• docs/security-model.md — threat model, boundaries, and environmental assumptions
• docs/FAQ.md — practical questions and operational caveats
• docs/release-status.md — current stable release state and forward-lane posture

• docs/developer-reference.md — hooks, filters, custom rule structure, and integration API details
• docs/two-factor-integration.md — Two Factor integration behavior
• docs/connectors-api-reference.md — connector credential gating notes
• docs/ai-agentic-guidance.md — AI and agent tooling guidance

• tests/MANUAL-TESTING.md — manual verification procedures
• docs/current-metrics.md — canonical current counts and architectural facts
• docs/ROADMAP.md — roadmap and backlog
• CHANGELOG.md — release history

• docs/sudo-architecture-comparison-matrix.md — comparison with other sudo/reauth approaches
• docs/abilities-api-assessment.md — WordPress Abilities API assessment
• docs/core-action-gate-proposal.md — longer-form core proposal and design thinking
• docs/llm-lies-log.md — verification discipline and past documentation failures
• docs/project-introduction.md — the longer conceptual introduction, graphic, poem, and gate metaphor preserved from the earlier README

Quick local checks:

composer install
composer test:unit
composer lint
composer analyse

For full setup, integration tests, E2E workflows, and contributor expectations, see CONTRIBUTING.md.

GPL-2.0-or-later.