SiteHelm gives an AI agent write access to a WordPress site. Security reports are taken seriously and handled first.

Do not open a public issue.

Use GitHub's private reporting: Report a vulnerability. If that is unavailable to you, email mr.shahidali.sa@gmail.com with SiteHelm security in the subject.

Please include:

• What an attacker can do, and what access they need to start.
• The affected operation or component, and the SiteHelm version.
• WordPress and PHP versions, and any relevant plugin versions (Elementor, ACF, Meta Box).
• Steps to reproduce, or a proof of concept.

You will get an acknowledgement within 72 hours and an assessment within 7 days. A fix ships in a patch release, and the advisory credits you unless you ask otherwise. Please give a reasonable window before public disclosure.

• Bypassing a capability check, or performing an operation the authenticating WordPress user could not perform by hand.
• Authentication bypass on the REST route, or accepting an unauthenticated request.
• Escaping an operation's declared surface: writing outside the target, mutating something the input schema does not address, or executing arbitrary code, SQL, or filesystem access.
• SSRF through media-import, including any way to reach a private, loopback, link-local, or reserved address, or to re-point a connection after validation.
• Information disclosure in a response envelope: a stack trace, filesystem path, SQL fragment, database error string, authorization header, resolved IP address, or a field value appearing in a warning or refusal.
• Defeating the two-phase write: replaying, forging, or reusing a plan token, or applying a change whose arguments differ from the previewed ones.
• Anything that makes a change unrecoverable — corrupting a snapshot, or bypassing the ledger.

• Findings that require an administrator account acting deliberately. An administrator can already do these things through wp-admin; SiteHelm does not, and cannot, restrict them.
• Vulnerabilities in WordPress core, Elementor, ACF, Meta Box, or any other third-party plugin. Report those to their maintainers.
• Sites running below the supported floors (WordPress 6.6, PHP 8.1), or with the REST API exposed over plain HTTP. Always use HTTPS: an Application Password sent over HTTP is already compromised.
• Missing hardening headers, rate limiting, or brute-force protection on the WordPress install itself.
• Reports generated by an automated scanner with no demonstrated impact.

• Every operation runs a real WordPress capability check against the authenticating user before any target is looked up.
• Every write is previewed, snapshotted, applied, and read back. A read-back that disagrees with the preview is reported as a failure, not swallowed.
• Plan tokens are single-use and bound to the previewed arguments.
• Nothing hard-deletes. content-trash is reversible; permanent deletion is permanently out of scope, along with arbitrary PHP, unrestricted SQL, and unrestricted filesystem access.
• media-import resolves and validates the host before connecting, refuses private and reserved ranges, re-validates and re-pins every redirect hop, pins the resolved address so the connection cannot be re-pointed between check and fetch, caps the wire read, and returns a deliberately digit-free refusal so it cannot be used as an SSRF oracle.
• All SQL goes through $wpdb->prepare, with table names from the installer rather than a hardcoded prefix.

• Serve the site over HTTPS. Always.
• Give the agent's Application Password an account with the least role that can do the work. SiteHelm enforces WordPress capabilities faithfully — which means an administrator credential gives an agent administrator reach.
• Rotate the Application Password if it may have been exposed, and revoke it when the integration is retired.
• Read the change ledger (audit-list) periodically. It is there to be read.