What it does: Puts a “Restore from wordpress.org” button beside a core file that is modified or missing, downloads that one file from core.svn.wordpress.org (falling back to raw.githubusercontent.com) and puts it back. How to access: GuardForge > File integrity, on the finding itself. Free/PRO: Free. The order of the checks is the whole feature — each step is a refusal, not a repair:

1. The path must be a key in the checksum list wordpress.org published, so there is nothing for directory traversal to work with.
2. The target must be writable, checked before anything is downloaded.
3. The download must match the published MD5, checked before anything is written.
4. The file being replaced is copied to wp-content/uploads/guardforge-restore// behind a deny rule first. It may be a live web shell: a restore that leaves it at a guessable URL has moved the shell, not removed it — and the copy is the only evidence of what was done to the site.

Notes:

• The restore is written to the audit log, and the restored file stops being a finding in the saved summary immediately, so the screen does not reload with the same row and the same button.
• Plugin files get no button. Reinstalling the release from the Plugins screen is the safe path, and the screen says so and links there.