An agent that installs nothing

By default it only reads

Once a website is connected, digiWatcher asks the agent every hour for data you can’t get from outside: WordPress and PHP versions, counts of pending updates, the list of plugins and themes with their versions, the state of scheduled tasks and the database, free disk space, and whether the site shows debug errors to visitors. The agent changes nothing in the database except its own settings. The address where the agent hands out this data returns nothing without a valid token, not even to a logged-in administrator. The site’s administrator can turn off the plugin and theme list in the plugin settings; everything else keeps working.

Updates only with permission

Write access is off until the site’s administrator turns it on, and they can turn it off at any time. With write access on, the agent accepts four signed update instructions: check for available updates, update one plugin, theme, or WordPress core, roll files back from a restore point, and confirm that an update went well. An update instruction carries no package URL. The agent updates only to the version WordPress’s own update source offers at that moment, which is the same package the Update button in the admin would install. Updates don’t run on multisite networks or where WordPress can’t write files directly.

What it never does

• It never installs a new plugin or theme.
• It never uploads a ZIP file and never uses a file editor.
• It can’t change the site’s settings.
• Its monitoring data contains no server disk paths and no passwords; the file check reports paths inside the site, never file contents.

Even a stolen write key would let an attacker do no more than WordPress itself does during an automatic update. How updates run across many websites is on the bulk WordPress updates page.

In short: the site accepts only signed instructions from digiWatcher, and the plugin installs only its own updates, signed by the operator. The technical details follow.

Every instruction is signed

digiWatcher signs each update instruction with a key that only digiWatcher and that one website know. The write key is separate from the token used for reading. Each instruction carries the time and a one-time number: an instruction more than five minutes off is refused, and an intercepted instruction can’t be sent again.

The plugin checks its own updates

New versions of the digiWatcher Agent are signed with an Ed25519 key that stays on the machine where versions are released; digiWatcher’s server doesn’t have it. The plugin carries only the public key, written into its code rather than its settings, so nobody can change it from the WordPress admin. The address it gets updates from is fixed in the code as well.

When WordPress updates the plugin, the agent downloads the package itself and passes it on for unpacking only if the signature matches. Without a signature, with a wrong one, or without the PHP sodium extension needed to check it, nothing is installed. The version inside the verified package must also be newer than the installed one and match the offered version, so an older signed package with a known flaw can’t be slipped in.

A digiWatcher account has two roles. The Owner manages websites, alert contacts, users, client access, and the subscription. An Operator sees every website, runs and pauses checks, acknowledges incidents, and writes notes, but can’t delete websites, change settings, or read alert contacts.

Anything that changes a WordPress site is for the Owner only: single and bulk updates, automatic update rules, write access settings, and the one-time login to the WordPress admin. The server checks the role on every such request. Hiding a menu item isn’t treated as access control: a page the role doesn’t allow sends the user back to the Overview, and the checks in the API apply regardless.

Before a one-time login, the Owner has to confirm their password, plus the code if they use two-factor authentication, unless they did so in the last 10 minutes. A stolen session cookie alone isn’t enough to get into a client’s WordPress admin.

For monitoring and the security log, the agent identifies WordPress users by account number. The security log records new and removed administrators, changes to the administrator email and the site address, and administrator logins. For users it sends the account number and creation date; the administrator email only as a fingerprint, never in readable form. For these purposes it doesn’t send names, email addresses, or IP addresses, and failed logins are reported only as a count. The site’s administrator can turn the security log off in the plugin settings.

Exceptions the site’s administrator turns on

One-time login to the WordPress admin is a separate option in the plugin settings. It’s off by default, and neither connecting for monitoring nor allowing updates turns it on: the site’s administrator has to check it. It works only over HTTPS and not on multisite.

Once it’s allowed, the Owner in digiWatcher can choose which WordPress administrator to log in as. To offer that choice, digiWatcher asks the site for its administrators, and the agent returns each one’s display name and username, up to 100 accounts. That request is signed with a separate login key, and digiWatcher saves only the number of the account you select. Each login is a single-use request that expires within a minute. Changing the setting in WordPress cancels requests that haven’t been used yet, but it doesn’t end WordPress sessions that are already open. If administrator names shouldn’t leave the site, keep one-time login off.

Sending encrypted copies of the site to digiWatcher is off by default, the plugin settings don’t offer it, and digiWatcher can’t turn it on remotely. If the site’s administrator turns it on in WordPress anyway, a copy contains the whole site database, including the users table; digiWatcher can open it.

These limits describe how the agent is built. They’re not a guarantee that a compromised WordPress site or server can’t be misused, and they don’t replace your own security measures. digiWatcher doesn’t include a firewall or malware cleanup.

The plugin’s readme lists every service the agent contacts and what it sends there. How to connect a site step by step is in the manual chapter on connecting WordPress, and how digiWatcher fits a team’s daily work is on the WordPress management page.