Why is malware in my database rather than in files?

Because the database renders into every page. Injected script tags in post content or a header/footer option execute on each visit without a single file changing, which sidesteps file-based scanning entirely. It commonly arrives through a vulnerable plugin that writes options or through a compromised admin session.

Can I clean it by just editing the flagged row?

You can remove the flagged content, and should — but treat that as symptom relief. Whatever wrote to the database still has access unless you find it: check for unfamiliar admin accounts, look at which plugins can write the affected option, and change admin passwords. Re-scan after cleaning; re-injection within days confirms the access path is still open.

Do my visitors need to worry?

While the injection is live, yes — database injections typically redirect visitors, load malicious ads, or serve fake update prompts. Clean it promptly and check Google Search Console for security flags, because search engines noticing before you do costs traffic that takes weeks to recover.

Glossary · Malware

Malicious content was found in the database

Wordfence type: database
Category: Malware
Severity: Critical

Wordfence matched malicious content inside database rows rather than in files.

Written by G. Schad, Cybersecurity Specialist Published 2026-07-31 · Updated 2026-08-22

The alert usually reads

Suspected malware code was found in the database in the option wp_head_scripts.

What Wordfence found

The scanner checked post content, options and other tables against its signatures and found a match. Typical cases are injected script tags across published posts, malicious redirects stored in options, or spam links inserted into content at scale.

Why it matters

Database injections survive a complete reinstall of WordPress core, plugins and themes, which is why sites are so often reinfected after a clean-looking file restore. They also serve malware directly to visitors, so the site can be blocklisted while the files look perfectly clean.

How to fix it

1Identify the affected rows before changing anything — the finding names the table.
2Restore the database from a backup predating the injection if you have one.
3Otherwise clean the rows, but do it with a targeted query rather than a blind search-and-replace across the whole database.
4Check wp_options for injected values as well as wp_posts — redirects usually live there.
5Re-scan, and check the site in a browser as a logged-out visitor, since many injections only fire for anonymous traffic.

Common questions

Why is malware in my database rather than in files?: Because the database renders into every page. Injected script tags in post content or a header/footer option execute on each visit without a single file changing, which sidesteps file-based scanning entirely. It commonly arrives through a vulnerable plugin that writes options or through a compromised admin session.
Can I clean it by just editing the flagged row?: You can remove the flagged content, and should — but treat that as symptom relief. Whatever wrote to the database still has access unless you find it: check for unfamiliar admin accounts, look at which plugins can write the affected option, and change admin passwords. Re-scan after cleaning; re-injection within days confirms the access path is still open.
Do my visitors need to worry?: While the injection is live, yes — database injections typically redirect visitors, load malicious ads, or serve fake update prompts. Clean it promptly and check Google Search Console for security flags, because search engines noticing before you do costs traffic that takes weeks to recover.

Findings that often appear with this one

A malicious URL was found in a site option Malware
The site is flagged by Google Safe Browsing Malware

How WPSecureOps treats it

The connector reports this as database. WPSecureOps files it under Malware and bands it by the numeric severity Wordfence assigns, so findings of this kind from every site you manage arrive in one queue rather than one email per site. Titles and descriptions are stripped of HTML and the site's absolute path is replaced before anything leaves the server.

Primary references

Product behaviour and remediation guidance were checked against these primary sources.