Your website hacked? Write to us and we will handle it
If your website has been hacked, do not delete anything yet: copy the files and database, put the site in maintenance mode, tell your host and change every password and API key from a clean device. Then you need to find how they got in, clean or rebuild, and update PHP, the CMS and the server before reopening.
The same applies if your provider warned you about a vulnerability and you do not know whether it affects you. Tell us what happened, we review the server and take care of the cleanup, the updates and the new keys.
How do I know if my website has been hacked?
One of these signs is enough reason to check the server. Some intrusions are invisible from outside: the site loads normally while someone uses the server to send spam or records what your customers type into forms.
-
Chrome or Google shows a red "dangerous site" or "deceptive site" warning when people visit your website.
-
Visitors arriving from Google get redirected to casino, pharmacy or spam pages.
-
You search site:yourdomain.com and find pages nobody on your team created.
-
There are administrator accounts in WordPress or PrestaShop that you do not recognise.
-
Your host suspended the account, or emailed you about malware or outgoing spam.
-
Your provider warned you about a vulnerability (php2shell, an NGINX or Node.js CVE) and you do not know if it affects you.
-
Email from your domain bounces or lands in your customers' spam folder.
-
The browser says the website's certificate is not valid.
-
An API bill (OpenAI, Google Cloud, AWS…) arrives far above normal: someone is using your keys.
Website hacked: what to do in the first hour
These steps apply whether you contact us or not. They come in this order because the copy of the current state is lost as soon as someone starts deleting files.
- Do not delete anything yet. Copy the current state, files and database, and store it off the server. Write down the time and take screenshots of what you see. That copy is how you find out how they got in and, if you report it to the police, it is your evidence.
- Stop the harm to your visitors. Put the site in maintenance mode or serve a static page while it is being cleaned. If your host already suspended the account, do not ask them to reactivate it until it is clean.
- Tell your hosting provider. They have the server access logs and can see whether other sites on the same account are affected too.
- Change passwords from a clean device. Hosting panel, CMS administrators, FTP or SFTP, SSH, database, domain email and registrar. Turn on two-factor authentication wherever you can. If the computer you manage the site from is infected, the new passwords leak as well.
- Revoke the API keys the site stores. Payment gateway, transactional email, maps, AI services: issue new keys and disable the old ones. A copied key keeps working even after the server is clean.
- Review administrator accounts. Note the username and creation date of any you do not recognise, then delete them.
- If personal data is involved, start the clock. If the site stores customer data (orders, forms, accounts), an intrusion may be a personal data breach. Under the GDPR you have 72 hours from becoming aware of it to notify your data protection authority when it poses a risk to people.
For the clean-up review afterwards, Google explains the process in its Security issues report help. If your business is in Spain, INCIBE's free and confidential 017 helpline gives cybersecurity guidance, and the AEPD explains breach notification.
# Administrators you do not recognise? (WordPress with WP-CLI)$ wp user list --role=administrator --fields=user_login,user_registered# PHP files modified in the last 7 days$ find . -name "*.php" -mtime -7 -type f# There should be no .php files in uploads$ find wp-content/uploads -name "*.php"# Scheduled tasks you did not create$ crontab -lWith SSH access to the server. If you do not have it, your host can give you the access logs and the list of modified files.
What should I do if my provider warns me about a vulnerability?
Check which version you run, update to the fixed one and, if the flaw allowed code execution or memory reads, check whether anyone got in before the patch. These are the recent advisories that touch the most websites and servers.
PHP: php2shell
CVE-2026-109618 and CVE-2026-109619, CVSS 9.2, no authentication required. Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Wiz demonstrated remote code execution against WordPress, Drupal and Joomla.
Node.js
Ten CVEs on 21 October, including an out-of-bounds write in the Brotli decompressor that allows code execution. Fixed in v26.12.1, v24.22.1 and v22.23.4; 20.x and 25.x no longer get patches.
NGINX
"NGINX Rift" (CVE-2026-42945) saw exploitation attempts from 16 May. The October batch, with HTTP/3 request smuggling and TLS session forgery, is fixed in 1.31.7 and 1.30.6 or later.
Certificates: GoDaddy and eMudhra
GoDaddy revoked 404,607 TLS certificates on 21 October over a compliance issue; a site that does not install the replacement can become unreachable. Chrome, Apple and Microsoft stopped trusting eight eMudhra intermediate CAs with weak keys.
Secrets: LiteLLM and Railway
LiteLLM version 1.107.0, published on PyPI and Docker Hub, stole credentials on startup. Railway detected anomalous activity in the systems that store its customers' environment variables and is asking them to rotate. In both cases the keys get changed even if the server looks healthy.
The fixed versions, the commands to check them and what to rotate in each case, in one article.
What to patch, rotate and renew →How do you fix a hacked website?
Seven steps, in this order. Cleaning without knowing how they got in leaves the same door open.
-
Containment
First we stop what is still happening: redirects, outgoing spam, processes that should not be running. If needed, the site stays in maintenance mode while we work.
-
Copy and basic analysis
We keep a copy of the compromised state and look at access logs, modified files, users and scheduled tasks to find the entry point. If you need a forensic expert report for court or for your insurer, a certified expert signs that; the copy is kept so they can work with it.
-
Clean or rebuild
If there is a backup from before the intrusion and we know how they got in, it is restored and cleaned. If not, the CMS is reinstalled from official sources and only the reviewed content is migrated.
-
Update PHP, CMS and server
PHP to a patched version, CMS core, plugins and theme, and the server software (NGINX, Apache, Node.js) if you run it yourself. Anything that does not support a maintained version is replaced or removed.
-
Credential rotation
Passwords, SSH keys, API keys and environment variables. Every credential that was on the server is treated as compromised.
-
Verification and blocklists
We check the site serves what it should, request a review from Google in Search Console and check whether the domain or server IP appears on email blocklists.
-
Maintenance
Regular backups stored off the server, updates and tracking of security advisories for the software your site runs on.
- Maintenance mode if needed
- Stop redirects and outgoing spam
- Suspicious processes and connections
- Notify the host
- Copy of the compromised state, off the server
- Access and error logs
- Recently modified files
- Users, cron jobs and SSH keys
- Likely entry point
- Restore a backup from before the intrusion
- Or reinstall the CMS from official sources
- Remove backdoors and injected files
- Review the database (users, options, content)
- PHP to a patched version
- CMS core, plugins and theme
- NGINX, Apache or Node.js
- Replace whatever is unsupported
- Hosting, CMS, FTP/SFTP, SSH and database
- API keys and tokens
- Environment variables
- Two-factor authentication
- Review request in Search Console
- Email and IP blocklists
- Valid TLS certificate
- Check the site works
- Regular backups off the server
- PHP, CMS and plugin updates
- Tracking security advisories
Seeing it right now? Send us the website address and what you have noticed.
Write to us →Can the site be cleaned or does it need rebuilding?
It depends on what is on the server and whether there is a backup from before the intrusion.
It can be cleaned
- We know how they got in and the hole can be closed.
- There is a backup from before the intrusion.
- The CMS, plugins and theme support a maintained PHP version.
Better to rebuild
- There is no trustworthy backup, or the infection returns after every cleanup.
- The site depends on abandoned plugins or an unsupported PHP version.
- It is reinstalled from official sources with the reviewed content migrated, or rebuilt: for a corporate site, for example a static site with Astro, which runs no PHP on the server.
Frequently asked questions about hacked websites
What should I do if my website has been hacked?
How do I know if my website has been hacked?
Is restoring a backup enough?
How do I remove Google's dangerous site warning?
Do I have to notify the data protection authority?
Is my PHP website affected by php2shell?
Can you guarantee it will not happen again?
What do you need to get started?
Tell us what happened and we will handle it
With the website address, what you have seen and the access you still have, we review the server and tell you whether it can be cleaned, whether it needs rebuilding and what has to be updated.
Tell us your challenge. We'll propose a solution.
No commitment. Within 24 hours, you'll receive a proposal with scope, timeline and budget. No fine print.