Imunify Connect Adds WordPress Database Scanning: One Integration, Both Halves of a WordPress Hack

An attacker gets in through a vulnerable plugin. They drop a backdoor file in wp-content/uploads. In the same session, they write a redirect script into wp_options and a spam link into wp_posts.post_content. A file scanner finds the backdoor. The database UPDATEs stay. The site gets cleaned and still serves pharma spam to search engines the next morning.

This is the shape of many WordPress breaches. It lives in two places at once, and a scanner that only looks at files will miss half the hack.

The Other Half of the Hack

Database-resident malware shows up in the same few tables in almost every compromised WordPress install:

• wp_posts.post_content collects injected <script> tags, hidden spam links, and iframe injections buried in years-old blog posts.
• wp_options.option_value holds base64-encoded redirect payloads tucked into widget and theme settings, and obfuscated PHP stored inside serialized options.
• wp_postmeta.meta_value hides encoded URLs and obfuscated JavaScript in post metadata, where many scanners never look.
• wp_comments gets spam payloads pasted into comment bodies and author email fields.

None of these touch disk. A file scanner, no matter how deep it goes, will not find them. The threat categories are the familiar ones: injected <script> and <iframe> tags, PHP backdoors stored as post or option data, base64-encoded redirects, and obfuscated JavaScript hooks that execute on page load. This whole class of threat has been a blind spot for file-only scanners, which is why sites that get cleaned by a file scan often keep turning up on blocklists a week later.

What Is New in Imunify Connect

Imunify Connect already lets WordPress security plugin vendors add file scanning to their plugin through a single API and PHP library. This release adds database scanning to the same integration. Same API, same PHP library, same partner portal, now covering both halves of a WordPress compromise.

How It Works

Database scanning in Imunify Connect uses the same split-scan architecture as the file scanner. The partner plugin does the work on the local WordPress server, the backend does the signature matching.

End to end, a scan looks like this:

1. Start the scan. The partner plugin calls scanDatabase($pdo, $database, $tablePrefix) on the Imunify Connect PHP library. The library sends only table metadata (names and prefix) to the backend. Database credentials stay on the partner server.
2. Get scan instructions. The backend returns a scan configuration: which tables and columns to look at, which content patterns mark a row as worth a closer look, and a per-cell size limit.
3. Prescan locally. The PHP library runs those pattern checks against the local WordPress database. Most rows, ordinary blog posts and ordinary settings, are filtered out before any content leaves the server.
4. Upload only suspicious rows. Rows that match a prescan pattern are uploaded to the backend in batches. Full database contents never leave the WordPress server.
5. Signature matching, server-side. The backend runs the Imunify malware database scanner engine on each batch as it arrives. It is the same engine used inside Imunify360, which protects over 60 million domains worldwide. Confirmed threats come back as a results list: table, column, row ID, signature ID, severity, and a safe content snippet.

Database credentials never leave the WordPress server.

Cleanup uses the same pattern. The backend returns a cleaned version of each infected row, the PHP library stores the original locally, and Restore reads from that local backup.

The library ships with a default SQLite-backed local store with 30-day retention. Partners with their own storage needs (e.g. a dedicated table in the site's DB, or object storage) can implement BackupStoreInterface and pass it in. It has the same shape as the file-scan FileBackupStoreInterface.

What Is in the Release

Here is what we shipped:

• New API endpoints for the full database scan flow: start, content upload, status polling, results, cleanup, cleanup confirm, and restore confirm.
• New PHP library methods covering the full scan, clean, and restore lifecycle.
• New webhook events: db_scan.started, db_scan.completed, db_scan.failed.
• Updated sample WordPress plugin in the repository: a Database Scan card, a tabbed results page, per-threat Clean and Restore buttons, and a wp imunify db-scan WP-CLI command.
• Updated partner portal: database scan history and a DB threats stat card.

Database scanning is included in existing Imunify Connect pricing at no extra cost.

How to Start Using It

There are two paths, depending on where you are today.

If you already integrated Imunify Connect for file scanning. Update the PHP library to the current version. Call the new scanDatabase() method whenever you want to trigger a scan. It runs the full prescan → upload → wait → return-results flow in one call. The partner portal starts showing database scan activity alongside file scans automatically. The rest of the integration shape does not change: same API base URL, same site-key authentication, same webhook delivery.

If you are evaluating Imunify Connect for the first time. Register a new partner account at connect.imunify.com. Pull in the Imunify Connect PHP library, wire your site-key into the configuration, and use the sample WordPress plugin in the repository as a reference for UI patterns. File scanning and database scanning come through the same API. You ship both the day you ship the integration.

Full documentation for the new endpoints and PHP library methods is on the Imunify Connect website. If you want to talk to us about fit before integrating, contact our team at sales@cloudlinux.com.

One Integration, One API, One Bill

A WordPress hack does not stop at the filesystem. Your scanner should not either. With this release, Imunify Connect gives your plugin the file scanner and the database scanner through one integration, one API, and one bill.

Get started with Imunify Connect today → connect.imunify.com