DEV Community: Nexura Security

WordPress Malware Keeps Coming Back? How to Find and Stop the Real Cause

Nexura Security — Mon, 21 Sep 2026 12:33:25 +0000

You delete the infected file.

A few minutes later, it is back.

You clean the website again. The same suspicious PHP file appears. Maybe a new administrator account is created. Maybe a strange script shows up inside wp-content, or a malicious redirect starts working again.

If this sounds familiar, you are probably not dealing with a single infected file.

Something else is putting it back.

This is one of the most frustrating WordPress security problems because deleting the visible malware does not necessarily remove the mechanism that created it.

That mechanism is often called persistence.

In this guide, we will look at why WordPress malware can return after cleanup, where the reinfection mechanism can hide, what you can check manually, and how a security scanner such as Nexura Security can help you investigate the problem.

Why Does WordPress Malware Keep Coming Back?

A common mistake during malware cleanup is focusing only on the file that was discovered.

For example, suppose you find:

/wp-content/uploads/cache.php

You delete it.

But what if another compromised PHP file contains code that executes something similar to:

file_put_contents(...);

and recreates cache.php?

The deleted file was only the symptom.

The actual problem was the code that recreated it.

This is why repeatedly deleting suspicious files can turn into an endless cycle.

A better question is:

What is creating this file again?

Once you identify the writer or persistence mechanism, you can remove the underlying cause instead of repeatedly cleaning the same symptoms.

Common Reasons WordPress Malware Returns

There are several places worth investigating when malicious files repeatedly reappear.

Malicious PHP File Writers

One of the first things to investigate is code capable of creating or modifying files.

Common PHP functions include:

file_put_contents()
fwrite()
fopen()
touch()
copy()
rename()

These functions are not malicious by themselves.

WordPress plugins and themes legitimately use filesystem operations.

The problem is when unexpected code uses them to create PHP files containing malicious payloads.

For example, a compromised script could write another PHP file into a writable directory.

Removing the generated file does nothing if the original writer remains.

What to investigate

Look for:

unexpected PHP files
recently modified PHP files
PHP inside upload directories
suspicious encoded strings
unfamiliar functions
files with unusual modification times
PHP files that do not belong in their directory

Do not automatically delete every file that looks unusual.

First determine what created it and whether the file is actually part of WordPress, a plugin, a theme, or your hosting environment.

WP-Cron Can Be Used for Persistence

WordPress has a scheduled task system called WP-Cron.

Plugins use it for completely legitimate tasks such as:

scheduled publishing
database maintenance
cache cleanup
email processing
updates

But if an attacker manages to create a malicious scheduled event, it can potentially execute unwanted code again later.

That can make a cleanup problem appear mysterious.

You delete the malware.

Later, a scheduled task runs.

The malware comes back.

What should you check?

Look for cron events that:

you do not recognize
belong to an uninstalled plugin
call unexpected PHP functions
reference suspicious files
execute unusually often
appeared around the time the compromise started

The important thing is not simply finding an unknown cron event.

You need to understand what the event executes and where that code comes from.

Must-Use Plugins Can Be Easy to Miss

WordPress has a special plugin directory:

wp-content/mu-plugins/

These are called must-use plugins.

They are loaded automatically and do not behave exactly like normal plugins in the WordPress Plugins screen.

That makes the directory important during a security investigation.

A malicious file placed there can survive normal plugin cleanup and may continue executing even when the administrator believes all plugins have been checked.

Look for:

wp-content/mu-plugins/

Then inspect unfamiliar files carefully.

Again, unfamiliar does not automatically mean malicious.

Some hosting companies and legitimate systems install must-use plugins.

The goal is to establish whether the file is expected and what it actually does.

Drop-ins and Other Special WordPress Files

WordPress also supports special files known as drop-ins.

Examples include files associated with:

advanced-cache.php
object-cache.php
db.php

depending on the site's configuration and installed software.

Caching, database, and hosting systems may legitimately use these files.

However, because they are loaded differently from ordinary plugins, they deserve attention during an investigation.

If suspicious code exists in a drop-in, deleting a normal plugin may not solve the problem.

.user.ini and auto_prepend_file

Another area that can be overlooked is PHP configuration.

A compromised site may contain configuration that causes another PHP file to be loaded automatically.

One example is:

auto_prepend_file=/path/to/file.php

The exact behavior depends on the PHP and hosting configuration, but the important security concept is simple:

A malicious file does not always need to be directly included by WordPress code.

Server or PHP configuration can cause additional code to execute.

During an investigation, check for unexpected:

.user.ini
php.ini

and relevant server configuration.

If you find auto_prepend_file, determine exactly what file it references and why.

Server Cron Can Recreate Malware

WordPress is not the only scheduler on a server.

Depending on the hosting environment, attackers may also abuse operating-system-level scheduled tasks.

For example:

crontab

could execute a script periodically.

This is particularly important on VPS, dedicated servers, and environments where users have shell access.

If the same malware appears at predictable intervals, timing can provide a useful clue.

For example:

The suspicious file appears every 15 minutes.

That does not prove a cron job is responsible, but it gives you something specific to investigate.

Compromised Administrator Accounts

Sometimes the malware is not automatically recreating itself at all.

An attacker may still have access to the website.

If a compromised administrator account remains active, malicious files can simply be uploaded again.

Check:

WordPress administrator accounts
unknown users
recently created users
suspicious login activity
hosting control-panel accounts
FTP/SFTP credentials
SSH keys
API credentials

Changing the WordPress administrator password alone may not be enough if another credential is compromised.

A complete incident response should consider all possible access paths.

A Vulnerable Plugin or Theme May Be the Entry Point

Persistence and initial compromise are two different questions.

You might successfully remove the persistence mechanism but leave the original vulnerability untouched.

Then the attacker can simply compromise the website again.

Common entry points include:

outdated plugins
vulnerable themes
abandoned extensions
compromised credentials
insecure file permissions
vulnerable custom code
outdated WordPress or server software

This creates another frustrating cycle:

clean → compromise → reinfect → clean → compromise

Therefore, malware removal should be followed by vulnerability investigation.

How to Investigate a Reappearing File

Suppose you have this file:

/wp-content/uploads/2026/09/cache.php

and it keeps coming back.

Instead of deleting it repeatedly, work backwards.

Step 1 — Record the filename

Write down:

cache.php

Also record:

full path
file size
modification time
permissions
owner
suspicious functions
Step 2 — Inspect the contents

Look for things such as:

eval()
base64_decode()
gzinflate()
assert()
preg_replace()
file_put_contents()

These functions can have legitimate uses, so their presence alone is not proof of malware.

Look at the surrounding code and understand what it actually does.

Step 3 — Search for references

Search the WordPress installation for:

cache.php

You may discover another script referencing it.

That reference could reveal the persistence mechanism.

Step 4 — Check timestamps

Compare the modification times of:

the recreated file
suspicious PHP files
plugin changes
theme changes
cron events
login activity

Timeline analysis can be extremely useful.

Step 5 — Identify the writer

The key question is:

Which process or code is writing this file?

Once you answer that, the investigation becomes much easier.

Why Deleting Malware Is Not the Same as Cleaning a Website

Malware cleanup is often described as:

Find bad file → delete bad file → website clean.

Real incidents can be more complicated.

A compromised website may contain:

Entry point
↓
Persistent access
↓
Malicious writer
↓
Generated PHP file
↓
Redirect / spam / backdoor

If you only remove the generated PHP file, the rest of the chain may remain.

The file simply comes back.

That is why a good investigation looks for the source, not only the visible payload.

Using Nexura Security to Investigate Reinfection

Manually investigating a compromised WordPress site can take time, especially when you are dealing with many files.

This is where Nexura Security can help.

Nexura Security is designed as a WordPress security toolkit with features for malware detection, vulnerability scanning, security auditing, headers, audit logs, and other security checks.

For a reinfection investigation, the useful approach is not simply:

"Delete suspicious files."

Instead, the goal is to identify suspicious activity and understand where it originates.

Nexura Security can help surface security findings that deserve investigation, including suspicious PHP code and WordPress-level security issues.

Free Nexura Security

The free version can be useful as a starting point for WordPress security investigation.

You can use it to inspect your site's security posture and identify findings that require attention.

This is especially useful when you want visibility before making changes.

Nexura Pro

For sites dealing with recurring infections or more advanced incidents, the Pro direction focuses on deeper investigation and response capabilities.

Depending on the available Pro features, this can include more detailed findings, quarantine workflows, and additional persistence-oriented checks.

The important principle remains the same:

Detect first. Understand the source. Then remove the cause.

A Practical Reinfection Investigation Checklist

If malware keeps returning, go through this checklist.

WordPress

Update WordPress

Update plugins

Update themes

Remove unused plugins

Remove unused themes

Check administrator accounts

Review recent login activity

Files

Search for recently modified PHP files

Check wp-content/uploads

Check mu-plugins

Check drop-ins

Check unexpected PHP files

Search for references to recreated files

Scheduled Tasks

Review WP-Cron events

Check server cron where available

Look for unknown scheduled scripts

PHP Configuration

Check .user.ini

Check auto_prepend_file

Review relevant PHP configuration

Hosting

Review FTP/SFTP users

Review SSH access

Review hosting-panel users

Rotate compromised credentials

Check server logs when available

Security

Run a malware scan

Run a vulnerability scan

Review audit logs

Check security headers

Monitor the site after cleanup

What If the Malware Still Comes Back?

If you have completed the cleanup and the same file returns, do not immediately start deleting files again.

Instead, collect evidence.

Record:

File path
Creation time
Modification time
File contents
Related PHP files
Cron events
User activity
Server logs

Then compare the timeline.

For example:

10:00 — suspicious file deleted
10:05 — file appears again
10:05 — WP-Cron executes
10:05 — another PHP file modified

A pattern like this gives you a much stronger lead than repeatedly deleting the same file.

Prevention After Cleanup

Once the infection is gone, prevention matters just as much.

Keep WordPress and extensions updated.

Remove software that is no longer required.

Use strong unique passwords.

Enable two-factor authentication for administrator accounts.

Limit unnecessary access.

Use appropriate file permissions.

Monitor important file changes.

Review scheduled tasks.

Keep reliable backups.

And most importantly, investigate the original entry point.

A clean website today can become compromised again tomorrow if the vulnerability that allowed the attacker in remains open.

Final Thoughts

When WordPress malware keeps coming back, the problem is usually bigger than the file you can see.

The suspicious PHP file may only be the final result of another process.

The real source could be:

a malicious file writer
a WP-Cron event
a server cron job
an MU-plugin
a drop-in
PHP configuration
a compromised account
a vulnerable plugin
or another persistence mechanism

That is why effective cleanup starts with one question:

What keeps recreating the malware?

Find that answer, and you can move from repeatedly deleting symptoms to actually addressing the cause.

If you are investigating a WordPress site with recurring malware, Nexura Security can give you a practical starting point for scanning, vulnerability detection, auditing, and security investigation.

Scan your WordPress site with Nexura Security and investigate the source of the reinfection—not just the file that keeps coming back.

[Get Nexura Security on WordPress.org]

FAQ
Why does WordPress malware keep coming back after I delete it?

Usually because another malicious file, scheduled task, compromised account, vulnerable component, or configuration is recreating it. Deleting the visible file may remove only the symptom.

Can WP-Cron cause WordPress malware to return?

A malicious or compromised scheduled task can potentially execute unwanted code. WP-Cron should therefore be reviewed when a file repeatedly appears.

Can malware hide inside wp-content/uploads?

Yes. PHP files in an uploads directory can be suspicious, although legitimate configurations can vary. Investigate unexpected executable files rather than automatically deleting everything.

What is a WordPress MU-plugin?

A must-use plugin is automatically loaded by WordPress and is handled differently from ordinary plugins. The wp-content/mu-plugins directory should therefore be included in a thorough security investigation.

Does scanning remove all WordPress malware?

A scan can identify suspicious files and security issues, but detection is not the same as complete incident response. Recurring infections require investigating the persistence mechanism and original entry point.

How can I stop WordPress malware from returning?

Identify the mechanism recreating the malware, remove the underlying persistence, patch the original vulnerability, rotate compromised credentials, and monitor the site after cleanup.

WordPress Malware Scanner: How to Detect Backdoors and Malicious PHP

Nexura Security — Tue, 08 Sep 2026 05:32:41 +0000

A WordPress website can look completely normal while malicious code is quietly running in the background.

Attackers can hide PHP backdoors inside plugins, themes, uploads directories, mu-plugins, cron jobs, or even the WordPress database. Removing the obvious malicious file is also not always enough. If a hidden backdoor remains, the attacker may simply reinfect the website.

That is why a proper WordPress malware scanner should do more than search for a few known malware signatures.

In this guide, we'll look at how WordPress malware works, how to detect suspicious PHP code, how backdoors hide, and how developers can build a layered approach to WordPress security.

What Is WordPress Malware?

WordPress malware is malicious code that has been injected into a WordPress website without the owner's authorization.

It can be used to:

Create hidden administrator accounts
Steal credentials
Redirect visitors to malicious websites
Inject SEO spam
Upload additional malware
Execute arbitrary commands
Send spam emails
Modify WordPress files
Inject malicious JavaScript
Maintain persistent access to the server

Common malware locations include:

/wp-content/plugins/ 
/wp-content/themes/ 
/wp-content/uploads/ 
/wp-content/mu-plugins/ 
/wp-includes/
/wp-admin/

Attackers may also hide malicious code inside database records, WordPress cron events, or server configuration files.

Why Malware Can Be Difficult to Detect

One of the biggest problems with malware detection is that malicious code does not always look obviously malicious.

For example, developers may encounter functions such as:

eval();
base64_decode(); 
gzinflate(); 
str_rot13(); 
assert(); 
shell_exec(); 
system(); 
passthru();

These functions are not automatically malware.

Legitimate applications can use some of them.

The problem appears when they are combined with suspicious behavior.

For example:

eval(base64_decode($payload));

This pattern deserves investigation because encoded content is being decoded and executed dynamically.

A good scanner therefore should not simply say:

"base64_decode() found = malware."

Instead, it should analyze the surrounding code and determine whether the combination of functions, variables, inputs, and execution behavior is suspicious.

Common WordPress Backdoor Techniques

1. Obfuscated PHP

Attackers frequently obfuscate malicious code to make manual inspection difficult.

For example:

$code = base64_decode('...'); eval($code);

Another example can involve compression:

eval(gzinflate(base64_decode('...')));

The goal is simple:

Malicious code
↓
Encode
↓
Compress
↓
Hide inside PHP
↓
Decode at runtime
↓
Execute

A malware scanner should therefore inspect both the visible source code and suspicious encoded payloads.

2. Variable Function Execution

Another common technique is executing a function dynamically.

For example:

$function = $_GET['action']; 
$function($_POST['data']);

This can become extremely dangerous when attacker-controlled input reaches a function that can execute code or commands.

A scanner should pay particular attention to:

$_GET
$_POST
$_REQUEST
$_COOKIE

Dynamic function calls

call_user_func()
call_user_func_array()

The important point is not that every use is malicious.

The important question is:

Can untrusted input control what the application executes?

3. PHP Files Inside the Uploads Directory

The WordPress uploads directory is another location worth checking.

For example:

/wp-content/uploads/2026/09/image.php

A PHP file inside an uploads directory can be suspicious because the directory normally stores media files such as:

.jpg
.png
.gif
.webp
.pdf
.mp4

A scanner should therefore flag unexpected executable files for manual review.

However, security tools should avoid assuming that every unusual file is automatically malicious.

False positives are a real problem in malware scanning.

4. Fake Plugins and Themes

Attackers can create plugins that look legitimate.

For example:

speed-cache-helper 
wordpress-performance-tool 
seo-optimizer 
security-update

A malicious plugin may contain a normal-looking plugin header while hiding a backdoor elsewhere in the code.

This is why checking only plugin names is not enough.

A security scanner should inspect:

Plugin files
Plugin metadata
File changes
Suspicious hooks
Remote requests
Obfuscated code
Unexpected executable files

5. WordPress Database Malware

Not every infection lives inside a PHP file.

Attackers can inject malicious content into database tables such as:

wp_options 
wp_posts 
wp_postmeta 
wp_comments

For example, malicious JavaScript may be injected into a post or option.

A database infection can be particularly difficult to notice because a traditional file-only scanner may never inspect it.

This is why modern WordPress security should consider both:

File scanning
+
Database scanning

rather than relying on only one source.

File Integrity Monitoring

Malware scanning answers one important question:

Does this code look suspicious?

File Integrity Monitoring answers another:

Did this trusted file change unexpectedly?

These are different security problems.

Imagine a clean WordPress installation.

You calculate a baseline:

plugin.php SHA-256 → ABC123...

Later, the file changes:

plugin.php
SHA-256 → XYZ789..

The hash changed.

That does not automatically mean the file is infected.

A legitimate plugin update can also change the hash.

But an unexpected modification is an important security event that should be investigated.

A simple integrity workflow looks like this:

Trusted baseline
↓
Monitor files
↓
Detect modification
↓
Compare changes
↓
Investigate
↓
Restore or approve

File integrity monitoring is especially useful after a website has already been compromised.

Malware Scanner vs Vulnerability Scanner

These two terms are often confused.

They solve different problems.

For example, a vulnerability scanner may discover that a plugin contains a known CVE.

A malware scanner may discover that the plugin file has already been modified.

You need both.

Finding a vulnerability does not prove that the site is infected.

Finding malware does not necessarily tell you which vulnerability was originally exploited.

How to Scan WordPress for Malware

If you suspect your WordPress website has been compromised, follow a structured process.

Step 1: Create a Backup

Before modifying anything, create a reliable backup.

Keep the backup separate from the compromised website if possible.

Step 2: Check WordPress Core

Compare WordPress core files against trusted versions.

Unexpected modifications to core files should be investigated.

Step 3: Scan Plugins
Check installed plugins for:

Unexpected files
Modified files
Obfuscated PHP
Suspicious remote requests
Unknown code
Outdated vulnerable versions

Do not assume that deleting one suspicious plugin completely removes an infection.

Step 4: Scan Themes

Check both the active and inactive themes.

Attackers sometimes hide backdoors inside inactive themes because site owners rarely inspect them.

Pay special attention to:

functions.php 
header.php 
footer.php 
404.php 
single.php

But do not assume these files are malicious just because they contain PHP.

Step 5: Check the Uploads Directory

Look for unexpected executable files:

wp-content/uploads/

Especially investigate PHP files that should not normally exist there.

Step 6: Review Administrator Accounts

Check:

Users → All Users

Look for:

Unknown administrators
Recently created accounts
Unexpected email addresses
Suspicious usernames

An attacker who creates a hidden administrator account may be able to regain access even after visible malware is removed.

Step 7: Review Cron Jobs
WordPress cron events can be abused for persistence.

Look for scheduled tasks that:

Download remote files
Execute suspicious PHP
Create users
Modify files
Contact unknown external servers

Step 8: Check .htaccess

A compromised .htaccess file can be used for:

Redirects
Cloaking
Malicious rewrites
Search engine spam
Request manipulation

Unexpected rules should be reviewed carefully.

Why Removing Malware Is Not Always Enough

Consider this attack chain:

Vulnerable Plugin
↓
Initial Exploit
↓
Malicious PHP Uploaded
↓
Hidden Backdoor Created
↓
Attacker Creates Persistence
↓
Visible Malware Removed
↓
Backdoor Survives
↓
Website Reinfected

This is why incident response should investigate the root cause and persistence mechanism, not just delete the first suspicious file.

Modern WordPress security tools increasingly focus on this broader problem: file scanning alone may miss database-resident malware, rogue access mechanisms, scheduled persistence, or other reinfection paths.

A Better WordPress Security Strategy
Instead of depending on a single security feature, use multiple layers.

Each layer answers a different security question.

What Should a Modern WordPress Malware Scanner Detect?

A useful scanner should look beyond simple signatures.

Important detection categories include:

PHP Backdoors

Detect suspicious code that allows attackers to execute commands or maintain access.

Obfuscated Code

Look for encoded, compressed, or heavily obfuscated payloads.

Suspicious File Changes

Compare important files against a known-good baseline.

Malicious JavaScript

Look for injected scripts, hidden iframes, and suspicious external resources.

Uploads Directory

Identify unexpected executable files.

Database Injections

Inspect relevant database content for suspicious payloads.

Cron Persistence

Review scheduled events that may download or execute malicious code.

Rogue Users

Detect unexpected administrator accounts and privilege changes.

Redirect Malware

Identify suspicious redirects and cloaking behavior.

Avoiding False Positives

One of the biggest challenges in malware scanning is false positives.

For example:

$encoded = base64_encode($data);

is not automatically malicious.

Likewise:

eval();

inside a legitimate development tool does not necessarily mean the entire website is compromised.

A good security scanner should provide:

File path
Line number
Detection reason
Severity
Detection type
Context
Review option

Instead of simply displaying:

MALWARE FOUND

a better result is:

High Risk

File:

wp-content/plugins/example/plugin.php

Line:
184

Reason:
Encoded payload is dynamically executed using eval().

Recommendation:
Review the surrounding code before removal.

This gives developers enough information to make a safe decision.

WordPress Security Should Be Layered

There is no single feature that can guarantee a WordPress website will never be hacked.

Security is a process.

A strong WordPress security strategy should include:

Regular updates
+
Vulnerability scanning
+
Malware scanning
+
File integrity monitoring
+
Secure authentication
+
WAF / request protection
+
Audit logging
+
Reliable backups

If one layer fails, another layer may detect or limit the damage.

How Nexura Security Fits Into This Approach

Nexura Security is designed around a layered WordPress security model rather than relying on a single protection mechanism.

Its security features include vulnerability scanning, security audit logs, security headers, database security checks, cron auditing, and security reporting.

The goal is simple:

Detect problems early, provide useful security information, and help WordPress administrators understand what is happening on their website.

For WordPress developers and site owners, combining vulnerability detection with malware detection, integrity monitoring, and security auditing provides a much stronger security strategy than relying on only one scanner.

WordPress Malware Detection Checklist

Before considering a compromised WordPress website clean, review the following:

☐ WordPress core checked
☐ Plugins checked
☐ Themes checked
☐ Uploads directory checked
☐ PHP files reviewed
☐ Obfuscated code investigated
☐ Database checked
☐ Cron jobs reviewed
☐ Administrator accounts reviewed
☐ .htaccess reviewed
☐ File integrity checked
☐ Vulnerabilities scanned
☐ Security logs reviewed
☐ Passwords and credentials rotated
☐ WordPress and plugins updated
☐ Clean backup verified

Final Thoughts

WordPress malware detection is more complicated than searching foreval() or base64_decode().

Attackers can hide malicious code inside files, databases, scheduled tasks, plugins, themes, and server configuration.

That is why a modern WordPress malware scanner should combine multiple detection techniques and provide enough context for developers to investigate suspicious findings.

The best security strategy is not:

Install one plugin and forget about security.

It is:

Prevent → Detect → Investigate → Recover → Monitor

When these layers work together, it becomes much harder for attackers to remain hidden and much easier for website owners to respond when something goes wrong.

## Final Thoughts

WordPress security is an ongoing process. Malware scanning can help detect suspicious code, while vulnerability scanning, file integrity monitoring, and security auditing provide additional layers of protection.

If you want to explore these security features in one WordPress security solution, take a look at Nexura Security.

👉 Learn more about Nexura Security

Keep your WordPress installation updated, monitored, and protected.

Nexura Security v1.0.11: A Smarter Vulnerability Scanner and Faster WordPress Security Architecture

Nexura Security — Wed, 26 Aug 2026 09:17:31 +0000

WordPress security is not only about blocking malicious requests.

A modern security plugin also needs to answer several important questions:

Are my plugins or themes affected by known vulnerabilities?
What security events happened on my website?
Are there suspicious scheduled tasks?
Are important security headers configured correctly?
Is my database carrying malicious or unnecessary data?
Can malware scanning run safely on shared hosting?
Can a scanner distinguish legitimate files from actual threats?

With Nexura Security v1.0.11, we focused on these areas.

This release introduces several new security modules while also improving the scanning architecture to reduce CPU usage, false positives, and unnecessary overhead.

What's New in v1.0.11?

Vulnerability Scanner

The new Vulnerability Scanner detects known CVEs affecting installed WordPress plugins and themes.

Instead of relying only on malware detection, the scanner helps identify software that may already have a publicly known security vulnerability.

This gives administrators another important layer of visibility:

Installed Plugin/Theme
↓
Version Detection
↓
Known Vulnerability Check
↓
CVE Information
↓
Security Risk Assessment

The goal is simple: find vulnerable software before attackers find it.

Nexura Security already provides security auditing capabilities for WordPress plugins and themes, and v1.0.11 expands this area with dedicated vulnerability scanning.

Security Audit Logs

Security events can be difficult to investigate without historical information.

Version 1.0.11 adds Security Audit Logs for tracking important user actions and security events.

Examples include:

Authentication-related events
Administrative actions
Security configuration changes
Important security events
Other activities that may require investigation

Audit logs can be particularly useful when troubleshooting a compromised website.

Instead of asking:

"What happened?"

you can start investigating:

"What changed, when did it change, and which action triggered it?"

Security Headers Manager

HTTP security headers are an important part of modern website hardening.

Nexura Security v1.0.11 adds a Security Headers Manager supporting:

HSTS
X-Frame-Options
Content Security Policy (CSP)
X-XSS-Protection

The objective is to make common security hardening controls easier to manage directly from WordPress.

For example:

WordPress
│
├── HSTS
├── X-Frame-Options
├── CSP
└── X-XSS-Protection
│
▼
Additional Browser-Side Protection

Headers should still be configured carefully because an overly restrictive policy can break legitimate website functionality.

Database Security & Safe Cleanup

WordPress databases can accumulate expired transients, unnecessary data, and potentially suspicious entries over time.

The new DB Security & Safe Cleanup module focuses on helping administrators maintain a cleaner database while looking for potentially malicious transients.

The important word here is safe.

Security cleanup should not blindly delete database records.

A security tool should identify what it believes is unnecessary or suspicious and allow administrators to make informed decisions.

Cron Job Auditor

WordPress scheduled tasks are useful for legitimate automation.

But they can also become interesting persistence mechanisms after a website compromise.

For example, an attacker could attempt to create a scheduled task that periodically executes unwanted activity.

The new Cron Job Auditor helps identify suspicious or hidden WordPress scheduled tasks.

A simplified security workflow looks like:

WordPress Cron Jobs
↓
Audit Scheduled Tasks
↓
Identify Suspicious Entries
↓
Review
↓
Take Action

This adds another layer of visibility for administrators investigating a potentially compromised website.

Security Score & Reporting

Security tools can generate a lot of information.

But information is only useful if administrators can understand the overall security posture of their website.

Nexura Security v1.0.11 adds Security Score & Reporting to provide a real-time view of the site's security posture.

Instead of checking every security feature individually, administrators can use the security score as a high-level indicator and then investigate individual findings.

Think of it as:

Security Score
│
├── Vulnerabilities
├── Security Headers
├── Malware Detection
├── Authentication
├── Database Security
└── Configuration

The score is designed to provide visibility, not replace detailed security analysis.

Performance Improvements

Security scanning can be expensive on shared hosting.

A scanner that consumes too much CPU can affect the entire WordPress installation.

That's why v1.0.11 includes several architectural changes.

Freemius SDK Removed

Nexura Security has completely removed the Freemius SDK from the plugin.

The result is a more independent architecture with fewer external components inside the plugin.

The focus is now on keeping the security core lightweight and focused on its primary purpose.

More Targeted Malware Signatures

Another major improvement is the reduction and targeting of cloud threat-intelligence signatures.

Instead of attempting to match an unnecessarily broad collection of patterns, the scanner focuses more heavily on targeted PHP and WordPress malware signatures.

This has two important benefits:

Faster scanning
Fewer false positives

False positives are especially problematic for security plugins.

A scanner that continuously reports legitimate files as malware creates alert fatigue and makes real threats harder to identify.

Better CPU Management for Shared Hosting

Shared hosting environments have limited CPU resources.

Running large malware scans without resource management can create unnecessary load.

Nexura Security v1.0.11 introduces a 1.5-second CPU breathing gap between scan steps.

The scanner also reduces the per-step execution time from 10 seconds to 6 seconds.

The basic idea is:

Scan
↓
Short CPU Breathing Gap
↓
Scan
↓
Short CPU Breathing Gap
↓
Scan
↓
...

This approach is designed to make background scanning more friendly to shared hosting environments.

Fewer Malware False Positives

One of the most important improvements in v1.0.11 is more precise malware detection.

The scanner no longer flags legitimate theme and plugin files simply because they contain Windows binary formats such as:

Armadillo
UPX
PE32

Domain-matching YARA rules have also been improved to reduce false positives.

The goal is not simply to detect more.

The goal is to detect better.

Improved Database and Post Content Scanning

Earlier generic cloud YARA patterns could produce large numbers of false positives when scanning database options and post content.

Version 1.0.11 changes this approach.

The database and post-content scanner now uses more targeted injection detection patterns, including indicators such as:

eval () <script> <iframe>

Rather than relying on broad generic malware patterns for every database value, the scanner focuses on indicators that are more relevant to WordPress database injection scenarios.

This significantly reduces unnecessary findings.

Stability Fix: Missing Plugin Files

WordPress administrators sometimes manually delete plugin files or remove incomplete plugin installations.

Version 1.0.11 fixes a fatal error that could occur when specific plugin files were missing or manually deleted.

Security software should be able to handle imperfect installations gracefully.

A missing file should result in a manageable security finding or scan condition—not a fatal error that takes down the process.

Safer Plugin ZIP Uploads

Another technical improvement involves malware regex patterns.

Hardcoded malware regex patterns were moved into an encoded external file.

One practical benefit is reducing the chance of cPanel ClamAV flagging the Nexura Security plugin ZIP during upload because of embedded malware-like regex patterns.

This is especially useful for hosting environments where uploaded plugin packages are automatically scanned.

Why This Release Matters

Nexura Security v1.0.11 is not just a feature update.

The release focuses on three areas:

Security Visibility

CVE detection, audit logs, cron auditing, security headers, and security reporting give administrators more visibility into their WordPress security posture.

Better Detection

More targeted malware signatures and improved database scanning help reduce false positives.

Better Performance

CPU breathing gaps, shorter scan steps, and the removal of unnecessary SDK dependencies make the scanner better suited to resource-constrained hosting environments.

What's Next?

WordPress security is continuously evolving.

New vulnerabilities appear, attackers change their techniques, and security tools need to adapt.

Our goal with Nexura Security is to build a security platform that remains:

Lightweight
Transparent
Performance-focused
Developer-friendly
Practical for shared hosting
Accessible to WordPress users

Version 1.0.11 is another step toward that goal.

Try Nexura Security

Nexura Security is available for WordPress users who want malware scanning, firewall protection, vulnerability auditing, authentication security, and other WordPress hardening features.

👉 Website: https://nexurasecurity.com/

👉 WordPress.org: https://wordpress.org/plugins/nexura-security/

If you're a WordPress developer, security researcher, or website administrator, we'd love to hear your feedback.

What security feature would you like to see in the next release?

WordPress #WordPressSecurity #CyberSecurity #WebSecurity #MalwareScanner #VulnerabilityScanner #CVE #PHP #WebDevelopment

Stop Attacks Before Your App Boots: Building an Early-Load WAF in PHP

Nexura Security — Wed, 15 Jul 2026 04:41:56 +0000

If you are building web applications in PHP, whether it's a custom Laravel app or a WordPress plugin, security is always a top priority. But when that security executes is just as important as what it does.

Most application-level firewalls make a critical mistake: they load too late.

Today, I want to share a technical dive into how we solved this problem when building Nexura Security, and how you can use PHP's native features to build an early-load Web Application Firewall (WAF).

The "Late Execution" Problem
Let's take WordPress as an example. A typical security plugin initializes its firewall via a hook (like plugins_loaded or init).

Think about what has already happened on the server by the time that hook fires:

The web server (Nginx/Apache) received the request.
PHP started up.
Database connections were established.
Hundreds of core PHP files were parsed and loaded.
The active theme and other plugins were initialized.
If a malicious bot sends a massive SQL Injection payload, your server is wasting CPU and memory parsing the entire application architecture just to tell the bot "No" at the very end. During a DDoS or brute-force attack, this late execution is exactly what brings servers down.

The Solution: auto_prepend_file
PHP has a brilliant, often-underutilized directive in its php.ini configuration called auto_prepend_file.

When configured, PHP will execute the specified file before executing the main script requested by the user. It happens at the absolute beginning of the PHP lifecycle, before database connections, before frameworks, and before any heavy lifting.

If you block a malicious payload here, the server resource cost is practically zero.

How We Implemented It in Nexura Security
When architecting Nexura Security, we knew we didn't want to be just another plugin that slows down the site. We wanted to intercept traffic at the server level.

Here is a simplified breakdown of how an early-load WAF works:

The Setup (Setting the Directive) We programmatically add the directive to the server configuration (e.g., .htaccess or .user.ini):

# In .htaccess <IfModule mod_php7.c> php_value auto_prepend_file "/absolute/path/to/nexura-waf.php" </IfModule>

The WAF Logic (nexura-waf.php) This file is intentionally kept incredibly lightweight. It does not connect to the database. It does not load large classes. It simply inspects the incoming superglobals ($_GET, $_POST, $_SERVER, $_COOKIE) against a set of known malicious patterns.

<?php
// Extremely simplified conceptual example
function nexura_inspect_request() {
    $payload = file_get_contents('php://input') . print_r($_GET, true) . print_r($_SERVER, true);

    // Check for obvious SQLi patterns
    $sql_patterns = '/(UNION\s+SELECT|CONCAT\(|WAITFOR\s+DELAY)/i';

    if (preg_match($sql_patterns, $payload)) {
        // Block the request immediately!
        header('HTTP/1.1 403 Forbidden');
        die('Blocked by Nexura Security WAF.');
    }
}

nexura_inspect_request();
// If it passes, PHP naturally continues to load the main app (e.g., index.php)
?>

The Performance Impact is Massive
By moving the firewall logic to the auto_prepend_file stage, we achieved a zero performance hit on the actual application load time.

If a request is legitimate, the WAF inspection takes less than 1 millisecond and hands the request over to WordPress. If the request is malicious, it gets blocked instantly, saving the server from executing a single database query.

Conclusion
Application security shouldn't be an afterthought that runs at the end of your boot cycle. By leveraging PHP's low-level directives, you can protect your applications efficiently.

We built Nexura Security entirely around this philosophy—combining this early-load WAF with flat-file logging (to prevent database bloat) and a micro-batching malware scanner.

If you're a developer managing WordPress sites, I’d love for you to test out our architecture and let me know your technical feedback!

Have you ever used auto_prepend_file for security or logging? Let's discuss in the comments!

How We Built a Zero-Bloat WP Security Plugin published: true tags: wordpress, php, webdev, security

Nexura Security — Tue, 14 Jul 2026 08:49:47 +0000

If you've ever managed a WordPress site, you already know the drill. You install a popular security plugin to keep the bad guys out. A few weeks later, your wp-admin dashboard feels sluggish, your CPU usage spikes randomly, and your database size has mysteriously doubled.

As a developer, this drove me crazy. Security shouldn't come at the cost of performance.

So, my team and I decided to look under the hood of popular security plugins to see why they were so heavy, and we built Nexura Security to solve these exact problems.

Here is what we found, and how we engineered a different approach.

Problem 1: The wp_options Database Bloat
Most security plugins log everything directly into the WordPress database. Every failed login attempt, every blocked 404 request, every minor crawler—it all gets stuffed into your database, often bloating the wp_options table or creating massive custom tables.

Our Fix: Zero Database Bloat We architected Nexura to keep the database completely clean. Instead of spamming the database with transient logs that bring sites to a crawl, we optimized how and where logs are stored. The result? A completely snappy backend, even on sites that are under constant bot attacks.

Problem 2: Late Execution WAFs
A Web Application Firewall (WAF) is supposed to block malicious requests. However, many plugins initialize their WAF after WordPress core, plugins, and the active theme have already loaded. By the time the WAF blocks the SQL injection, the server has already wasted CPU and memory processing 80% of the request.

Our Fix: Early-Load WAF (auto_prepend_file) We implemented an early-load WAF that hooks in before WordPress even starts. By utilizing PHP's auto_prepend_file directive, Nexura intercepts and inspects requests at the server level. If a request contains a malicious payload, it is blocked instantly with near-zero resource consumption.

Problem 3: Server-Crashing Malware Scanners
Scanning 10,000+ files for malware in a single PHP execution is a guaranteed way to trigger a 504 Gateway Timeout or spike your hosting CPU to 100%. Traditional plugins often run heavy regex searches across the entire filesystem at once.

Our Fix: Smart Micro-Batching Scanner We wrote a custom micro-batching algorithm. Instead of trying to scan everything at once, Nexura breaks the scanning process into tiny, lightweight chunks. It scans a few files, pauses, and resumes. This keeps the server load practically non-existent. You can run a full malware scan while users are actively shopping on your WooCommerce store, and they won't feel a thing.

Security Should Be Invisible
Building Nexura Security taught us that the best security is the kind you don't even notice. Your dashboard stays fast, your database stays small, and your server breathes easy.

We recently launched, and the response from the community has been amazing (especially regarding the zero-database-bloat!).

It includes the WAF, Malware Scanner, 2FA, and Brute-force protection out of the box.

If you are a developer managing WordPress sites, I would absolutely love to hear your technical feedback.

You can check it out here: nexurasecurity.com

Let me know what you think in the comments! 🚀