Setyenv · Docs
  • English
  • Spanish
  • Chinese
  • Japanese
  • Arabic
  • German
  • French
  • Hindi
  • Indonesian
  • Italian
  • Dutch
  • Portuguese
  • Russian
  • Turkish

Security model

wp-executor runs commands on a real host on your network. The security model is built so that compromising the WordPress side does not automatically translate into arbitrary code execution on the executor's host.

Authentication

Every upstream call carries a worker-specific bearer token and, by default, an X-PFW-Signature HMAC-SHA256 of the request body. Disable the second factor only if you understand the trade-off; with it on, an intercepted bearer token alone is not enough to impersonate the worker.

Token handling

  • The bearer token is provisioned through the WP-PFWorkflow administration UI and shown in plain text exactly once.
  • The executor never writes the secret to disk beyond your config.toml and never emits it in log output.
  • show-config redacts the token before printing.
  • Tokens can be rotated from the WordPress side at any time; the old token is invalidated immediately and the worker will need the new value in its config before it can claim its next job.

Capability allowlist

Capabilities are double-gated:

  • Server-side — the WP-PFWorkflow admin chooses which capabilities this worker is allowed to perform.
  • Client-sideallowed_capabilities in config.toml restricts what this particular install of the binary is willing to perform.

The intersection of the two applies. A worker can never run a capability either side has forbidden.

Process privileges

Capabilities run with the privileges of the user the executor process runs as. Install the worker under a dedicated low-privilege user where you can — the Linux installer does this by default.

TLS

TLS is provided by rustls; OpenSSL is not a dependency. Rotating the system trust store is enough to update the executor's trust anchors.

Lease model

When the worker claims a job it acquires a time-bounded lease. Heartbeats extend the lease while the job runs; if the worker dies mid-job, the lease eventually expires and the platform makes the job available for re-claim. Result-posting is idempotent on the job id, so a slow worker that finishes after a re-claim does not double-write the outcome.