Balada Injector: Identifying and Removing It

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

Your visitors get bounced to a fake prize page or a browser-notification scam. You look at the site while logged in and everything is normal. A scanner flags some obfuscated JavaScript, you delete it, and two days later it is back. That pattern — mass redirects, rotating domains, and a cleanup that never quite sticks — is the signature of Balada Injector, and it has been running against WordPress sites for years.

What Balada actually is

Balada is not a single piece of malware so much as an industrial campaign. The operators watch for newly disclosed vulnerabilities in popular WordPress plugins and themes, then scan the entire web for unpatched installs within days — sometimes hours — of the disclosure. Anything they can reach gets injected, and the site is added to a pool that gets monetized by redirecting visitors to scam pages, fake support numbers, and push-notification traps.

Because it works at that scale, nothing about your site was targeted. You were not singled out, your business is not interesting to them, and there was no personal grudge. You ran a plugin version with a known hole in it and an automated scanner found you. That is genuinely the whole story, and understanding it matters because it tells you where to look for the way in.

What you actually see

The complaints almost always arrive from other people. A customer says your site sent them to a sweepstakes page. Someone on a phone gets a fake virus warning. Meanwhile you open the site on your own laptop, logged into wp-admin, and it behaves perfectly — because the injected script deliberately skips anyone carrying a WordPress login cookie, and often skips repeat visitors too, so you cannot reproduce the thing you are being told about.

In the page source you will find a block of obfuscated JavaScript, usually in the header or footer output, built out of long arrays of encoded strings and reassembled at runtime. The destination domain rarely appears as readable text. Look also at your Users screen: Balada is well known for adding an administrator account, frequently with a plausible-looking name, so that the operators keep access even after you patch the hole they came through.

Everywhere it puts itself

The mistake that keeps people in a reinfection loop is treating this as a JavaScript problem. The injected script is the visible end of a much longer tail. Expect to find copies of the payload in your theme files, in wp_options rows, and sometimes written into the database as part of post content. Expect one or more PHP backdoors dropped in places that look harmless — the uploads folder, a fake plugin directory with a believable name, or a file that mimics a core filename closely enough to skim past.

Expect modified .htaccess files, not just the one in your web root. Expect the administrator account mentioned above, and sometimes a second one that does not display on the Users screen at all. And expect at least one persistence mechanism whose entire job is to put everything else back: a scheduled task, a must-use plugin, or code appended to a file that loads on every request. My guides on WordPress backdoors, hidden admin users and malicious cron tasks cover each of those in detail.

Cleaning it properly

Work in an order that does not let the infection rebuild behind you. Take a full copy of the site first, files and database, purely as evidence — you may need it to work out how they got in, and you cannot recover a detail you deleted. Then replace WordPress core, every plugin and your theme with clean copies from source rather than trying to surgically edit infected files. Anything you did not put there and cannot account for goes, particularly PHP anywhere inside wp-content/uploads.

Then do the database pass, because this is the step most DIY cleanups skip and it is the reason the redirect returns. Search the database for the injected script fragments and the attacker domains, check wp_options for junk rows, and confirm siteurl and home still point where they should. Finish by deleting unrecognized admin accounts, forcing a password reset on every remaining user, and rotating your database password and salts.

Closing the door you came in through

A clean site with the original hole still open gets reinfected within days, because the same scanners that found you the first time are still running. Update everything to current versions — core, all plugins, theme — and treat any plugin that has been abandoned by its developer as a liability to replace rather than a component to keep.

Your access logs are the fastest route to the actual entry point. Look for POST requests to plugin endpoints around the time the first strange file appeared, and match file modification timestamps against log entries. My guide on how sites get hacked walks through that process, and hardening covers what to change so the next disclosure does not catch you the same way.

After the cleanup

Balada sites usually pick up collateral damage on the way out. If Google flagged you, work through the Search Console security issues report and request a review once the site is genuinely clean. If a browser or antivirus vendor is still blocking you, the blacklist removal links page has the delisting forms for each one.

Then verify rather than hope. Fetch your own pages the way a search engine sees them, check a few from a phone on mobile data with no login cookie, and watch the site for a week. If the redirect comes back, something survived — and finding the last piece of a persistence chain is exactly the work my malware removal service exists to do.

Common questions

Why does the redirect only happen to some visitors?

Because the injected script checks who you are before it fires. Logged-in WordPress users are skipped almost universally, and many variants also skip repeat visitors by setting a cookie, or only trigger for traffic arriving from search results or on mobile. That selectivity is deliberate — it keeps the site owner from noticing while the campaign keeps monetizing real visitors.

I deleted the JavaScript and it came back. What did I miss?

Almost certainly a PHP backdoor or a database-level persistence mechanism that rewrites the script. The JavaScript is output, not cause. Until you remove the code that generates it — a backdoor file, an infected theme function, a scheduled task, or a malicious row in wp_options — deleting the visible injection just resets a timer.

Does Balada steal customer data?

Its primary business is redirecting traffic for profit rather than harvesting data, but that is a statement about intent, not about capability. A compromise that installs backdoors and creates administrator accounts means someone had full read access to your database for as long as they were in. If you hold customer records or take payments, treat it as a potential data incident and read my guide on telling customers after a hack.

Will updating my plugins remove the infection?

No. Updating closes the door for next time; it does nothing about anyone already inside. The injected files, database rows, admin accounts and backdoors all survive an update untouched. You need both steps, in the right order: clean the site completely, then patch, then rotate credentials.

How long until Google stops showing the warning?

Usually a few days after a successful review request, sometimes faster. The clock only starts when the site is actually clean, though — a review request submitted while a backdoor is still live comes back as a failed review and costs you more time than waiting a day to be thorough would have.