How Do I Know If My Website Has Been Hacked? Signs, Checks and Fixes

You usually find out from a warning (a browser, Google Search Console, your host or a customer), strange content in search results, or a server change you did not make, such as a new admin user or a PHP file in an uploads folder. Confirm it with Search Console, official file checksums and your access logs.

Below are the checks in detail, with commands for WordPress, Drupal, Joomla and hand built sites, plus how to choose between cleaning and restoring and what to update afterwards.

Key takeaways

• Most hacks are found by someone else first: a Search Console alert, a browser warning, your host or a customer. Register in Google Search Console and Bing Webmaster Tools before you need them.
• Looking at the homepage is not a test. Injected content is often hidden from logged in administrators and shown only to crawlers, phones or visitors arriving from search. Google calls this cloaking.
• The server tells the truth. Unknown admins, PHP files in upload folders, new scheduled tasks, changed .htaccess files and failed checksums beat anything you see in a browser.
• The usual way in is an outdated component, followed by weak or reused passwords. CISA, Google and the WordPress project all put patching first.
• Restore from a verified clean point, then patch before going live. Google's cleanup guide says around 20 percent of hacked sites are hacked again within a day.
• Change every credential twice: when you find the hack and again once the site is clean.

What are the visible signs that a website has been hacked?

Visible signs are what a visitor or search engine sees without logging in. They are easy to miss if you only check your own site from your own laptop.

Browser and search engine warnings

If Google decides your site serves malware or deceptive content, browsers that use Safe Browsing can show a warning page, and search results can carry a hacked site note. Google's Search Console documentation says these warnings vary by context, so you may not reproduce one yourself, and it treats the Security Issues report as the authoritative source for whether a problem remains.

The WordPress "My site was hacked" FAQ lists the same family of indicators: blocklisting by Google or Bing, a host disabling the site, a malware flag, visitors' antivirus complaining, or reports that the site is attacking others.

Spam content and odd search snippets

The most common hack on small business sites is search spam: pages of pharmacy, gambling or foreign language keywords that reuse your theme. Google's guide to the cloaked keywords hack describes code that generates many such pages to manipulate rankings, sell links and sometimes redirect visitors. You see it as:

• Search results for your domain with titles or descriptions in a language you do not publish in.
• A site:yourdomain.com search showing thousands of pages you never created, often under unfamiliar paths.
• A sudden jump in indexed pages or impressions in Search Console for queries that have nothing to do with your business.
• Search Console messages about a new owner or a sitemap you did not submit.

Redirects

A visitor clicks your search result and lands on a scam page or unrelated shop, often only once, only on phones or only from search. Google's spam policies call this a sneaky redirect: sending people to a different URL than they asked for, deceptively.

Defacement, breakage and outside signals

Defacement is now one of the rarer outcomes. More common are a checkout that throws errors, encoded text printed at the top of every page, or a slow site that is busy sending spam. Outside signals include a host suspension notice, your server IP on email blocklists (the WordPress FAQ warns this hurts email from the same server), customers reporting card fraud after buying from you, and abuse complaints that your site hosts phishing.

What are the hidden signs?

Hidden signs live on the server, in the database and in the admin panel. Many hacks stay invisible for weeks because the attacker wants persistent access, not attention.

Unknown or changed administrator accounts

A new admin with a plausible name (admin2, support) or a known account whose email changed is one of the clearest signs. The WordPress FAQ lists new user creation as an indicator of compromise. On WordPress with WP-CLI:

# List every administrator with creation date and email
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Show all users sorted by registration date, newest last
wp user list --fields=ID,user_login,roles,user_registered --orderby=user_registered

On Drupal check People filtered by the administrator role; on Joomla check the Super Users group.

New files in upload and cache folders

Script files in upload directories are almost never legitimate. A PHP file inside wp-content/uploads, sites/default/files or images strongly suggests a web shell, which CISA describes as a script uploaded to a web server to give an attacker remote administration.

# PHP or other executable script files where only media should live
find /var/www/html/wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -print

# Any file in the web root changed in the last 14 days
find /var/www/html -type f -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

# Files newer than your last known deployment marker
find /var/www/html -type f -newer /var/www/html/wp-includes/version.php -print

CISA lists files newer than your last application update, and suspicious files in the web root, as indicators. Timestamps can be faked, so use them to find leads, not to rule files out.

Changed scheduled jobs

A cron entry that re-downloads a backdoor every hour will undo a manual cleanup within the hour.

# System and per user cron entries for the web server account
crontab -l
sudo crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily

# WordPress has its own scheduler stored in the database
wp cron event list --fields=hook,next_run_relative,recurrence

Look for anything unfamiliar that fetches a URL, decodes text or writes into the web root, and check the hosting panel's cron screen too.

Changed configuration and rewrite rules

Google's cloaked keywords guide flags .htaccess rewrite rules that send requests to a randomly named PHP file. The WordPress FAQ says .htaccess is among the files most often changed, and it can sit in several directories.

# Every .htaccess file in the tree, with modification time
find /var/www/html -name ".htaccess" -printf '%TY-%Tm-%Td %TH:%TM %p\n'

# Rewrite rules that point at PHP files, for manual review
grep -rn "RewriteRule" --include=".htaccess" /var/www/html

Check the site URL settings as well. On WordPress, wp option get siteurl and wp option get home should return your own domain.

Encoded or obfuscated code

Google's cleanup guide suggests looking for long blocks of jumbled text alongside decoding and execution functions. This search gives false positives but a list to review by hand.

# Candidate files for manual review; expect some legitimate hits
grep -rlE "base64_decode|gzinflate|str_rot13|strrev|eval\s*\(" /var/www/html --include="*.php" | sort

CISA warns that antivirus often detects web shells poorly and that many indicators appear in legitimate files, so triage each hit against other evidence.

Unusual processes and outbound traffic

A web server process spawning shells is a strong indicator. The NSA and Australian Signals Directorate web shell guidance suggests logging execution by the web server account with auditd:

# Log every program executed by the web server user (replace 33 with your web server UID)
sudo auditctl -a always,exit -F arch=b64 -F uid=33 -S execve -k apacheexecve
sudo ausearch -k apacheexecve --start today

Unexpected outbound connections or a spike in outbound email point the same way.

Why does injected content only show to some visitors?

Because attackers want their spam indexed and their redirects paid, but they do not want the owner to notice. So the injected code checks who is asking before deciding what to serve.

Common conditions include:

• Is the visitor a search engine crawler? Google's web.dev guidance describes pages that look empty to you but contain spammy words and links for Google, and its cloaked keywords guide notes a hacked page may even show you a 404 error while still serving content to search engines.
• Is the visitor logged in? Many injections skip anyone with a CMS session cookie, because that is usually the owner or an editor.
• Did the visitor arrive from a search result? Redirects that only fire when the referrer is a search engine keep direct visits looking normal.
• Is it a phone? Mobile only redirects are common, because owners mostly check their sites on desktop.
• Has this visitor been seen before? Some injections fire once per IP address or once per cookie, so refreshing the page shows nothing.

CISA's web shell guidance recommends exactly this test: change your user agent to a search engine crawler's, because some malicious code shows different content to crawlers than to regular users. You can do a basic version from a terminal. These requests only read your own pages.

# Normal desktop browser
curl -s -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://www.example.com/ -o desktop.html

# Claims to be Google's crawler
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://www.example.com/ -o googlebot.html

# Mobile browser arriving from a search result
curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X)" -e "https://www.google.com/" https://www.example.com/ -o mobile.html

# Compare sizes and differences
wc -c desktop.html googlebot.html mobile.html
diff desktop.html googlebot.html | head -50

# Follow redirects and print each hop
curl -sIL -A "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X)" -e "https://www.google.com/" https://www.example.com/ | grep -i -E "^(HTTP|location)"

Some cloaking also checks the visitor's IP address, so a clean curl result proves nothing. Google's URL Inspection tool shows the page as Google fetched it. Test the human paths with a private window, a phone on mobile data and a click from a real search result.

What do Search Console and server logs tell you?

These are the two sources that turn a suspicion into evidence. Search Console tells you what Google has observed from the outside. Your logs tell you what actually happened on the server.

Google Search Console

According to Google's Security Issues report documentation, the report groups problems into four families:

Google says the example URLs are a sample, not a complete list, so fixing only those pages is a common reason a review fails. Also check Manual Actions, Page indexing and Performance (for jumps in pages or unrelated queries), Sitemaps you did not submit, and Users and permissions for owners you did not add.

When everything is fixed, use Request Review, describe what you found and did, and do not resubmit while a request is pending. Google says reviews typically take several days to a few weeks.

Web server access logs

Access logs are where you find the entry point and the timeline. CISA's alert lists log patterns to look for: non web file types receiving unexpected requests (an image receiving POST parameters), and URIs requested rarely, by few user agents and with no referrer, because a web shell is usually visited only by whoever planted it. Logs usually live under /var/log/apache2/, /var/log/httpd/ or /var/log/nginx/, or in your hosting panel. These commands assume the combined log format.

LOG=/var/log/nginx/access.log

# POST requests to upload or content directories (rarely legitimate)
awk '$6 ~ /POST/ && $7 ~ /\/(wp-content\/uploads|sites\/default\/files|images)\//' "$LOG"

# Successful requests to PHP files inside upload folders
grep -E "/wp-content/uploads/.*\.php" "$LOG" | awk '$9 ~ /^2/'

# The 30 least requested URIs that returned 2xx, the pattern CISA describes
awk '$9 ~ /^2/ {print $7}' "$LOG" | sort | uniq -c | sort -n | head -30

# Login attempts and their sources
grep -E "wp-login\.php|xmlrpc\.php|/user/login|/administrator/" "$LOG" | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Everything a suspicious IP did, in order
grep "^203\.0\.113\.45 " "$LOG"

The NSA and ASD repository includes scripts for this rare URI analysis on Apache and IIS logs, and warns the output always contains false positives.

Once you find a malicious file, work backwards from its first request: what did that IP request in the minutes before? A POST to a plugin endpoint just before a new file appears is often the entry point. Download logs early, because shared hosts rotate them quickly, and treat a gap in the logs as a finding in itself.

How do you check file integrity?

File integrity checking compares what is on your server with what should be there. It is the most reliable hidden sign check, because it does not depend on recognising malicious code.

WordPress

WP-CLI can verify core files and plugins from the WordPress.org directory against published checksums.

# Verify core files; --include-root also warns about unexpected files in the root
wp core version
wp core verify-checksums --include-root

# Verify every plugin hosted on WordPress.org
wp plugin verify-checksums --all

# Show plugins and themes with available updates
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available --fields=name,version,update_version

The WP-CLI documentation notes that if core verification fails because of locale or version differences, you should pass --locale and --version matching what the site's Updates screen shows. --include-root was added in WP-CLI 2.8.0. Plugin verification compares against WordPress.org checksums, so premium plugins and custom themes are not covered; compare those against a fresh download from the vendor or your own repository.

Drupal

The Hacked! module re-downloads installed core, modules and themes and reports which files differ. Its project page is explicit that it is a developer tool and should never be installed on a production site, so run it against a copy. If your Drupal site is managed with Composer, the simpler route is to compare against a clean composer install of the same lock file.

Joomla and everything else

For any CMS or framework, the general method from the NSA and ASD guidance works: put a clean copy of the exact same versions side by side and diff the trees.

# Compare a clean install of the same versions with production, list changed and added files
diff -r -q /srv/known-good/site/ /var/www/html/ | grep -v -E "uploads|cache" | sort

Code managed sites

If your site is deployed from Git, integrity checking is much easier. Anything on the server that is not in the repository, or differs from the deployed commit, needs an explanation.

cd /var/www/html
git status --porcelain
git diff --stat
git ls-files --others --exclude-standard

The WordPress FAQ also points out that sites under version control can compare files directly against the official repository, which is a faster path to a list of changes.

How did the attacker usually get in?

Knowing the entry point matters more than knowing the payload, because the entry point is what you must close before the site goes back online.

Outdated plugins, themes, frameworks and libraries

This is the dominant cause. CISA's first mitigation for compromised web servers is patching applications and the host OS. The WordPress hardening guide says older versions no longer get security updates and tells owners to update plugins and delete unused ones. Google says to find and fix the vulnerability that let the attacker in.

On a typical small business site, the code you did not write vastly outnumbers the code you did: core, a theme, a page builder and many plugins, or hundreds of Composer or npm packages. Any of them can ship a public vulnerability that bots scan for within days. Abandoned plugins and themes are the worst case because a fix may never come. We cover a curated way of tracking actively exploited flaws in can CISA KEV work as a WordPress vulnerability feed.

Weak, reused or stolen passwords

Credential stuffing against admin logins, FTP and hosting panels is constant. The WordPress FAQ says every access point (SFTP, CMS admin, hosting panel, database) and every user needs a long unique password and ideally two factor authentication. It also warns the infection may have started on the owner's own computer, with malware capturing FTP or admin credentials.

Nulled and pirated themes or plugins

Paid themes and plugins downloaded for free from unofficial sites very often contain backdoors before they are ever installed. The WordPress hardening guide says never to download WordPress from anywhere other than wordpress.org, and the same rule applies to every component. See are nulled WordPress themes and plugins safe.

Hosting and neighbour compromise

On shared hosting, one compromised site can affect others on the same account, and sometimes on the same server. The WordPress FAQ recommends contacting your host early for this reason. Old copies of the site (/old, /backup, /staging) left on the same account are a frequent source, because nobody updates them.

Runtime and server software

The PHP runtime, the web server and the operating system matter too. A site with fully patched plugins can still be exposed through an unsupported PHP version or a vulnerable server module. See is PHP still safe to use in 2026 and PHP security explained.

Should you clean up or restore from backup?

Restoring from a known clean backup is usually faster and more reliable than cleaning, provided you can identify a clean point and you close the entry point before going live. Cleaning in place is the right choice when no clean backup exists, when the site changes constantly (a busy shop with daily orders), or when you need to preserve evidence first.

How to pick a clean restore point

1. Find the earliest evidence: the first log request to a malicious file, an unknown admin's registration date, the earliest odd URL in Search Console.
2. Go back further. Attackers often get in days or weeks before they act, so a backup from the day before the first spam page may already hold the backdoor.
3. Verify the backup on staging with the same checks: checksums, PHP files in upload folders, admin users, cron jobs. Only then promote it.
4. Reinstall code from official sources at the same versions. The WordPress FAQ notes that dashboard reinstall options only overwrite existing files and leave new ones, so replace whole directories such as wp-admin and wp-includes.
5. Patch before production. An old backup without updates reopens the same hole.
6. Keep the infected copy. The WordPress FAQ and Google's cleanup guide both say to take a full offline copy before changing anything.

The NCSC's small business response and recovery guide frames this as part of an incident plan you prepare in advance. UK organisations facing a live attack can call 0300 123 2040, and significant incidents can be reported at report.ncsc.gov.uk. In the US, CISA and the FBI's IC3 take reports. If the site handled personal or card data, check your notification duties.

Step by step: a first day check for a site you think is hacked

This sequence works for most PHP based CMS sites on Linux hosting. Adapt paths to your setup. It reads and records; it does not change anything until the final steps.

1. Write down what you saw and when, with time zone and recent changes. The WordPress FAQ calls this the baseline of your incident report.
2. Take a full offline copy of files, database and logs.

tar -czf ~/site-files-$(date +%F).tar.gz -C /var/www html
mysqldump --single-transaction -u dbuser -p dbname > ~/site-db-$(date +%F).sql
cp /var/log/nginx/access.log* ~/

3. Check Search Console and test what different visitors see, as described above.
4. Verify integrity, hunt for web shells, review users and scheduled tasks with the commands in the sections above.
5. Read the access logs and build a timeline.
6. Inventory component versions and compare them against published advisories.

php -v
wp core version
wp plugin list --fields=name,status,version,update_version
# For Composer managed sites (Drupal, Laravel, Bedrock style WordPress)
composer show --direct
composer audit
# For Node based sites or build tooling
npm ls --depth=0
npm audit --omit=dev

7. Lock things down: take the site offline if it serves malware or phishing, reset every password (CMS, SFTP, hosting panel, database) and enable two factor authentication. On WordPress, the FAQ recommends new secret keys in wp-config.php from the official generator, which signs everyone out.
8. Restore or clean, update everything on staging, then go live.
9. Request a review in Search Console, then change all passwords again.

After cleanup: what to update and how to keep components current

What to update immediately

• CMS core to the current supported release.
• Every plugin, module, extension and theme, including inactive ones. Delete anything you do not use; inactive code can still be reachable.
• Abandoned components: anything with no release in a long time or removed from the official directory should be replaced.
• Composer and npm dependencies for code managed sites, including transitive packages.
• The runtime: PHP to a version still receiving security support, and the web server and OS packages your host lets you control.
• Credentials and secrets: database password, API keys stored in config files, payment gateway keys, SMTP passwords. Assume anything readable by the web server was read.

How to keep components current

• Use a staging first update workflow so updates are routine. See a staging first update workflow for WordPress sites.
• Turn on automatic updates where risk is low. WordPress has offered automatic background updates since 3.7.
• Track advisories for what you run: an inventory of every component and version, plus a feed you read. CISA's Known Exploited Vulnerabilities catalogue lists flaws seen in real attacks.
• Deploy from version control, so the server can always be compared with the repository.
• Harden the CMS. define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php disables the dashboard file editor; the hardening guide says it "might stop some attacks" but not uploads. Use SFTP, 755 for directories and 644 for files.
• Monitor file changes and keep logs longer than your host's default.
• Keep versioned, protected backups. The hardening guide suggests snapshots over time, protected by encryption, independent hashes or read only storage.
• Least privilege for the web server. CISA recommends limiting where it can create or execute files. An upload folder that cannot execute scripts removes the most common web shell path.

When should you call a professional, and what should you ask?

Do it yourself only when the site is small, you have a clean backup, you can identify the entry point, and nothing sensitive was involved. Call a professional when any of these are true:

• The site takes payments, stores customer accounts or processes health or financial data.
• You found evidence of database access, data exfiltration or a payment page skimmer.
• The site was reinfected after a cleanup.
• You cannot find the entry point.
• The same hosting account or server runs other sites or business systems.
• You may need evidence for insurance, a regulator, a payment card investigation or law enforcement.

Agencies managing many client sites should read our first hour checklist for a compromised client website.

What to ask a cleanup or incident response provider

• Will you identify and report the entry point, not just remove malware?
• Will you preserve a forensic copy before you change anything, and who keeps it?
• How will you verify the cleanup, including the database, cron jobs and a crawler view of the site?
• Will you handle the Search Console review request and any blocklist delisting?
• What is your reinfection policy, and for how long?
• Will we get a written report suitable for our insurer or a regulator?

Where Safeguard fits, and where it does not

Safeguard is a software supply chain security platform. It is not a website malware scanner: it does not crawl your live site, clean infected sites or read your web server logs. If your site is compromised now, follow the steps above. Safeguard's fit is earlier and indirect, on the component exposure behind most of these compromises.

• Inventory of what your site is built from. For code managed sites, safeguard scan --dir . scans the repository and produces an SBOM and dependency inventory across Composer, npm and other ecosystems, with results written as JSON under ./output. If you ship the site as a container, safeguard scan --image <name> scans the image, including its OS packages.
• Known vulnerability matching. Components are matched against vulnerability databases including NVD, GitHub advisories, OSV and CISA KEV, with reachability analysis to rank what your code actually calls.
• Which sites carry a given version. For an agency with dozens of client sites in Safeguard, the platform shows which projects contain a given component and version, so the next advisory becomes a list, not a guess.
• Upgrade pull requests. Autonomous remediation can open tested upgrade pull requests for code managed sites, and it ships switched off by default.
• Free version checks. Gold Open Source lets anyone look up a package version's known CVEs and fixed versions without logging in.

The honest limit: a WordPress site whose plugins were installed by clicking Install in the dashboard has no manifest in a repository, so Safeguard only sees those components if you manage them as code, for example with Composer. Premium plugins outside public package registries may not appear in vulnerability databases at all.

Common mistakes

• Checking only the homepage while logged in. Cloaked content skips administrators by design.
• Deleting the obvious file and stopping. Attackers leave several backdoors and often a cron job to reinstall them.
• Using the dashboard reinstall button as a cleanup. It leaves new files in place.
• Restoring the latest backup without updating. It may hold the backdoor, and the vulnerable plugin goes straight back online.
• Changing passwords only once, or only the CMS password.
• Forgetting the database, where injected scripts and rogue admins often live.
• Letting logs rotate away before you download them.
• Requesting a Search Console review before every page is fixed.
• Keeping old staging or backup copies on the server, unpatched and sharing credentials.

FAQ

How can I check if my website is hacked for free?

Register the site in Google Search Console and read the Security Issues report, search site:yourdomain.com for pages you did not create, view the site from a phone on mobile data, and run free command line checks on the server: wp core verify-checksums, a find for PHP files in upload folders and a review of admin users and cron jobs.

Why does my website redirect to spam only on mobile?

Because the injected code checks the visitor's user agent and referrer and only redirects phones, often only those arriving from a search result, and often only once per visitor. Test with a phone on mobile data and with curl using a mobile user agent and a search engine referrer.

Can a website be hacked without any visible changes?

Yes. Web shells, hidden admins, payment skimmers and crawler only spam can run for weeks unseen, which is why server side checks matter more than looking at the site.

What does a hacked site warning in Google search results mean?

Google believes a third party may have changed content on the site, for example by adding spam pages or links. Check the Security Issues report, fix every affected page, then request a review, which Google says typically takes several days to a few weeks.

What is a web shell?

A script an attacker uploads to a web server to control it through a web page. CISA describes it as a way to gain remote administration of the machine. On PHP sites it is usually a PHP file in an upload or cache folder, or code appended to a legitimate file.

How do I find out how my website was hacked?

Find the first request to a malicious file in your access logs, then see what the same IPs requested just before. Compare with component advisories and admin login history. If you cannot find it, call a professional.

Should I restore my website from a backup after a hack?

Usually yes, if you have a backup from before the compromise that you have checked on staging. Update every component before going live, keep a copy of the infected site, and change all credentials.

Do I have to report a hacked website?

It depends on what was exposed and where you operate. If personal data or card data may have been accessed, data protection or payment card rules may require notification. The NCSC and CISA both accept incident reports, and your host should be told so it can check neighbouring sites.

Fix it without waiting for upstream

Most website compromises in the official guidance trace back to a component that already had a published fix, or to one whose maintainer had stopped shipping fixes. The block below is about closing both gaps for the open source code your site is built from.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos cleans a hacked website. They show the prevention side covered above: finding outdated components in the code behind a site and upgrading them with a human approving each step.

This first demo is a real CLI session. Asked to fix a lodash CVE, the CLI reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow applies to the JavaScript build tooling and front end packages behind many modern sites.

Click through it at your own pace, or open it full screen.

The second demo sets up the runner on your own machine, approves it with its device code, then scans from the terminal. For an agency, that is a way to scan client site repositories locally without sending the code anywhere else first.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, you can ask which of your projects carry a component named in a new advisory, while keeping the assistant limited to the tools you approve.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• Google Search Console Help: Security Issues report
• Google web.dev: How do I know if my site was hacked?
• Google web.dev: Fix the cloaked keywords and links hack
• Google Search Central: Spam policies for Google web search
• CISA: Compromised Web Servers and Web Shells, Threat Awareness and Guidance
• NSA and ASD: Mitigating Web Shells guidance repository
• NCSC: Small Business Guide, Response and Recovery
• WordPress.org Documentation: FAQ My site was hacked
• WordPress Developer Resources: Hardening WordPress
• WP-CLI: wp core verify-checksums
• WP-CLI: checksum-command (wp plugin verify-checksums)
• Drupal.org: Hacked! module

Last reviewed: 23 October 2026. CMS tools and search engine processes change; check the linked official guidance for current steps.