We removed detected malicious code from the EspaDent website, restored WordPress files and strengthened upload protection. The main work took place in August 2026. Cleanup, updates and website checks are described separately below.
Project website: EspaDent
What needed to change
The review started with access, then moved to files and server settings. The working documents identified suspicious executable files and rules that allowed them to run.
We needed to remove the detected code and check the restored website. The available evidence did not establish how the initial intrusion happened.
Work and results
| Work | Result | Period or source |
|---|---|---|
| Removing detected malicious code | 1 website recovered | August 2026 |
| Plugin updates and WordPress checks | 8 plugins updated | August 2026 |
| Checking uploaded files | 2 protection layers configured | August 2026 |
Removing detected malicious code
1 website recovered · August 2026
We removed the detected malicious code and restored WordPress system files. We checked the database, homepage and admin login.
After restoring files, access needs checking: unknown accounts and excessive permissions require separate investigation. Replacing files alone does not remove an attacker’s access.
We also checked what allowed the detected files to run. Deleting one file is insufficient if another route remains for execution or reinfection.
Plugin updates and WordPress checks
8 plugins updated · August 2026
We updated eight available plugins and restored WordPress files. We then checked core integrity and database operation.
The website was checked after updates. A successful component update does not confirm compatibility of every feature or the absence of page errors.
Checking uploaded files
2 protection layers configured · August 2026
We configured two layers of protection: blocking script execution in the uploads folder and checking uploads for dangerous extensions and PHP code.
Uploads were checked separately from the theme and plugins. Server code should not execute in a folder intended for visitor content.
The screenshots show the clinic’s current public page on desktop and mobile. Malicious code, private records and login details are not published.
How we checked the results
After recovery, we checked the homepage, admin login, core files and database. The follow-up check covered the detected threats and agreed scope.
Our article on signs of a hack explains that a bot request, even with HTTP 200, does not prove command execution. Requests need comparison with files and other server events.
We opened the public website to capture this case. We did not send new enquiries to the clinic.
What to keep in mind
Removing detected code and passing the checks do not rule out every hidden threat. Establishing the cause of intrusion requires separate examination of logs, access and change history.
The current screenshot shows the interface. It does not confirm server security or uninterrupted operation since the August recovery.
Before similar work
When recovering WordPress, review cleanup, updates and upload protection separately. The report should list the parts checked and the questions still open.