But underneath, a different scenario may exist—a theme or some functionality was installed haphazardly, without a clear history of its origins or guarantees of code integrity. That's when a security audit becomes not a formality but a necessity. When a wordpress nulled issue surfaces in a project, it's important not to argue about the motives, but to conduct a sober investigation: understand the current risks, document the system's state, and determine what exactly needs to be cleaned, restored, or rebuilt.

How to think about auditing in such a situation

The main mistake is trying to "guess" where the problem is and then fix the symptoms selectively. The correct approach is to treat the installation of untested code as a potential source of compromise and check the entire system: the file system, database, update chain, users, keys, permissions, logs, and external integrations. The audit should answer three questions: are there any signs of intrusion, where exactly the suspicious code has become entrenched, and what needs to be done to prevent the situation from recurring after the fixes are in place.

Preparing for a test without the risk of breaking your live site

Before any action, it's worth capturing the initial state. Ideally, the audit is performed on a copy: a backup is taken, staging is deployed, and then comparisons, cleanups, and experiments are performed there. If there's no staging, then at a minimum, a careful diagnostic without deleting files "in place" is enough to avoid erasing traces and causing instability.

It's important to immediately determine where the project's "truth" resides: is there access to the hosting panel, SSH, database, web server logs, and backup tools? If access is lacking, the checklist becomes a guess, so access restrictions should be recorded as a risk and part of the audit findings.

Backup Before Audit: What Exactly to Save

A backup shouldn't be "just in case," but rather suitable for recovery and investigation. Typically, two layers are needed: a full snapshot of the site's file system and a database dump, created to preserve the date/time stamp and structure. It's also useful to save environment configurations that are often missed in regular backups: web server settings, .htaccess or nginx configurations, PHP configurations, WAF rules, cron jobs, and a list of installed packages and versions if the site is running in a container or on a VPS.

It's especially valuable to save logs for at least the last 30-90 days, if they exist and aren't rotated too aggressively. Logs are needed not only for attack detection but also to verify the integrity of the patches.

Inventory: What to Describe Before a Deep Dive

A good audit begins with a website "passport" review: WordPress version, active theme, plugin list, availability of MU-plugins, auto-update status, caching scheme, CDN availability, authentication methods, whether the REST API is enabled, whether XML-RPC is used, what integrations are associated with the site (mail, payments, CRM, external forms). This isn't a list for the sake of a list: any item could be a source of entry for malicious code or a hiding place.

File System Check: Where Are Bookmarks Most Often Hidden?

The first thing to look at is everything that's being executed and everything that can modify executable code. In WordPress, this includes the core, plugins, themes, MU-plugins, the uploads directory (which shouldn't contain executable PHP files), as well as temporary directories and caches.

In practice, files with recent modification dates are suspicious, especially if they haven't been updated. Also dangerous are names that "look like system files": files masquerading as wp-include/something similar, extra PHP files in the root directory, duplicates with extensions like .php5, .phtml, .inc, .bak, strange .ico/.png files that actually contain code, and large obfuscated blocks with base64, gzinflate, str_rot13, eval, and similar constructs.

Pay special attention to wp-config.php and everything around it. It may contain key substitutions, remote file inclusions, update constant overrides, non-standard paths, and insertions that are not noticeable at a glance.

Comparing WordPress core with the benchmark

Having access to the command line and WP-CLI makes life easier: you can check the core's integrity using built-in mechanisms and then carefully reinstall a "clean" core over it, leaving wp-content intact. Even without WP-CLI, the logic remains the same: the core must match the official version, and any differences must have a clear origin.

The presence of modified files in wp-admin and wp-includes is almost always a warning sign. Normally, you don't edit the core manually, and if you do, it should be documented and explained.

Plugins and Themes: How to Distinguish “Functionality” from Implementation

With plugins and themes, the most important thing is their origin and version control. If the code was installed from an unknown archive, it could contain "additional features" unrelated to the intended function. You need to check for hidden access "managers," remote calls, suspicious files in subfolders, autoloading of external scripts from unknown domains, and constructs that include code with every request.

A separate risk area is MU plugins and "additional" include files that are loaded from a theme's functions.php or via a custom "core plugin." These elements can be very convenient for a developer, but they are also very convenient for an attacker, because they are rarely checked and are always loaded.

The Uploads and Media Directory: A Place Where Rules Are Often Violated

By default, uploads should store images, documents, and caches, but not executable code. If PHP files are found there, it's almost always either a configuration error or the result of an attack. Even if a file appears to be "service-related," it could be a web shell.

It's also worth checking whether PHP execution is enabled in uploads at the web server level. Sometimes this is "accidentally" enabled by .htaccess rules or the nginx configuration, and then any file upload vulnerability turns into remote code execution.

Database: What to Look for in Content and Settings

There are several common locations in the database where malicious insertions are embedded. These include site options (wp_options), especially those related to autoloading, active plugin settings, siteurl/home, and any custom options that appear as random strings.

The second zone is content: posts, pages, widgets, block templates, and custom HTML blocks. This may contain hidden scripts, redirects, "invisible" links, and footer and header embeds. Widgets and global blocks, which are shared across all pages, deserve special attention.

The third zone is users and permissions. It's important to understand who has administrator access, whether there are any "extra" accounts, strange email addresses, and whether roles have been changed. If you have a multisite, checking becomes more complicated: network settings and roles are added at the network level.

Logs and telemetry: how to see the big picture

Without logs, you only see a snapshot of the current state, but with logs, you see the history. Web server access/error logs, PHP logs, WordPress logs (if enabled), and WAF/Firewall logs, if present, are useful. It's important to look for not only obvious login attempts in the logs but also anomalies: unknown POST requests to strange endpoints, file accesses in uploads, mass requests to wp-admin/admin-ajax.php, non-standard user agents, spikes in 404 responses to "possible webshells," accesses to wp-config.php or backups (zip/sql), and attempts to brute-force xmlrpc.php.

If there are no logs, or if they are stored for too short a time, this is also a result of the audit: the lack of observability is a separate risk that needs to be corrected, otherwise you will not be able to confidently confirm that the site has been “cleaned up.”

WordPress Security Settings: What to Check in the Configuration and Environment

Important things are usually hidden in settings that aren't visible in the admin panel. These include setting the correct file and directory permissions, disabling write access to inappropriate locations, disabling the file editor in the admin panel, restricting access to wp-admin, using the correct SALT keys, ensuring a secure PHP configuration, up-to-date PHP, and disabling dangerous functions where possible.

It's worth checking how your updates are configured. If a site is afraid to update because of "non-standard" themes or plugins, this in itself increases the risk. Without regular updates, any known vulnerability becomes a "permanent door."

Action plan in case of confirmed compromise

If you find clear signs of infiltration, the goal becomes not just "cleaning up the file," but restoring a trusted environment. This typically involves replacing the kernel with a clean one, replacing suspicious themes/plugins with trusted versions, checking uploads and deleting executable files, resetting all passwords and keys, recreating integration secrets, and auditing cron jobs and background processes.

It's important to remember that a common scenario is reinfection due to a retained entry point. You can clean up a site and see the same thing a day later if the initial vector isn't closed: a vulnerable plugin, a weak password, an open xmlrpc, PHP allowed in uploads, an FTP key leak, or an infected workstation.

How to record audit results so that they are useful

The audit result isn't a "everything is fine/everything is bad" statement, but a documented picture: what was checked, what was found, how critical it is, what evidence exists, and what actions are recommended. It's important to record versions, hashes/checksums of suspicious files, modification dates, log fragments, signs of obfuscation, associated domains, request chains, and audit limitations (e.g., "no access to logs," "no SSH," "no deployment history").

A good format is for any other specialist to be able to repeat the review based on your report and reach the same conclusions. This is especially important if you need to discuss responsibility, support, and future update strategy with the client.

What constitutes the “end of audit” and how to confirm stability after fixes

An audit ends not when a suspicious file is deleted, but when you can confidently say the environment is in a manageable state. This means: updates are working, the source code is clear, logs are collected, access permissions are reviewed, backups are configured, file permissions are correct, and basic anomaly monitoring is in place.

After making the fixes, it's helpful to monitor the site for a while: check the logs for retries, monitor file changes, and look for new administrators and unexpected redirects. If everything is done correctly, the "oddities" will stop, and the site will become predictable and maintainable.

Calm communication with the team and the client as part of security

Technical audits almost always rely on communication. It's important not to turn the discussion into accusations, but to stick to the facts: the risk doesn't stem from "bad people," but from the lack of a trust chain for the code and the inability to guarantee its security. Good communication emphasizes a simple message: "We don't evaluate installation motives; we bring the project to a state where updates and security are controlled."

When you present your findings clearly and offer a clear recovery plan, the risk conversation becomes constructive: it's no longer a debate over terminology, but a managed effort to reduce vulnerabilities and protect the business.

If you'd like, I can write a follow-up to this article in the same style: how to create a "project passport" after an audit and how to specify in agreements who is responsible for what during updates and incidents—also without lists, but with subheadings.