The Real Price of WordPress "GPL" and "Nulled" Plugins

The pitch sounds reasonable

You see the ad. “WordPress is GPL — premium plugins are GPL — therefore everything should be free.” The marketplace charges $5 a month for unlimited downloads of plugins that retail for $59, $99, $299 each. A few sites take it further and host the files for free, monetized with affiliate links and ads. The logic seems airtight: if the license permits redistribution, where’s the harm?

This article walks through what’s actually inside those files. As someone who builds and maintains a commercial WordPress plugin, I’ve spent the last few years examining nulled copies of my own work and other plugins from the same marketplaces. The pattern is depressingly consistent — and the “license bypass” itself is usually the least interesting thing in the file.

Part 1: The license bypasses are mostly theater

Most modern commercial plugins don’t really run a license check locally and then unlock features. They make HTTP requests to a microservice, and the server’s response gates premium functionality like image processing, indexing, AI features, sync, analytics and so on.. The “license check” you’d want to bypass isn’t a boolean somewhere in the PHP; it’s an HTTP round-trip whose response carries the actual data the plugin needs.

So what do nullers do? They intercept the HTTP call and fake the response. Below is an example of WordPress’ pre_http_request hook that lets any plugin short-circuit any outbound request. Inject a callback, return a hardcoded “success” payload, and the plugin’s license check appears to pass:

PHP

That’s the entire “bypass” in many cases. A faked HTTP response and a pre-seeded options row.

Here’s what’s funny about it: for most well-built plugins, this does nothing. The premium features call back to the vendor’s API for actual data — generated images, indexing results, AI-processed content, license-signed configuration. Faking a {“status”: 1, “message”: “ok”} response doesn’t produce that data. The user sees admin screens that say the plugin is licensed. The “Pro” features either don’t work, work partially, or work for a few weeks until the next plugin update breaks the patch.

Just recently I dealt with a couple of bug reports, which in the end turned out to be caused by the “professional” nullers, who managed to not only fake the license activation, but also break some of the core features doing so.

The reason nullers ship these obviously broken bypasses anyway is straightforward: their customers can’t tell. Most buyers of nulled plugins are not technical enough to verify what works. They see “Pro Activated” in the admin screen, they trust the marketplace, and they move on. The marketplace gets paid. The buyer thinks they got a deal. The plugin’s premium features quietly don’t work, and the user blames “compatibility issues” with their theme.

Part 2: What’s actually in the files

The license bypass is rarely shipped alone. Security researchers have documented the same patterns appearing across the nulled-plugin ecosystem for the better part of a decade. After personally assisting with over 5 000 support tickets in my carreer, I have seen it all, and it’s nasty. I can’t even count how many times I had to warn users of suspicious code I discovered on their servers on accident, while trying to solve unrelated bugs in my plugin.

The snippets below are only non-working examples. Usually they are encoded and obfuscated to a non-readable format and eval’d directly, so the untrained eye doesn’t spot them right away.

Slide

Do you have a license yet?

GET AJAX SEARCH PRO

Category 1: Hidden administrator account creation

This is the most common payload because it’s the most useful to the attacker. A small block of code, usually buried in a file with a mundane name, ensures that an attacker-controlled administrator account exists on the site — and that it stays there even if you delete it.

Sucuri’s malware research team documented a 2025 case where a disguised plugin file checked on every page load whether a user named adminbackup existed, and recreated it if missing. It silently created an admin user and actively concealed it from the WordPress admin dashboard. The attacker manually or programmatically uploaded the fake plugin into the plugins folder. Because it used a legitimate-looking name and metadata (WP Compatibility Patch), it could easily evade detection during a superficial plugin review.

A separate Sucuri case study described how this snippet forces WordPress to create a new user named help with the role of administrator. If the user already exists, the script ensures it has administrator privileges restored. This simple trick allows attackers to slip in unnoticed by posing as a plugin that administrators might ignore. To remain hidden, the plugin removed itself from plugin listings and filtered user queries to hide the newly created admin account.

A sanitized illustration of the pattern:

PHP

The persistence aspect is what makes this devastating. It is somewhat humorous that the attackers misspelled administrator but this flows with their lack of any attempt to better hide the malware. This is probably one of the laziest attacks we’ve seen in a while. Lazy or not, even when administrators discover the rogue user and delete it, the plugin recreates it on the next page load. Many site owners report cleaning their site three or four times before realizing the source.

Category 2: Rogue REST API endpoints for data exfiltration

WordPress’s REST API makes it trivial for any plugin to register publicly accessible endpoints. The legitimate use is fine. The malicious use is to register an endpoint whose permission callback is __return_true, meaning anyone, with no authentication, can hit it and receive whatever the endpoint returns.

A 2026 CVE described exactly this pattern in a legitimate plugin’s unintended bug: When the plugin registers its REST API route for appointment data, it uses the built-in WordPress permission callback __return_true, which unconditionally returns true for all requests. This effectively disables any authentication or authorization verification, allowing anyone, including unauthenticated external attackers to extract sensitive customer appointment data including full names, email addresses, phone numbers, IP addresses, appointment descriptions, and pricing information.

In a nulled plugin, this isn’t a bug, it’s the feature. A sanitized illustrative pattern:

PHP

The attacker doesn’t need to log in. They don’t need to exploit anything. They just need to know the URL. The endpoint stays available as long as the plugin is installed. Site owners exporting customer lists, payment info, API keys stored in wp_options, or session data have, in many documented cases, been doing so for months without realizing it.

Category 3: Third-party script injection (ads, SEO spam, backlinks, miners)

This is the oldest category and the most common in older infections. The plugin hooks into wp_head, wp_footer, or the_content and injects something on every page load.

The injected content varies by campaign:

SEO spam: Hidden links to gambling, pharmaceutical, or adult sites. The page renders normally for visitors but is full of spam links for search engine crawlers. Sometimes the spam is conditional on the user agent — humans see a clean page, Googlebot sees a link farm.
Affiliate hijacking: Replaces or wraps your outbound links with affiliate IDs that profit the attacker.
Drive-by malware redirects: Conditional JavaScript that redirects mobile visitors to fake app stores, pop-up scams, or phishing pages.
Cryptocurrency miners: JavaScript that uses the visitor’s CPU to mine for the attacker.

A 2025 cyberpress.org analysis described the pattern: Attackers embedded a deceptively simple function ti_custom_javascript() at the bottom of the file. This function is hooked into WordPress’s wp_head action, ensuring it executes on every page render. The PHP code establishes a POST request to hxxps://brazilc[.]com/ads[.]php, then echoes the server’s response into the HTML head section. By fetching content at runtime, the attackers avoid storing JavaScript directly on the compromised server, reducing the likelihood of detection by static scanning tools.

The fetch-at-runtime approach is the key innovation. The malicious payload doesn’t live in your files, your files just contain instructions to fetch and execute whatever the attacker’s server is serving today. Static malware scans miss it because there’s no malware to find locally. The attacker can swap payloads at will: SEO spam this week, a crypto miner next week, a phishing redirect next month.

A sanitized illustration:

PHP

Category 4: Sleeping botnet triggers

This is the category I find most chilling, because the infected site does nothing visibly wrong for weeks or months. The plugin includes code that periodically phones home to a command-and-control server, asking "anything to do?" If the answer is no, nothing happens. If the answer comes back with a payload, the site executes it.

CryptoPHP, documented by Fox-IT, is the canonical example. Fox-IT has determined that the purpose of the malware is, currently, to engage in black-hat SEO by injecting links to other, presumably malicious, websites into your content. However this infection is sophisticated and it communicates with command and control servers that can instruct it to do a variety of tasks including the ability to upgrade itself. So this is a classic botnet infection which turns all infected websites into drones that can be instructed to do just about anything, from sending spam email to SEO spam to hosting illegal content to performing attacks on other websites.

The Patchstack analysis of WP-VCD, a long-running family of malware specifically distributed via nulled plugins, describes essentially the same pattern. The WP-VCD malware for WordPress has existed for many years. It mainly spreads by injecting itself into legitimate plugins and themes after which it will spread itself on sites that offer downloads to (nulled) WordPress plugins and themes. A recent research paper notes the same architecture: The malware functions as a bot. Upon infection, it sends a "phone home" request to a hardcoded C2 domain.

A sanitized pattern:

PHP

The crucial design choice: the malware doesn't contain the malicious payload. It contains the ability to fetch one when instructed. For weeks or months, your site looks clean to any scanner. Then one day the attacker activates the network, and tens of thousands of sites simultaneously start sending phishing emails, mining crypto, attacking another target, or hosting illegal content. You become an unwitting participant in a coordinated attack, and your IP, your hosting account, and your domain are what shows up in the abuse reports.

Category 5: Remote code execution and shell access

The most severe payloads attempt to give the attacker full PHP execution, and from there, potentially shell access to the underlying server.

The classic pattern is eval(base64_decode(...)) somewhere in a plugin file, where the base64 content is either fetched remotely or sent in a POST parameter. The Sucuri team has documented this for over a decade: It uses the file_put_contents function to create a PHP script into the docroot of the website with the specified remote code execution backdoor.

A sanitized illustration:

PHP

Once an attacker has PHP execution on your site, what they do next depends on your server. On a properly hardened shared host, they're limited to PHP-level damage, which is already catastrophic. On a poorly configured server, they can read /etc/passwd, scan internal networks, attempt privilege escalation, exfiltrate database dumps, install reverse shells, or pivot to other tenants on the same machine.

A DEV Community case study described the typical aftermath: Digging deeper revealed the entry point: a nulled (pirated) premium plugin the client had installed months earlier. Nulled plugins often contain hidden backdoors. Malicious code in functions.php using base64_decode and eval to execute remote payloads. Injected scripts in the database (wp_posts and wp_options tables), creating hidden spam pages. A backdoor file disguised as a core WordPress file (e.g., wp-feed.php with extra code).

The injected database entries are particularly hard to clean. Once executed, the malware ensures it survives even if the original infected plugin is deleted. Core File Infection: It scans the wp-includes directory and injects its code into post.php. By the time you realize the original plugin was the source, the infection has spread to core WordPress files, your theme's functions.php, and rows in your database. Deleting the plugin doesn't help. You're cleaning core files and the database while the malware actively re-infects everything you've just cleaned.

Part 3: What you actually pay

Let's tally the real cost of saving $59 on a plugin license.

Direct cleanup costs. Professional WordPress malware removal services charge meaningful money. Snazzy Solutions, summarizing typical market pricing: Most WordPress hack cleanups cost between $500 and $3,000+. A simple malware removal on a small business site with a single infection point? You might get away with $300-$500 if you find the right freelancer. A full-blown compromise where the attacker has backdoors buried in your database, your theme files, your plugins, and maybe even your server configuration? That's easily $1,500-$3,000 or more, especially if you need emergency, same-day service.

A separate guide cites similar figures: Professional cleanup typically costs $300-2000 depending on complexity, but includes forensic analysis, complete malware removal, security hardening, and guarantees against reinfection.

Forestal Security breaks this down further: Malware removal services. Basic cleanup can start as low as $75 for a one-time fix, as offered by Fixed.net. SolidWP's service for non-mission critical websites runs $299, while SiteLock may charge $350 upfront. They also note: Developer or agency fees. If you hire a developer hourly, a thorough cleanup might start around $400 based on four hours of work at a rate of $105 per hour. Severe hacks that burrow deep into your core WordPress files can take much longer, pushing your total into the thousands.

Downtime and lost revenue. While you're cleaning the site, customers can't buy from you. If you run an e-commerce site doing $1,000/day in revenue, a five-day cleanup costs you $5,000 in lost sales on top of the cleanup fee itself.

SEO and reputation damage. Google flags compromised sites in search results. The "This site may harm your computer" warning destroys traffic, and getting it removed requires you to have fully cleaned the site and submitted a reconsideration request, which itself takes time. SEO spam injected by the malware can survive cleanup if you don't catch every database row, and the spammy backlinks the attacker built using your domain can keep dragging your rankings for months. Sucuri's reporting notes that SEO spam makes up a huge percentage of WordPress infections, and it's one of the trickiest to fully remove because it buries itself in your database.

Data breach liability. If the malware exfiltrated customer data, email addresses, phone numbers, payment info, addresses, you're now in regulatory territory. Under GDPR, that's notification obligations to affected users and your data protection authority within 72 hours of discovery. Under various US state laws, similar obligations apply. Fines for failure to notify can be material. Civil suits from affected customers are increasingly common.

PCI compliance fallout. If your site processed payment cards and was breached, you're looking at forensic investigation requirements, potential loss of merchant account status, and PCI fines. As one cleanup service notes: For WooCommerce sites that handle payment data, a hack can trigger PCI compliance issues that cost far more than the cleanup itself.

Hosting costs. A site running a crypto miner or participating in a botnet uses dramatically more CPU and bandwidth than a clean site. As we worked through the hacked site's cleanup, another unexpected consequence of the hack came to light: the malware wasn't just sabotaging the website's functionality; it was also inflating the client's hosting costs. Many shared hosts suspend accounts that exceed resource limits, meaning you find out you're infected because your host took your site offline.

Cross-contamination. On shared hosting, an infected site can spread to neighboring sites on the same server. If your hosting account contains multiple sites, all of them are at risk, and cleanup costs multiply accordingly.

The recurring expense of paranoia. Once a site has been compromised once, you can never quite trust your backups again. How far back does the infection go? Was your "clean" backup from three months ago actually clean? Most professionals recommend ongoing monthly security maintenance after an incident, easily $30 to $100 per month for the rest of the site's life.

Let's add the conservative case: you saved $59 on a plugin license. Your site got cleanly compromised. Cleanup cost: $1,200. Downtime: $2,000. Six months of post-incident maintenance: $300. SEO recovery: indeterminate but non-zero. Total: $3,500+ to save $59.

The pessimistic case, data breach, PCI fallout, sustained reputation damage, runs into five and six figures and is bounded only by your business size.

Part 4: The support you don't get

There's a category of cost that doesn't show up in any cleanup invoice: the support and updates you forfeited.

When a security vulnerability is found in a premium plugin, the developer typically pushes an urgent patch within hours to days. The plugin's auto-update system pulls the fix down to every licensed installation. By the time the vulnerability is public knowledge, most legitimate users are already patched.

If you're running a nulled copy:

You don't get the patch automatically. The nuller has to re-null the patched version, which takes days or weeks if they bother at all. Many nulled-marketplace plugins lag the official version by months. Some are abandoned at whatever version was current when the marketplace owner lost interest.
You don't get support when something breaks. No ticket system. No "contact the developer." The most you can hope for is a forum thread on the nulled-marketplace site where other pirates speculate about what might be wrong.
You don't get compatibility testing. Legitimate developers test their plugins against new WordPress versions, popular themes, common companion plugins. Nullers don't. When WordPress 6.5 ships and breaks something, you're on your own — and you can't even file a bug report.
You don't get the new features. Every release adds value. You're stuck on whatever ancient version the nuller last bothered to repackage.
You can't get help from any reputable security firm without admitting how you got infected. "I downloaded my plugin from a Russian forum and now my site is hacked" is a conversation most professional security consultants will charge you extra to have, and some won't take at all.

There's also the moral dimension nobody likes to talk about. A working WordPress plugin economy depends on developers being paid for their work. Every legitimate license sold funds continued development, security patches, support, and improvements. Every nulled install is a free ride on the back of paying customers. The plugins that get nulled the most aggressively are often the same ones that quietly shut down a year or two later because their developers couldn't sustain the work — which means even the paying customers eventually lose access to updates. The pirates kill the thing they were stealing from.

Part 5: How to tell if you're already running infected code

If you're reading this and uncertain about plugins on a site you currently operate, here are the things worth checking:

Look for plugins from non-official sources. Anything you didn't download from WordPress.org or directly from the plugin vendor's website should be considered suspect. Free download sites for premium plugins are essentially guaranteed to be infected.

Search your plugin files for suspicious patterns. Run grep -r 'base64_decode' wp-content/plugins/ and grep -r 'eval(' wp-content/plugins/ and review every result. Legitimate plugins occasionally use these, but they're rare and obvious. Hits in random files with unusual names are red flags.

Audit your WordPress user list. Go to Users → All Users and confirm every admin account is one you recognize. Bear in mind that some malware hides accounts from this list — checking the database directly with SELECT * FROM wp_users is more reliable.

Check your registered REST routes. Visit /wp-json/ on your site. The output lists every route registered by every active plugin. Routes you don't recognize, especially under unusual namespaces, deserve investigation.

Look at the modification times of files in wp-includes/. Core WordPress files shouldn't have been modified after your last WordPress update. Files in wp-includes/ with recent timestamps are extremely suspicious.

Review your hosting account's outbound traffic logs. If your site is calling out to domains you don't recognize, especially repeatedly and on a schedule, something is talking to a command-and-control server.

If any of these turn up anything alarming, get professional help. Don't try to clean a compromised site yourself unless you really know what you're doing — half-cleaned sites get reinfected within days.

The bottom line

If you get the nulled, you will get nulled eventually.

The pitch is that nulled plugins are a smart way to save money on something that's "really" free under the GPL anyway. The reality is that the people doing the nulling aren't ideological GPL warriors, they're running a malware distribution business with a clever cover story. The "free plugin" is the bait. The payload is the product.

You can buy a year of a typical premium plugin license for less than the cost of one hour of a cleanup specialist's time. You can buy several premium licenses for less than the cost of a single basic malware removal. The economics of using nulled plugins only work if you assume nothing will go wrong, and the entire commercial purpose of distributing nulled plugins is to make sure something does.

Pay for the plugin. Get the updates. Get the support. Keep your site, your customers, and your reputation. The "free" version is the most expensive software you'll ever install.