A script injected into your posts runs in every visitor’s browser — and no file scan sees it.

String.fromCharCode turns numbers into characters: 104, 116, 116, 112 spell h, t, t, p. An injected script written this way never contains its destination as readable text, so a search for a domain name or for http finds nothing, and a quick look at a post in the editor shows what looks like noise. atob() does the same job with base64, and document.write or a created <script> element then loads the real payload from elsewhere.

The injection is usually stored where WordPress will print it into every page or every post: appended to the end of post_content, inside a Custom HTML or Text widget, in a page builder’s saved layout, or — in the bluntest version — by changing the siteurl and home options so the whole site loads from an attacker’s domain. Nothing in the files changes, so file-integrity checks, core reinstalls and plugin replacements all report a clean site.

Getting script into the database requires a write path: an exploited plugin, a stolen administrator login, cross-site scripting stored through a form or comment, or code already running on the server. The injection is the visible symptom of that access.

Figure 1 · Where injected scripts live

Four places a database script injection hides, and the safe way to fix each.

Location	What the injection looks like	Safe fix
wp_posts · post_content	<script> or fromCharCode() appended to posts	search-replace --dry-run, then apply
widget_text, widget_custom_html	A script inside a serialised widget	WP-CLI or the editor — never raw SQL
siteurl and home options	Changed to an unfamiliar domain	Restore the value, then find the writer
wp_postmeta, theme_mods_*	Scripts in builder or theme data	Search, then fix through WordPress

1. 01

   Search post content

   Posts, pages and other post types whose content carries the usual markers:

   SQL · read-only

   SELECT ID, post_type, post_status, post_modified
   FROM wp_posts
   WHERE post_content LIKE '%fromCharCode%'
      OR post_content LIKE '%document.write(%'
      OR post_content LIKE '%atob(%'
      OR post_content LIKE '%<script%src=%'
   ORDER BY post_modified DESC;

   Injections are often appended to many posts in one pass. A cluster of matches with modification times minutes apart, on posts nobody edited, is the pattern.

2. 02

   Search widgets and site-wide options

   Widgets are stored as options, so a script added to a sidebar lives here:

   SQL · read-only

   SELECT option_name, LENGTH(option_value) AS bytes
   FROM wp_options
   WHERE (option_name LIKE 'widget\_%' OR option_name LIKE 'theme\_mods\_%')
     AND (option_value LIKE '%<script%'
       OR option_value LIKE '%fromCharCode%'
       OR option_value LIKE '%atob(%');

   The backslash keeps the underscore literal: in a LIKE pattern an unescaped _ matches any single character.

3. 03

   Check the site address options

   If the whole site redirects or loads from somewhere else, look here first:

   SQL · read-only

   SELECT option_name, option_value
   FROM wp_options
   WHERE option_name IN ('siteurl', 'home');

   Both should be your own address. A different domain here means something wrote directly to the database — treat it as a full compromise, not a misconfiguration.

4. 04

   Search every table at once with WP-CLI

   WP-CLI’s database search covers postmeta, builder data and plugin tables in one pass, and only reads:

   WP-CLI

   $ wp db search fromCharCode --all-tables-with-prefix
   $ wp db search '<script' --all-tables-with-prefix

   Repeat with document.write and atob(. Note each table and column with a match; that list is your cleanup scope.

1. 01

   Preserve the evidence

   Export the database outside the web root before changing anything:

   shell

   $ mkdir -p ~/incident
   $ wp db export ~/incident/before-cleanup.sql

   Record which posts, widgets and options carried the injection and their modification times. They bound the window to search the logs for.

2. 02

   Restore the site address first, if it changed

   A hijacked siteurl or home locks you out of the dashboard. Defining WP_HOME and WP_SITEURL in wp-config.php overrides the stored values until the options are corrected — remove the defines afterwards if you do not normally use them.

3. 03

   Remove the injection from content

   Run the dry run until the counts match what you found, then repeat the same command without --dry-run. Fix widgets the same way or by editing them in Appearance → Widgets; never with a raw SQL REPLACE.

4. 04

   Find what wrote it

   An injection in many posts at once points to code or database access, not someone typing. Look for the file-based loader and the account: rogue administrators, recently changed plugin files, PHP in uploads, and anything in mu-plugins.

5. 05

   Rotate and re-check

   Administrator passwords, application passwords, the database password and the WordPress salts. Then re-run the searches the next day: content that is re-injected means the writer is still there.

A script injection is often one layer among several. The same access that wrote to post content can store an encoded PHP payload in the options table, alter role definitions, or schedule a WP-Cron event that re-injects the content after you clean it. Google may also have noticed before you did.