WordPress Cyberattacks: 18 Real Threats and How to Stop Them

WordPress powers more than 43 percent of all websites on the internet, including a huge share of business websites in the UAE. That popularity is also the reason attackers love it. A single zero-day in a popular plugin can be weaponised against millions of sites overnight, and automated exploit kits are built specifically to target WordPress at scale. This guide covers 18 WordPress-specific attack techniques, the real damage each one causes to UAE businesses, and practical steps with code that you can apply today to stop them.

This article focuses on WordPress-specific mechanics: plugins, themes, functions.php, wp-cron, the wp_options database table, REST API, and XML-RPC. For general website security fundamentals like SSL, passwords, 2FA, and backups that apply to any platform, see our companion guide on website security best practices.

Why WordPress Is the Number One Target for Attackers

Understanding why WordPress gets attacked so often helps you understand why hardening it requires more than just a generic security plugin.

• Economies of scale for attackers. One working exploit against a popular plugin can be run against millions of sites by an automated bot in hours. The return on investment for hackers is enormous.
• Huge plugin and theme ecosystem. There are over 60,000 plugins and 10,000 themes available, many written by hobbyist developers without security review. Every plugin you install is a potential door.
• Administrators are often non-technical. Most WordPress sites are run by business owners, marketers, or content teams, not developers. This means patches and configuration hardening often lag behind.
• Predictable file and URL structure. Attackers always know where /wp-admin, /wp-login.php, /wp-content/uploads, and /wp-config.php are located on any WordPress site.
• UAE context. Many UAE small businesses, from Jumeirah boutique shops to Abu Dhabi consultancies, run WordPress for their websites without a dedicated IT team. That combination of high-value business data and light security makes them prime targets for both opportunistic bots and targeted attacks from competitors.

18 WordPress-Specific Attacks and How to Stop Each One

Each attack below includes what it does, what happens if you ignore it with a realistic example, and the exact fix with code where applicable. Work through the list top to bottom, the earlier items block the most common attack vectors.

A “nulled” plugin or theme is a paid product that someone cracked, removed the licence check from, and re-uploaded for free download on shady websites. The catch: almost every nulled copy also contains hidden malicious code. You save AED 200 on a premium theme and give an attacker full access to your server.

What happens if you don’t fix it: A Sharjah wedding planner installed a nulled premium booking theme downloaded from a forum. Within 72 hours, her site was sending phishing emails pretending to be DEWA bill reminders to random UAE email addresses. The emails caused her domain to be blacklisted by Google, Microsoft, and every major UAE ISP. Her legitimate emails to clients stopped arriving. Cleaning the reputation took two months.

How to fix it:

• Never download themes or plugins from sites offering paid products for free. There are no exceptions.
• Buy from the WordPress.org directory, the original developer’s website, or reputable marketplaces (ThemeForest, CodeCanyon, Elegant Themes).
• Scan your current installation for signatures of known nulled code. The plugin “String locator” can search for suspicious PHP patterns like eval(base64_decode( across all files.
• If you inherited a site and are not sure if the themes and plugins are legitimate, reinstall them fresh from official sources.

Even legitimate, paid, well-reviewed plugins can turn malicious. This happens when the original developer sells the plugin to a new owner who adds backdoor code, or when an attacker compromises the developer’s account and pushes a malicious update. You trust the plugin, so you install the update without thinking, and suddenly your site is compromised.

What happens if you don’t fix it: This has happened to several popular WordPress plugins over the years: Display Widgets, WP-GDPR-Compliance, Social Warfare, and others. Users installed routine updates and woke up to sites that were redirecting visitors to scam sites, stealing admin credentials, or hosting hidden spam pages. A Dubai fitness studio lost its local Google ranking entirely after its contact form plugin was compromised and started showing spam pages to Googlebot.

How to fix it:

• Before updating, check the plugin’s recent reviews. A sudden flood of one-star reviews often means something has gone wrong.
• Subscribe to WordPress security news sites (Wordfence blog, Patchstack, Sucuri blog) and UK/EU vulnerability feeds. They usually announce compromised plugins within 24 hours.
• Use a security plugin that maintains its own threat database. Wordfence and Solid Security flag known-compromised plugin versions automatically.
• Always have a backup from the day before any update. If an update turns out to be malicious, you can roll back.
• Consider staging updates: test new versions on a staging site for 48 hours before pushing to production.

WordPress allows file uploads through the media library and through contact forms, job application forms, profile picture uploads, and many plugins. If any of these accept files without checking the actual file type, an attacker can upload a PHP file disguised as an image. The moment they visit that uploaded file, the PHP executes and the attacker has a shell on your server.

What happens if you don’t fix it: A Ras Al Khaimah recruitment agency had a “Submit your CV” form that accepted PDFs. A vulnerability in the form plugin allowed uploading .php files renamed with a .pdf extension. The attacker uploaded a web shell, gained access to the server, and sat silently for three weeks collecting every CV that came through (passport copies, salary histories, references) before selling the data. The agency discovered the breach when candidates started complaining about identity theft.

How to fix it:

• Only allow specific, safe file types on upload forms. Validate both the MIME type and the file extension on the server side.
• Never trust the filename. Rename uploaded files to a random string and strip extensions like .php, .phtml, .php3, .phar.
• Block PHP execution inside the uploads folder with this rule in .htaccess placed in /wp-content/uploads/:

# /wp-content/uploads/.htaccess
# Prevent any PHP or script execution in the uploads folder
<FilesMatch "\.(php|phtml|php3|php4|php5|php7|phar|pl|py|jsp|asp|sh|cgi)$">
  Require all denied
</FilesMatch>

# Block access to any file starting with a dot
<FilesMatch "^\.">
  Require all denied
</FilesMatch>

• Use a form plugin that explicitly supports server-side MIME type validation (Gravity Forms, WPForms Pro, Fluent Forms).
• Set a reasonable maximum upload size to limit damage.

By default, WordPress leaks usernames through several URLs. Visiting yoursite.com/?author=1 redirects to a URL containing the username of user ID 1 (usually the main admin). The REST API endpoint /wp-json/wp/v2/users returns a full list of all usernames on the site. Once attackers have real usernames, brute force attacks become much more effective because they only need to guess passwords, not username and password combinations.

What happens if you don’t fix it: A Dubai real estate agency had three admin accounts, all with the username matching their first name (standard for small teams). An attacker discovered all three usernames in under a minute via the REST API. Focused password attacks then cracked one account within a day. The agency’s entire property listing database was dumped and sold to competitors.

How to fix it: Add the following to your theme’s functions.php (child theme preferred) or to a custom plugin:

// Block user enumeration via ?author=
add_action('init', function() {
    if (!is_admin() && isset($_GET['author'])) {
        wp_redirect(home_url(), 301);
        exit;
    }
});

// Restrict REST API /users endpoint to logged-in users
add_filter('rest_endpoints', function($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }
    return $endpoints;
});

Also, make sure every user account has a different username from their display name. In WordPress, go to Users → Profile and set “Display name publicly as” to something other than the login username.

WordPress has a legacy feature called pingbacks, which uses the xmlrpc.php file to notify other sites when you link to them. Attackers abuse this to turn your WordPress site into a weapon: they send a single request to your xmlrpc.php and trick it into making hundreds of outbound HTTP requests to a victim’s website. Thousands of compromised WordPress sites doing this at once create a massive DDoS attack. Your site becomes an accomplice, and your hosting provider may suspend you for participating.

What happens if you don’t fix it: A Dubai marketing agency received a suspension notice from their hosting provider. Their WordPress site had been participating in a DDoS attack against a foreign news website for three hours. The hosting provider shut down the site and threatened to terminate the account if it happened again. The agency was offline during a product launch campaign worth AED 40,000.

How to fix it: Disable pingbacks and XML-RPC unless you specifically need them (for Jetpack or mobile WordPress apps).

// In functions.php: disable XML-RPC completely
add_filter('xmlrpc_enabled', '__return_false');

// Disable pingback method specifically (if you still need other XML-RPC features)
add_filter('xmlrpc_methods', function($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    return $methods;
});

// Remove pingback HTTP header
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

You can also block xmlrpc.php entirely at the web server level if you don’t need it at all:

# .htaccess in WordPress root
<Files xmlrpc.php>
  Require all denied
</Files>

These are famous WordPress-specific malware patterns. The “Japanese keyword hack” injects Japanese-language spam pages into your site that rank on Google for Japanese search queries, then redirect visitors to counterfeit product stores. The “pharma hack” does the same for medication spam. Both use sophisticated cloaking: real visitors see your normal site, but Googlebot sees the spam content.

What happens if you don’t fix it: An Abu Dhabi law firm noticed their Google Search Console suddenly showed thousands of indexed pages in Japanese. Their site was unchanged when they visited it (the malware served normal content to regular browsers), but Googlebot and anyone clicking through from Japanese search results saw pages selling fake luxury goods. Google flagged the site as hacked and removed it from search results entirely. Business inquiries from their website dropped to zero for six weeks.

How to fix it:

• Scan regularly with a malware scanner that checks files AND the database (most hacks hide in wp_options, wp_posts, and theme files).
• If you’re already infected, manual cleanup usually fails because the malware re-infects itself from hidden triggers. Use a professional cleanup service.
• Check Google Search Console regularly for “Security Issues” and “Coverage” reports to catch infections early.
• Compare your actual indexed pages in Google (site:yoursite.com) to the ones you expect to see. Any pages you didn’t create are a red flag.
• SiteLock Fix and Defend plans include automatic malware removal that handles these common WordPress malware families.

Smart attackers don’t just inject malware into files, they inject it into your database too. The wp_options table stores site-wide settings and is loaded on every page request. Malicious code injected here survives file cleanups, theme changes, and even WordPress reinstalls, because it’s stored in the database, not on disk.

What happens if you don’t fix it: An Ajman e-commerce store hired a freelancer to “clean” their hacked site. The freelancer reinstalled WordPress fresh, replaced all themes and plugins, and declared the job done. Within 48 hours, the malware returned. The issue was a malicious option injected into wp_options with an autoload flag set to “yes”, causing it to execute on every page load. The fresh files had no malware, but the database did.

How to fix it:

• When cleaning up a hacked site, always scan the database, not just the files.
• Look for suspicious option names in wp_options with this SQL query:

-- Find suspicious autoloaded options
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

-- Look for options containing base64 or eval patterns
SELECT option_name, option_value
FROM wp_options
WHERE option_value LIKE '%base64_decode%'
   OR option_value LIKE '%eval(%'
   OR option_value LIKE '%gzinflate%';

-- Check for suspiciously named options
SELECT option_name FROM wp_options
WHERE option_name REGEXP '^[a-z0-9]{8,}$'
  AND option_name NOT LIKE 'wp_%'
  AND option_name NOT LIKE '_transient_%';

• Check the wp_posts table for hidden spam posts with post_status = 'publish' that you didn’t create.
• Check wp_users for admin accounts you don’t recognise (we cover this in attack 8).
• Export your database before making changes. If you delete the wrong option, you can restore it.

Once an attacker gets into your site, the first thing they often do is create a hidden admin account for themselves. This is their persistence mechanism: even if you clean all the malware, they still have a working login. These accounts are usually given plain-looking names like “wpsupport”, “sysadmin”, “backup”, or sometimes they’re hidden entirely from the user list using a plugin the attacker installs.

What happens if you don’t fix it: A Dubai consultancy cleaned up a malware infection and thought they were safe. Six weeks later, the site was hit again, worse than before. The cause: a hidden admin user named “update-manager” that had been created during the first attack and never deleted. The attacker simply logged back in with it. The second cleanup cost three times more because so much more damage had been done.

How to fix it:

• Go to Users → All Users in WordPress admin and review every account. Delete anyone you don’t recognise.
• Check the database directly in case an admin is hidden from the UI:

-- List ALL users with admin role, regardless of UI visibility
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

• Reset passwords for every remaining admin after a cleanup, not just the ones you suspect are compromised.
• Enable login notifications so you get an email every time an admin logs in. Plugins like WP Activity Log or Wordfence do this.
• After a major cleanup, delete all active sessions so stolen cookies become useless:

-- Force logout of every user (they'll have to log in again)
UPDATE wp_usermeta
SET meta_value = ''
WHERE meta_key = 'session_tokens';

A webshell is a small PHP file that gives an attacker an interactive control panel for your server via a browser. They can browse your files, run database queries, download your data, and install more malware. Webshells are usually uploaded through file upload vulnerabilities (attack 3) and hidden among thousands of real files in /wp-content/uploads/.

What happens if you don’t fix it: A Jebel Ali logistics company had a webshell hidden in their uploads folder for 11 months. The file was named thumb-cache-2023.php to look legitimate. The attacker used it periodically to check for new shipping records and customer invoices. The breach was only discovered during an unrelated compliance audit, long after significant data had been exfiltrated.

How to fix it:

• Apply the upload folder PHP execution block from attack 3. This alone neutralises most webshells.
• Scan for suspicious PHP files in directories that shouldn’t contain any:

# Run via SSH from the WordPress root
# Find all PHP files in uploads (there should normally be zero)
find ./wp-content/uploads -type f -name "*.php"

# Find files with common webshell signatures
grep -r --include="*.php" -l "eval(base64_decode" ./wp-content/
grep -r --include="*.php" -l "gzinflate(base64_decode" ./wp-content/
grep -r --include="*.php" -l "system(\$_GET\|shell_exec(\$_POST\|passthru(\$_REQUEST" ./

• Compare the file structure of your wp-includes and wp-admin folders to a fresh WordPress download. Any extra files are suspicious.
• Install a file integrity monitoring plugin (Wordfence, Sucuri Security) that alerts you when new PHP files appear anywhere they shouldn’t.

Cross-Site Request Forgery tricks an authenticated admin into performing actions they didn’t intend. For example, an attacker crafts a link or an image that, when loaded by a logged-in admin, silently triggers an action on the WordPress site: creating a new user, changing a setting, or installing a plugin. WordPress has a built-in defence called “nonces” (numbers used once), but many custom or cheap plugins skip them.

What happens if you don’t fix it: A boutique hotel in Fujairah had a custom “quick edit” plugin built by a freelancer. The plugin had no CSRF protection. An attacker sent the hotel manager a link to what looked like a booking confirmation. When she clicked it while logged into WordPress in another tab, the link silently changed her admin email address to the attacker’s. The attacker then did a password reset, took over the account, and deleted all bookings for the following week.

How to fix it:

• If you write any custom WordPress code that changes data, always use nonces:

// When generating a form:
<form method="post" action="">
    <?php wp_nonce_field('my_action_name', 'my_nonce'); ?>
    <!-- form fields -->
</form>

// When processing the form, verify the nonce first:
if (!isset($_POST['my_nonce']) ||
    !wp_verify_nonce($_POST['my_nonce'], 'my_action_name')) {
    wp_die('Security check failed');
}

// Also verify capabilities
if (!current_user_can('manage_options')) {
    wp_die('Insufficient permissions');
}

• Review every custom plugin or theme function that processes $_POST or $_GET data. If there’s no wp_verify_nonce() call, the action is vulnerable.
• Prefer established form plugins over custom code. Gravity Forms, WPForms, and Fluent Forms handle nonces correctly.

Every WordPress site has a file called admin-ajax.php used by legitimate AJAX requests, plus a “Heartbeat API” that pings the server every 15 to 60 seconds from every open admin tab. Attackers flood these endpoints to overload your server with cheap-to-send but expensive-to-process requests. Unlike a traditional DDoS, this one hits your PHP and database directly.

What happens if you don’t fix it: A UAE news site on shared hosting became slow and unresponsive every evening. Investigation showed tens of thousands of requests per hour to admin-ajax.php from distributed IPs. Legitimate visitors got timeouts. Google’s Core Web Vitals scores tanked. The site dropped from first page to second page on major search queries, and it took months to recover rankings.

How to fix it:

• Throttle the Heartbeat API so it doesn’t run on the front-end for logged-out users:

// Disable Heartbeat on the front-end, slow it down in admin
add_action('init', function() {
    global $pagenow;

    // Disable on the front-end entirely
    if (!is_admin()) {
        wp_deregister_script('heartbeat');
        return;
    }

    // On post edit screens, slow the heartbeat (default 15s, set to 60s)
    if (in_array($pagenow, ['post.php', 'post-new.php'])) {
        add_filter('heartbeat_settings', function($settings) {
            $settings['interval'] = 60;
            return $settings;
        });
    }
}, 1);

• Put Cloudflare in front of your site and set a rate limit rule on /wp-admin/admin-ajax.php (for example, no more than 30 requests per minute per IP).
• If you don’t need AJAX on the public side of the site, block unauthenticated access to admin-ajax from non-logged-in users via a firewall plugin like Wordfence.

Comment spam isn’t just annoying, it can also be a security problem. Spam comments often include malicious links that damage your site’s SEO (Google penalises sites linking to known bad domains), and sometimes they contain payloads designed to exploit unpatched XSS vulnerabilities in poorly coded themes.

What happens if you don’t fix it: A Dubai tourism blog had comments open with no moderation. Within six months, over 400,000 spam comments were posted, many linking to gambling and adult sites. Google’s automated systems flagged the site as a “link farm” and dropped its rankings across all queries. Recovery required deleting all the spam and submitting a reconsideration request, which took four months to process.

How to fix it:

• Never allow unmoderated comments. Go to Settings → Discussion and require manual approval for every comment.
• Install Akismet (free for personal sites, paid for commercial) or Antispam Bee (free alternative) to filter obvious spam automatically.
• Disable comments entirely on pages that don’t need them (contact, about, service pages).
• Close comments automatically on posts older than 30 days, most comment spam targets old posts:

// Close comments on posts older than 30 days automatically
add_filter('comments_open', function($open, $post_id) {
    $post = get_post($post_id);
    if ($post && (time() - strtotime($post->post_date)) > (30 * DAY_IN_SECONDS)) {
        return false;
    }
    return $open;
}, 10, 2);

• If you don’t need comments at all, disable them sitewide. A plugin like “Disable Comments” removes all comment functionality in one click.

If your WordPress site sends email through its own server (which it does by default) and your contact forms are not protected, spammers can abuse them to send phishing or scam emails that appear to come from your domain. Your server’s IP gets blacklisted. Emails you actually want to send (order confirmations, customer replies, internal communications) start landing in spam folders or bouncing back.

What happens if you don’t fix it: A Dubai e-commerce store noticed that order confirmation emails were no longer reaching customers. The cause: their contact form had been abused for weeks to send thousands of phishing emails impersonating DU telecom. The server’s IP was blacklisted by every major email provider. Orders were being placed but customers never received confirmation, so they contacted the store thinking the orders failed, or simply disputed the charges.

How to fix it:

• Add reCAPTCHA v3, hCaptcha, or Cloudflare Turnstile to every form. Invisible challenges block bots without annoying real users.
• Use a proper transactional email service (SendGrid, Mailgun, Amazon SES, Postmark) rather than your server’s built-in mail function. This also improves deliverability.
• Configure SPF, DKIM, and DMARC for your domain. Our DMARC Force service sets this up and monitors it.
• Limit contact forms to logged-in users where possible (internal tools, support forms).
• Rate-limit submissions: no more than 3 submissions per IP per hour is a safe default for contact forms.

The functions.php file of your active theme runs on every single page load. It’s the perfect place to hide a backdoor: a few lines of PHP that give an attacker a secret way to execute commands on your server. Because the file is part of a theme, it survives WordPress core updates.

What happens if you don’t fix it: A freelance developer copying code snippets from a random blog pasted a “WordPress speed optimisation” snippet into his client’s functions.php. The snippet included hidden code that accepted commands from a specific URL parameter. Three months later, the attacker who had distributed the snippet triggered all sites that had copied it, using them to host a phishing campaign. The client’s site was blacklisted by Google.

How to fix it:

• Never paste code into functions.php without understanding every line. Be especially wary of code that includes base64_decode, eval, gzinflate, or connects to external URLs.
• Use a child theme, so updates to the parent theme don’t overwrite your customisations AND so you can easily compare your functions.php to the original.
• Scan functions.php (and wp-config.php) for suspicious patterns:

# SSH into the server and search theme files
cd wp-content/themes
grep -rn "eval(" .
grep -rn "base64_decode" .
grep -rn "str_rot13" .
grep -rn "gzinflate" .
grep -rn "preg_replace.*\/e" .
grep -rn "file_get_contents(\"http" .

• Enable file integrity monitoring (Wordfence does this), which alerts you whenever functions.php is modified.
• Consider making theme and plugin files read-only in production:

// Add to wp-config.php to disable file editing from the admin
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);

Directory traversal (also called “path traversal”) is when a plugin accepts a file path from user input without validation, letting an attacker navigate outside the intended directory. For example, ?file=../../../../wp-config.php lets them read your database credentials. Dozens of WordPress plugins have had this flaw over the years.

What happens if you don’t fix it: A Dubai translation service used a file download plugin that passed filenames directly from the URL to PHP’s readfile(). An attacker used path traversal to download wp-config.php, got the database credentials, and connected to the database directly from outside. They dumped all translated documents (confidential client materials) and sold the access on a forum.

How to fix it:

• Keep every plugin updated (see pillar article risk 1). Directory traversal fixes are common in plugin updates.
• Subscribe to a vulnerability database (Patchstack, WPScan) that alerts you to newly disclosed WordPress plugin vulnerabilities.
• Uninstall plugins you don’t actively use.
• Move wp-config.php one level above the WordPress root if your hosting allows. WordPress looks for it there automatically:

# If your WordPress is at:   /home/user/public_html/
# Move wp-config.php to:      /home/user/wp-config.php

# This moves it outside the web-accessible directory
# so web-based traversal attacks can't reach it
mv /home/user/public_html/wp-config.php /home/user/wp-config.php

# Set tight permissions
chmod 600 /home/user/wp-config.php

• Use a WAF (Cloudflare, Wordfence, SiteLock) that detects and blocks path traversal patterns in URLs automatically.

Attackers inject JavaScript-based cryptocurrency miners into WordPress sites so that every visitor’s CPU is used to mine cryptocurrency for the attacker. The code runs in the visitor’s browser for as long as they’re on your page. Your visitors’ laptops and phones get hot and slow, your bounce rate increases, and your reputation suffers.

What happens if you don’t fix it: A Dubai children’s school had their WordPress site infected with a crypto miner hidden in the header template. Parents visiting the site noticed their laptop fans running at maximum while on the school’s website. Word spread on WhatsApp parent groups within a day. The school had to explain the breach publicly, apologise, and rebuild trust, which took months.

How to fix it:

• Scan your theme files for unexpected JavaScript in the header.php, footer.php, and any template files.
• Check the wp_options table for option names that sound like they contain scripts (see attack 7).
• Add a strict Content Security Policy (CSP) header that blocks JavaScript from unknown domains:

# .htaccess: restrict script sources to your own domain plus trusted services
<IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; \
    script-src 'self' 'unsafe-inline' https://www.google-analytics.com \
    https://www.googletagmanager.com; \
    style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; \
    font-src 'self' https://fonts.gstatic.com; \
    img-src 'self' data: https:; \
    frame-ancestors 'self';"
</IfModule>

Test the CSP in “report-only” mode first (Content-Security-Policy-Report-Only) to see what legitimate scripts are running before enforcing it.

This is one of the most financially damaging WordPress hacks because it’s often invisible. The attacker injects hidden pages or hidden backlinks into your site that rank on Google for commercial queries, then sells that ranking to scam services. Your visitors see nothing wrong, your traffic might even increase temporarily, but Google eventually detects the spam and de-ranks your entire domain.

What happens if you don’t fix it: A legitimate Dubai dental clinic’s WordPress site was infected. The malware injected 800 hidden pages about online gambling, all ranking on Google in English and Arabic for gambling queries. Traffic tripled for two months, all of it bouncing instantly. Then Google’s manual actions team intervened. The clinic’s main service pages dropped off the first page of search results for “dentist Dubai” and similar terms. Recovery took eight months.

How to fix it:

• Check Google Search Console’s “Coverage” report monthly. Any indexed pages you didn’t create are a red flag.
• Run site:yoursite.com casino, site:yoursite.com viagra, site:yoursite.com poker in Google. Zero results = probably clean. Any results = infected.
• Look at your database for posts with suspicious titles or content:

-- Find published posts you might not have created
SELECT ID, post_title, post_date, post_author
FROM wp_posts
WHERE post_status = 'publish'
  AND post_type IN ('post', 'page')
ORDER BY post_date DESC
LIMIT 100;

-- Find posts with spam keywords (adjust for your site language)
SELECT ID, post_title
FROM wp_posts
WHERE post_content REGEXP 'viagra|casino|poker|loan|crypto-invest'
   OR post_title REGEXP 'viagra|casino|poker|loan|crypto-invest';

• Check for hidden links in footer widgets and in the database (wp_options where option_name = 'widget_text').
• Use a malware scanner that specifically detects SEO spam patterns. SiteLock includes Spam Blacklist Monitoring on the Fix and Defend plans.

WordPress has a built-in scheduled task system called wp-cron that runs on every page load and fires scheduled events. Attackers create fake scheduled events that re-inject malware, create admin backdoors, or exfiltrate data on a schedule. Because these events live in the database and trigger silently, they often survive file-level cleanups.

What happens if you don’t fix it: A UAE boutique bakery cleaned their hacked WordPress site three times with the help of a freelancer. Each time, the malware came back within 48 hours. The cause was a malicious wp-cron event scheduled to run every 12 hours, which re-downloaded and re-installed the backdoor. Only when someone inspected the cron schedule did they finally stop the re-infection.

How to fix it:

• List all scheduled events and look for suspicious ones. Install the free “WP Crontrol” plugin for a readable UI, or use WP-CLI:

# Via WP-CLI over SSH
wp cron event list

# Look for event hooks you don't recognise from plugins or themes
# Delete suspicious events:
wp cron event delete <hook-name>

• Check the database directly if WP-CLI isn’t available:

-- View the cron schedule stored in the database
SELECT option_value
FROM wp_options
WHERE option_name = 'cron';

-- It's a serialized PHP array. If you see hook names with random strings
-- like "wp_XxYyZz_handler" that aren't from known plugins, they're suspicious.

• For very active sites, replace WordPress’s page-load-based cron with a real server cron job for reliability:

// Disable wp-cron on page loads in wp-config.php
define('DISABLE_WP_CRON', true);

# Then set up a real server cron via cPanel or crontab to run every 5 minutes
*/5 * * * * wget -q -O - https://yoursite.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

This also makes the site faster, because wp-cron won’t fire on every visitor page load anymore.

Your WordPress Security Stack for UAE Businesses

If all of this feels like a lot to maintain manually, that’s because it is. The practical solution is layering a few tools and services that handle most of the work automatically. Here is a recommended stack scaled to business size.

30-Day WordPress Hardening Plan

Don’t try to do everything in one day. Here’s a realistic four-week schedule to work through the most impactful protections.

When You Think Your WordPress Site Is Hacked

If you notice any of these warning signs, assume your site is compromised and act fast:

• Google Search Console sends a “Security Issues” alert or shows “This site may be hacked” on your search results.
• Your site redirects visitors to other websites, or shows content you didn’t create.
• You can’t log in to WordPress admin with credentials that used to work.
• Your hosting provider contacts you about malicious activity, high resource usage, or outbound spam.
• Customers, colleagues, or Google show you pages on your site that you didn’t create.
• New admin users, plugins, or scheduled tasks appear that you didn’t add.
• Your traffic in Google Analytics suddenly spikes with bounce rate near 100 percent.

Immediate response checklist:

1. Take the site offline temporarily (put up a maintenance page) to stop the damage spreading.
2. Change every password: WordPress admin, hosting control panel, FTP, database, email. From a clean device, not the one you’ve been using.
3. Restore from a clean backup from before the infection started if you have one. An automated website backup service with daily restore points makes this step trivial instead of impossible.
4. If you don’t have a clean backup, hire a professional cleanup service or use SiteLock with automatic malware removal on the Fix or Defend plan.
5. After cleanup, change all passwords again (in case the attacker captured the first round of new ones), review user accounts, check the database for persistent malware (attacks 7 and 18), and enable file integrity monitoring.
6. Submit a reconsideration request in Google Search Console if Google flagged the site. Include a description of what was compromised and what you fixed.
7. Notify affected customers if personal data may have been exposed. Under UAE law, you may be required to notify the UAE Data Office within a defined timeframe.

Summary

WordPress is powerful and flexible, but it attracts more attackers than any other website platform on earth. The 18 attack techniques in this article cover what actually happens to WordPress sites in the real world, from UAE small businesses to global enterprises. The core lessons:

1. Never use nulled themes or plugins. The “savings” always cost more than the licence.
2. Update everything, always. Outdated plugins and themes are the single biggest cause of WordPress compromises.
3. Block WordPress-specific leak points: XML-RPC pingbacks, user enumeration, PHP execution in uploads, file editing in admin.
4. Check the database, not just files. Persistent malware hides in wp_options, scheduled events, and hidden admin users.
5. Layer your defences: hosting-level protection, a WAF, malware scanning, backups, and monitoring. No single tool is enough.
6. Have a response plan ready. When something goes wrong at 2 AM on a holiday, you want to know exactly what to do.
7. Consider managed hosting. AEserver Managed WordPress handles automatic updates, malware scanning, daily backups, and a WordPress-aware WAF out of the box.

For general website security practices that apply beyond WordPress (SSL, passwords, 2FA, DDoS protection, security headers), read our companion article: Website Security Best Practices: 17 Risks and Fixes. Together, these two guides cover everything a UAE business owner needs to know to keep their site, their customers, and their reputation safe.

×