# Your Site or Hosting Had a Security Incident? What to Do in the First 24 Hours (2026)

> A website security incident checklist for the first 24 hours: tell your site from your provider, rotate secrets in order, read audit logs and lock down.

A **website security incident checklist** is the short list of things you do when your site is hacked or your hosting provider reports a breach: confirm what happened, rotate secrets by risk, read the audit logs, close public access, redeploy and verify. Done in the first 24 hours, it limits what a leaked key or backdoor can cost you.

The trigger varies. Sometimes a customer emails a screenshot of spam on your homepage. Sometimes it is a provider notice: on 22 October 2026, **Railway** published a [**preliminary report**](https://blog.railway.com/p/preliminary-report-october-security-incident) saying environment variables were potentially exposed for at most 1.85% of workspaces, and asked everyone who signed up before 21 October to rotate their keys. It is a clear, transparent write-up, and it is a good template for what any platform should tell you.

Either way, the first day matters most. This guide walks through it hour by hour, then covers a hacked WordPress site, how to keep secrets safer next time, and what xCloud does (and doesn't do) with your credentials. If you want the prevention side first, read our [**web hosting security best practices**](/web-hosting-security-best-practices/).

## TL;DR: The Whole Checklist in Seven Lines

Short on time? Here is the whole guide in a few lines:

- **Hour 0:** write down the time, what you saw and who knows. Do not delete files or logs yet.
- **Decide the scope:** your own site was compromised, or your provider was. The steps overlap, but the order differs.
- **Rotate secrets by blast radius:** AI/LLM keys and payment keys first, then database, cloud, GitHub and registry tokens, then SMTP.
- **Revoke, don't just replace.** A new key does nothing while the old one still works.
- **Read the audit logs:** GitHub, your container registry, your cloud console, payment and AI usage dashboards.
- **Lock down:** close public database ports, remove unused GitHub app installs, force everyone to sign in again.
- **Redeploy and verify** that the new values are live and the old ones fail.

## Quick Answer: The First 5 Things to Do in the First Hour

The first hour is about stopping the bleeding, not finding the root cause. Work through these five in order.

1. **Start a timeline.** Note the time you noticed, the alert or email, and every action you take from now on. You will need it for your provider, your customers and possibly a regulator.
2. **Preserve evidence.** Do not wipe the server or delete strange files yet. Download the logs you can reach, because some platforms only keep them for days.
3. **Rotate the keys that cost money fastest.** An AI API key or a payment key in an attacker's hands turns into a bill or a refund fraud within hours.
4. **Sign everyone out.** Reset admin passwords and end active sessions on your hosting dashboard, your CMS and your Git provider.
5. **Turn on two-factor authentication** wherever it is still off, starting with the accounts that can deploy code. On xCloud that is your account's [**two-factor authentication**](/docs/two-factor-authentication-set-it-up-and-recover-access-if-you-lose-your-device/).

If you only remember one line: **rotate first, investigate second**. You can always investigate a key you already revoked.

## First: Is It Your Site, or Your Provider?

This is the sharpest dividing line, because it decides where the attacker could be right now.

| Signal | Probably your site | Probably your provider |
|---|---|---|
| How you found out | Spam pages, redirects, unknown admin users, a malware warning | An email or status-page notice from the platform |
| What is affected | One site or one server | Many customers at once |
| Where the attacker is | Possibly still inside your files or database | In the provider's systems, holding copies of your secrets |
| Your first job | Close the hole and remove the backdoor | Rotate every secret the provider stored |
| Restoring a backup helps? | Only a clean one, after the hole is closed | Rarely; the code was not the problem |

When the provider had the incident, the catch nobody talks about is that **your site can look perfectly healthy** while your keys are in someone else's hands. Railway noted, for example, that running services stayed online during its response. Healthy uptime is not evidence that nothing leaked.

When your own site was compromised, assume the attacker also read whatever the site could read: the database password, any API keys in config files, and the SMTP login.

## Rotate Secrets in the Right Order

Rotate by **blast radius**: what an attacker can do with the key, and how fast. The order below works for most web apps and WordPress sites.

| Order | Secret | Where to rotate it | What breaks if you don't redeploy |
|---|---|---|---|
| 1 | AI/LLM API keys (OpenAI, Anthropic and others) | The provider's API keys page | Chatbots, AI features and agents return auth errors |
| 2 | Payment keys and webhook signing secrets | The payment provider's developer dashboard | Checkout fails; webhooks are rejected |
| 3 | Database passwords | Your database or hosting dashboard | The app cannot connect at all |
| 4 | Cloud and storage credentials (S3, R2, backups) | The cloud provider's IAM page | Uploads and off-site backups stop |
| 5 | GitHub, CI and container registry tokens | GitHub settings, CI settings, registry account | Deploys and image pulls fail |
| 6 | SMTP and transactional email keys | The email provider | Password resets and order emails stop sending |
| 7 | App secrets (session keys, JWT secrets, WordPress salts) | Your `.env` or `wp-config.php` | Everyone is logged out, which is the point |

The trade-off is downtime. Each rotation breaks something until the new value is deployed, so rotate one row, redeploy, check, then move to the next.

The [**OWASP Secrets Management Cheat Sheet**](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) is blunt about the rule here: keys that were exposed should be revoked immediately, and a revoked secret must also be removed from wherever it leaked, including code and logs.

## Check the Audit Logs

Rotation stops future abuse. The logs tell you whether abuse already happened, and they are what turns "potentially affected" into a real answer.

- **GitHub:** organization owners can open **Settings → Archive → Logs → Audit log**. GitHub keeps the [**organization audit log**](https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization) for 180 days but shows three months by default; filter with `action:personal_access_token` or `action:oauth_application` and a `created:` date range.
- **Container registry:** look for pushes or new tokens you did not create. A pushed image is how an attacker survives your next deploy.
- **Cloud console:** new IAM users, new access keys, new regions with running instances.
- **Payment dashboard:** new API keys, changed webhook URLs, unexpected refunds or payouts.
- **AI usage dashboards:** a spend spike is often the first and loudest sign that an LLM key leaked.

For the hosting side, open your server and site event history. On xCloud you can [**view logs and events**](/docs/view-logs-and-events-of-your-server-and-site/) for each server and site, and download a log to keep as evidence.

## Lock Down: Close the Doors You Are Not Using

An incident is a good moment to remove access that should never have existed.

- **Close public database access.** A database should listen only to the app that uses it. If yours is reachable from the internet, close the port at the firewall.
- **Restrict SSH** to trusted IPs. xCloud's [**SSH lockdown**](/docs/how-to-configure-ssh-lockdown/) limits SSH to the addresses you whitelist.
- **Revoke unused OAuth and GitHub app installs.** Every connected app is another set of credentials that can be stolen.
- **Remove old team members and stale deploy keys.**
- **End support sessions you no longer need.** On xCloud, regenerating the code under [**support access**](/docs/grant-and-revoke-xcloud-support-access/) stops the old code and ends active support sessions.

## Redeploy and Verify

A rotated key that never reached production does nothing. Verification is the step people skip, and it is the one that proves the incident is over.

1. **Redeploy every app** that uses a rotated value, so the new value is loaded. Some platforms paused deploys during their incident; Railway, for example, asked customers to redeploy commits pushed during the pause.
2. **Test each feature that depends on a key:** checkout, email, login, file upload, AI features.
3. **Try the old key.** It should fail. If it still works, you replaced it without revoking it.
4. **Recreate CLI and CI credentials** on the machines that deploy, not just in the dashboard.

Keep notes on each check in your timeline. "Old Stripe key returns 401 at 14:20" is the kind of line that ends an argument later.

## If Your WordPress Site Itself Was Hacked

Here's the part that trips people up: **cleaning the files is not the same as closing the hole.** Three patterns explain why a cleanup often doesn't hold.

- **Spam that comes back.** Malicious files or a scheduled PHP job regenerate the spam pages after each cleanup, so check cron jobs and recently changed files, not just the visible pages.
- **Infected backups.** Restoring a backup that already holds the backdoor brings the problem straight back.
- **Leftover access.** Cleanup fails when unknown administrator accounts and old credentials survive it.

Work through it in this order:

1. **Find the entry point:** an outdated plugin or theme, a reused password, or an unsafe upload. Our write-up on a [**WordPress PHP shell attack**](/php2shell-wordpress/) shows what a real one looks like.
2. **Remove unknown admin users** and reset every remaining admin password.
3. **Change the keys and salts** in `wp-config.php`. This invalidates every login cookie, including a stolen one.
4. **Rotate the database and SFTP passwords.** On xCloud, a site's SFTP password is set in its [**SSH/sFTP settings**](/docs/how-to-configure-sftp-access/).
5. **Compare files** against clean copies of WordPress core, your plugins and your theme, and reinstall anything that differs.
6. **Restore only a backup from before the compromise.** Use [**restore a backup to another site**](/docs/how-to-restore-a-backup-to-another-site/) to inspect it safely before it replaces production.
7. **Add a firewall and login protection.** [**Site Security Pro**](/docs/set-up-site-security-pro/) adds Patchstack's vulnerability protection, and [**BetterShield**](/bettershield-replaces-wp-fail2ban/) blocks repeated failed logins.

If a third party reports the site for phishing or malware, reply to the report quickly. On xCloud, support asks you to investigate and secure the site, usually within 24 hours, and a clear phishing report can suspend the site as a precaution until the xCloud team reviews your reply and what you fixed. [**Why xCloud suspends a site or server**](/docs/why-xcloud-suspends-a-site-or-server-billing-and-abuse/) explains how that review works.

## Keep Secrets Safer Next Time

Most of the pain above comes from a few habits. Change them once and the next incident is a 30-minute rotation instead of a lost weekend.

- **No secrets in repos or build logs.** OWASP's advice is that secrets should never be logged and that pipeline output must not leak them.
- **Scoped tokens.** A deploy token that can only read one repository is a small loss when it leaks.
- **One key per environment.** Staging and production should never share a payment or AI key.
- **Expiry dates.** A fine-grained token that expires in 90 days limits how long a forgotten leak stays useful.
- **A written rotation list.** Keep the table above, filled in with your own keys, somewhere you can reach when your laptop is the thing that was compromised.
- **Tested backups.** A backup you never restored is a guess. See the [**website backup mistakes**](/website-backup-mistakes/) people make, and the server-side habits in [**maximize your VPS security**](/maximize-your-vps-security/).

## How xCloud Stores Your Secrets

This section is facts only, so you know what to rotate on xCloud and where.

**What xCloud does today:**

- **Passwords are encrypted per field** in xCloud's database. Site database, Redis, admin and SSH passwords, and server database, Redis, sudo and SSH passwords, are each stored encrypted rather than as plain text.
- **Your app's environment file is on your server, and xCloud keeps an encrypted copy of some of them.** You edit it on the site's **Environment** page. For Git, Docker Compose, Node.js and one-click app sites, xCloud also stores the environment file encrypted in its database so it can write it again on each redeploy. For a Laravel site, the editor reads and writes the file on the server, as the site's own user. After a leak, change the keys in the dashboard editor, not only on the server, or the next redeploy can put the old values back.
- **You can rotate the access you control from the dashboard:** the site SFTP password, SSH keys, your account's two-factor authentication and the support access code.
- **Logs and events** for every server and site are in the dashboard, and you can download them.

**What xCloud doesn't do:**

- **Malware removal and forensic cleanup are not part of standard support.** As the [**support scope**](/docs/how-xcloud-support-scope-works-for-different-services/) page says, support helps with logs, backups, restore guidance and firewall settings, but the cleanup itself is a specialist job.
- **xCloud cannot rotate keys held by other services.** Your AI, payment, GitHub and email keys must be rotated at each provider, then updated in your environment file.

## Get Through the Next 24 Hours, Then Fix the Habit

A security incident feels like chaos, but the response is a list. Rotate by blast radius, revoke the old keys, read the logs, close what you don't use, then prove the new values are live.

This week, write your own rotation table while nothing is on fire. The next time a provider sends a notice, or a customer sends a screenshot, you will spend an hour on it instead of a day. If you get stuck on the hosting side, our [**support team**](/docs/access-built-in-support-portal-in-xcloud/) can help with logs, backups and restores.

If you have found this blog helpful, feel free to [**subscribe to our blogs**](https://xcloud.host/blog/) for valuable tutorials, guides, knowledge, and tips on web hosting and server management. You can also join our [**Facebook community**](https://www.facebook.com/groups/xcloud.community) to share insights and engage in discussions.

## Frequently Asked Questions

### What should I do first after a security incident?

Write down the time and what you saw, then rotate the secrets that can cost you money or data the fastest: AI and payment API keys, then database and cloud credentials. Do not delete anything yet, because logs and files are your evidence.

### My provider says I may be affected. Was my account hacked?

Not necessarily. A notice or a key-revocation email from a vendor usually means your secrets were in scope, not that someone used them. Rotate anyway and read your audit logs, because you cannot prove a key was never used.

### Is replacing an API key the same as revoking it?

No. Adding a new key leaves the old one valid until you delete or revoke it at the provider. Revoke the old key after the new one is live, then confirm the old one fails.

### Should I restore a backup after my WordPress site was hacked?

Only a backup from before the compromise, and only after you know how the attacker got in. A recent backup can carry the same backdoor, and restoring without closing the hole lets the attacker straight back in.

### Does changing WordPress salts log everyone out?

Yes. New keys and salts in wp-config.php invalidate every login cookie, so every user, including an attacker with a stolen session, has to sign in again. It does not change passwords, so reset those as well.

### Does xCloud clean malware from hacked sites?

No. Malware removal and forensic cleanup are not part of standard xCloud Support. Support helps with logs, backups, restore guidance and firewall settings, and a security specialist handles the cleanup itself.