Audit My Site Get Started

Category: Security

  • How Do You Check If Your Website Is Secure?

    How Do You Check If Your Website Is Secure?

    Contents

    1. 01
      Understand what each check actually tells you

      The short answerHow it actually works

    2. 02
      Run the checks

      What good looks likeWhat to do about it

    3. 03
      Know what still isn’t covered

      Common misconceptionsWhat this does not solve

    The short answer

    Checking whether a website is secure means running four separate signals, not one. Each covers a different layer, and a clean result on any one of them is not a clean bill of health for the other three.

    Signal What it checks What it misses
    Google Safe Browsing status
    		Whether Google’s crawler classified the URL as malware, phishing, unwanted software or deceptive content on a recent pass Anything injected since that pass, or anything on a page the crawler never reached
    Blacklist (DNSBL) check
    		Whether the domain or IP has been reported to a third-party list such as Spamhaus or Barracuda A fresh compromise nobody has reported yet
    Certificate validity (the padlock)
    		That the connection is encrypted and that whoever requested the certificate controlled the server at issuance Patched software, server-side validation, or malware already on the site
    File-level malware and vulnerability scan
    		The actual files and database for injected code, plus installed versions against known disclosures Nothing, but it is the one check none of the URL-only tools can run
    The four checks that make up a website security check, and what each one covers.

    How it actually works

    Google Safe Browsing

    Google’s Safe Browsing technology scans its own web index daily. As Google puts it, “Our Safe Browsing technology scans our web index on a daily basis to identify unsafe websites.” A URL that turns up gets classified as malware, phishing, unwanted software or deceptive content. Malware detection works by scanning sections of the index and testing pages in a virtual machine to see if it gets infected. Phishing detection runs on statistical models instead.

    Once a site is flagged, the warning is added within minutes of detection, and it takes about half an hour on average to show up externally. That speed cuts both ways.

    Catches

    A site that was actively serving bad content at its last crawl.

    Misses

    Anything injected after that crawl, anything on a page the crawler never reached (behind a login, or blocked by robots.txt), and a vulnerable plugin sitting on the site that nobody has exploited yet.

    Run the lookup directly at Google’s Safe Browsing site-status tool, and read how the scan actually works in Google’s Safe Browsing transparency FAQ. For the fuller process this single check feeds into, see the fuller checklist this feeds into.

    Blacklist and DNSBL checks

    A blacklist check is a DNS lookup, cross-referenced against third-party lists such as Spamhaus, Barracuda or SORBS. Each list sets its own listing criteria. A clean result here means the domain or IP has not been reported yet, not that the underlying code is clean. It also misses a site that was compromised recently and hasn’t been reported, and it can produce a false positive on shared hosting, where one bad neighbor gets an entire IP block listed.

    The padlock and certificate

    A valid certificate confirms two things only: the connection between browser and server is encrypted, and whoever requested the certificate had administrative access to the server at the moment it was issued. It does not confirm the software behind that connection is patched, that server-side validation is sound, or that the site is free of malware.

    Free certificate issuance changed what the padlock actually signals. A phishing site can get the same valid HTTPS certificate a legitimate business gets, and vendor reporting on phishing incidents has noted that most reported phishing sites now carry a valid certificate too.

    Read the padlock correctly

    Treat the padlock as confirmation of encryption, never as confirmation of safety.

    Malware and vulnerability scanning

    This is the layer the first three checks cannot touch, because it requires looking at the site’s own files rather than at how the outside world sees the domain. A malware scan inspects the files and database for injected code, unexpected admin accounts and altered core files. A vulnerability check compares the installed versions of core, themes and plugins against public disclosure databases such as WPScan’s.

    Both require server-side access or a direct look at the codebase. A URL-only checker run from outside the site cannot do either.

    Where the free checks stop

    External reputation
    • Safe Browsing
    • Blacklist
    • Certificate

    Requires file-system access

    Requires file-system access

    On the server
    • Malware scan
    • Vulnerability check

    A diagram showing the boundary between external reputation checks and a file-level security scan.

    External reputation and file-level access are two different zones. Safe Browsing, blacklist status and the certificate all judge the site from outside. A malware scan and a vulnerability check are the only ones that look at what is actually sitting on the server.

    What good looks like

    A genuinely clean result means all four signals come back clear at once:

    No Safe Browsing flag
    No blacklist listing
    A valid certificate with no mixed-content warnings
    A file-level scan that turns up no injected code and no versions matching a known disclosure

    One green result out of four is a start, not a finish. It tells you one layer looks fine today. It says nothing about the other three.

    What to do about it

    1. 01

      Run the Google Safe Browsing site-status lookup directly against the domain.

    2. 02

      Run a blacklist (DNSBL) checker against the domain to see if it appears on Spamhaus, Barracuda or a similar list.

    3. 03

      Check the certificate’s validity in the browser, and look in the browser console for mixed-content warnings on pages that should be fully encrypted.

    4. 04

      Run a malware and vulnerability scan, either through a security plugin with file-system access or through a fuller audit.

    Each of these is a snapshot, not a standing guarantee, so the useful habit is running all four again after any change to the site, not just once after a scare.

    Get the layer those four checks can’t see.

    NoDrama’s free website audit checks the site’s actual files and versions, no pitch attached.

    Audit My Site

    Common misconceptions

    “HTTPS means the site is safe.”

    It confirms encryption in transit and that someone controlled the server when the certificate was issued. That’s all it confirms.

    “A clean Safe Browsing result means nothing is wrong.”

    It reflects only what Google’s crawler has seen so far, and that can lag behind a fresh infection by hours or days.

    “A security plugin covers all of this.”

    A plugin scans what it has file-system access to. Reputation flags such as Safe Browsing and blacklist status are external judgments, and a local plugin cannot see or clear them.

    What this does not solve

    None of the four checks above replace an ongoing, operated security practice: updates tested before they go live, monitoring that runs continuously rather than once, and a documented process someone actually follows. A clean result across all four today answers only “as of today.” For how the security work is scoped, see how the security work is scoped, and for who actually watches this after today, see who actually watches this after today.

    Conclusion

    Checking whether a website is secure is four separate signals, not one: Google Safe Browsing status, blacklist status, certificate validity, and a file-level malware and vulnerability scan. Each one is narrow, each one misses what the other three catch, and the only honest answer to “is my site secure” comes from running all four rather than trusting whichever one came back clean first.

  • How Do I Know If My WordPress Site Is Hacked?

    How Do I Know If My WordPress Site Is Hacked?

    Contents

    1. 01
      Work out what you’re looking atWhat a hacked site looks like
    2. 02
      Check the five signs

      The five signsHack vs. broken

    3. 03
      Act, and stop it recurring

      What to do once you’re sureTroubleshootingStop it happening againWhat this doesn’t solveIs your site hacked?

    What does a hacked WordPress site look like?

    Google’s own definition: “This is any content placed on your site without your permission because of security vulnerabilities in your site.” Three common ways in: a vulnerable plugin, weak credentials, or an outdated core file with write access.

    The usual motive is SEO spam or redirects, via cloaking: the real site loads for a logged-in admin, and a different, injected page loads for Googlebot or a search visitor. “It looks fine to me” is not a clean bill of health, since that’s exactly what this hack is built to show.

    See whether WordPress itself is the weak point for that separate question.

    How to confirm the site is compromised (the five signs of a compromised website)

    Five signs checklistAny one of these holding is enough to act on
    1. 01 Google or browser warning
    2. 02 Pages you never published in search
    3. 03 Redirects to another site
    4. 04 Unknown admin users or files
    5. 05 Host suspension or abuse notice
    Five signs a WordPress site has been hacked, shown as a checklist.

    Each sign has its own cause and check; none needs developer skill.

    1. Google or your browser warns people away

    Google’s Search Console help: “Pages or sites affected by a security issue can appear with a warning label in search results or an interstitial warning page in the browser when a user tries to visit them.” This shows as “This site may be hacked” in search, or a warning in Chrome, under Hacked Content, Malware and Unwanted Software, or Social Engineering.

    Verify it

    Open Security Issues in Search Console (site must be verified there). Green “no issues” clears this; anything listed does not. See Google’s Security Issues help.

    Google’s Security Issues help

    2. Search results show pages you never published

    Injected spam: pharmacy, gambling or foreign-language pages, often served only to Googlebot.

    Verify it

    Search site:yourdomain.com in a logged-out incognito window and scan titles and snippets for anything that matches nothing in your CMS.

    3. Visitors get sent to another site

    Injected JavaScript, or a modified .htaccess or functions.php file, often triggers only on referrer or device, so a direct visit looks fine. Wordfence documented a 2019 campaign exploiting vulnerable plugins to inject this code.

    Verify it

    Visit the site logged out, in incognito, arriving from search rather than typed, and once more from a phone on a different network.

    Wordfence’s 2019 write-up

    4. Admin users or files appear that nobody created

    This sign is the foothold: a new admin account, an extra file in wp-content or plugins, or an edited core file lets an attacker return after cleanup. wordpress.org’s checklist includes unauthorised new users.

    Verify it

    Open Users, filter by Administrator, and match every account to a named person. Ask a developer to check file-modification dates in wp-content and core.

    wordpress.org’s FAQ on a hacked site

    5. Your host suspends the site or reports abuse

    Hosts run their own malware and abuse scanners, independent of Google. A suspension, or a report the site is sending spam or attacking others, can arrive before, or without, a Google flag.

    Verify it

    Check host email and the control panel for a suspension notice or an abuse report.

    When it looks like a hack but isn’t

    A broken plugin update, an expired SSL certificate, a stale cached page, or a host outage can look alarming and match none of the five signs above. If Security Issues is clean, admin accounts belong to the team, and the host hasn’t flagged anything, the read is broken, not hacked: roll back, renew, or contact the host. An SSL warning or outage doesn’t need a forensic audit.

    What you see Points to a hack Points to broken
    Search Console Security Issues An issue is listed Green “no issues”
    Unknown admin users An account nobody can name Every account belongs to the team
    Host abuse notice Suspension or abuse report received Host hasn’t flagged anything
    SSL warning only — Expired certificate: renew it
    Error after an update — Broken plugin update: roll back
    Stale cached page — Cache serving an old version
    Table comparing signs of a compromised website with ordinary WordPress failures.

    See how tested updates and rollback are handled.

    What to do once you’re sure

    wordpress.org’s first steps: stay calm, document what you found, and scan.

    Option 1Recommended

    Easiest: tell your host and follow wordpress.org’s first steps

    Your host runs its own scanners and may already know. Follow wordpress.org’s guidance from there.

    Option 2

    Done for you: hand it to whoever runs security for the site

    A retainer with monitoring and backups already running means some of these signs can be caught before you notice them.

    Option 3

    Manual: restore from a clean backup and close the foothold

    Restore to a known-clean point before the first sign appeared: the older the sign, the further back. Remove admin accounts nobody can name, and have a developer compare files against a clean copy. See how off-site backups and restores work.

    Verify it

    Re-run all five checks: Security Issues clean, site: search clean, incognito visit from search and mobile clean, Users list matches named people, no host notice.

    Troubleshooting

    “Google says this site may be hacked, but Search Console shows no security problems”

    Cloaking can explain the mismatch: the spam goes to Googlebot and search visitors, not you. Run the site: search and incognito check rather than trusting either alone.

    “My security plugin says everything is clean”

    A scanner reports what it was configured to catch; silence isn’t proof of more. Cross-check against the signs above.

    How to stop it happening again

    Turn the causes above into a routine: tested updates, admin accounts reviewed, monitoring and scanning running, and off-site backups you could restore from tomorrow. The monthly check is the five-sign list. See the site’s state now with NoDrama’s free WordPress audit.

    See what a security retainer covers.

    NoDrama’s WordPress security retainer runs security monitoring and malware scanning on every plan, which can catch some of these signs before you do, and keeps off-site backups to restore from if one turns up.

    See Security Work

    What this guide does not solve

    It doesn’t cover a full malware cleanup, a forensic investigation, or how a specific attacker got in. A site handling payments or client data also has obligations this guide doesn’t cover.

    So, is your WordPress site hacked?

    Five signs settle it: a Google or browser warning, unpublished pages in search, a redirect elsewhere, an unrecognised admin account or file, or a host suspension. None depend on how the dashboard looks while logged in; the checks happen outside it. If none hold, the read is broken, not hacked, or fine.

  • WordPress Security Hardening: What It Is and What It Actually Covers

    WordPress Security Hardening: What It Is and What It Actually Covers

    What this guide covers

    1. 01Understand what hardening is made of
    2. 02Sort the current advice from the stale advice
    3. 03Decide what you will run

    The short answer, and where hardening lives

    Hardening is configuration, not detection. A firewall and a malware scanner watch for something happening. Hardening removes the path it would happen down in the first place.

    Six categories make up the stack: patching, file and database permissions, administrative surface, response headers, obscurity measures, and the operational layer that keeps the rest true after a release goes out. Patching lives at the plugin, theme and core level. Permissions live on the server and in the database. The file editor and two-factor authentication live on the admin screens, and response headers get sent by the server or a proxy. A plugin cannot set a file permission or send a header the way a server configuration can.

    Six layers, three places they live
    A plugin reaches only the WordPress band

    Server

    • File and directory permissions
    • Response headers
    • wp-config.php protection

    Database

    • Reduced database privileges
    • Authentication keys and salts

    WordPress

    • File editor disabled
    • Two-factor authentication
    Update cadence spans all three bands: it is what keeps the rest of this true after a release goes out.

    No figures needed here. This is a grouping of measures by where each is configured, not a severity ranking.

    Diagram showing WordPress hardening measures grouped by where each one is configured.

    Read what ongoing WordPress security work covers once you know which of the six you actually own.

    Verification step

    List which of the six categories you can currently point at a real setting for, not a plugin dashboard toggle. The ones you cannot name are the gap this piece is about.

    How the layers actually work

    Three controls, in the order this section covers them

    File permissions
    Directories 755/750, files 644/640, wp-config.php 440/400 on suexec

    File editor disabled
    One line in wp-config.php closes the in-browser edit path

    Database and keys
    Reduced privileges, rotatable authentication keys and salts
    Diagram summarising the three controls covered in this section: file permissions, the file editor, and database privileges and keys.

    File and directory permissions

    WordPress core, wp-admin and wp-includes should be writable only by your user account. wp-content is the exception, since plugins, themes, uploads and cache write there. The handbook gives permissions as ranges, not one number: directories at 755 or 750, files at 644 or 640, and wp-config.php at 440 or 400 on a suexec setup.

    Which number is correct depends on your host. On suexec or PHP-FPM, the PHP process runs as the file owner and can use the tighter number; on a shared mod_php setup, the web server’s own user needs write access, so the same tight number breaks the site. wp-config.php gets the strictest rule, holding the database credentials and the four secret authentication keys, and the handbook calls a default 644 permission on it a hazard.

    The file editor, and why it goes first

    Setting DISALLOW_FILE_EDIT to true in wp-config.php removes the plugin and theme editor from wp-admin, equivalent to removing the edit_themes, edit_plugins and edit_files capabilities from every user. Without it, an attacker holding an admin session can paste a PHP web shell straight into a theme file through the browser, no upload needed. Removing the editor closes that path.

    Database privileges and authentication keys

    Day to day, WordPress needs only SELECT, INSERT, UPDATE and DELETE from its database user. DROP, ALTER and GRANT can be revoked without breaking anything WordPress normally does, so an injection flaw in an unpatched plugin cannot drop a table or create a privileged user, even if it succeeds.

    The keys and salts sign your authentication cookies. If they are weak, default or leaked, someone holding them can forge a valid login cookie without your password, and rotating them ends every logged in session at once, the fastest way to remove a session you do not control.

    Read the three plans and what each covers if you’d rather have someone else run this. See the three plans.

    Verification step

    After each change, load the site, log in, upload a media file and save a post. Those four actions confirm permissions, sessions and write access at once, so you know within a minute whether the tighter setting broke something.

    Security headers, including the one to stop maintaining

    The headers worth setting

    • Content-Security-Policy tells the browser which sources may load or execute. A policy that disallows unsafe-inline means an injected script tag does not run.
    • X-Frame-Options stops the page loading inside a frame on another domain, the mechanism behind clickjacking.
    • X-Content-Type-Options: nosniff stops the browser guessing a file’s type instead of trusting the declared type.
    • Strict-Transport-Security tells the browser to only connect over HTTPS for the stated period.
    • Referrer-Policy and Permissions-Policy limit what leaks to other origins and which browser features a page may use.

    X-XSS-Protection, and why guides still list it

    MDN, the reference most browser vendors defer to, marks this header both deprecated and non-standard. It “was a feature of Internet Explorer, Chrome and Safari that stopped pages from loading when they detected reflected cross-site scripting (XSS) attacks.” Chrome and Edge have since removed the XSS auditor the header controlled, so setting it today changes nothing.

    MDN’s own guidance is direct: “it is recommended that you use Content-Security-Policy instead of XSS filtering.” It warns that in some cases the header “can create XSS vulnerabilities in otherwise safe websites,” which makes it a header that can work against you.

    The honest answer to what people are searching for is this. Do not tune this header. Retire it, and put the effort into Content-Security-Policy, which is harder to get right and is the one doing the actual work.

    Header What it does Status
    Content-Security-Policy Tells the browser which sources may load or execute Set it, does the actual work
    X-Frame-Options Stops the page loading inside a frame on another domain Set it, stops clickjacking
    X-Content-Type-Options Stops the browser guessing a file’s type instead of trusting the declared type Set it, stops MIME sniffing
    Strict-Transport-Security Tells the browser to only connect over HTTPS for a stated period Set it, forces HTTPS
    Referrer-Policy Limits what leaks to other origins on navigation Set it, limits leakage
    Permissions-Policy Limits which browser features a page may use Set it, limits feature access
    X-XSS-Protection Once stopped some browsers loading pages with detected reflected XSS Deprecated per MDN, retire it

    Status described in words, not header syntax to copy. No HSTS max-age value shown, since that number is sourced only to a secondary vendor article.

    Chart of WordPress security response headers with the deprecated X-XSS-Protection marked.

    Read about how response headers and caching are handled for performance if headers are new territory for you.

    Verification step

    Request your own home page and read the response headers back. Then check a page that loads a third party script or embed, since a policy that passes cleanly on the home page often blocks something the moment an embed is involved.

    What good looks like

    The configuration is set, and somebody can say when each item was last checked. Updates are applied on a schedule, tested before going live, and reversible if one breaks something. That is ordinary practice offered by several providers, not something unique to any one of them. The plugin inventory is short, and every item on it is still maintained upstream.

    Patchstack, a vendor that sells a vulnerability monitoring product, published figures worth reading with that in mind:

    Layer Share of 2025 disclosures
    Plugins Roughly 91 percent
    Themes Roughly 9 percent
    Core 6 vulnerabilities, out of 11,334 total
    Table showing that most WordPress vulnerabilities disclosed in 2025 were in plugins. 11,334 total disclosures, a 42 percent increase on 2024. Shares are rounded. All figures from Patchstack, a vendor with a commercial interest in this figure, not an independent survey.

    Read how updates get tested before they go live once you know the plugin layer is where the exposure actually sits.

    Verification step

    Pick the three most recently updated plugins on your site and find out who applied each update and whether anything was checked afterward. If you cannot answer either question, that is the gap.

    What to do about it

    In order of what returns most for the effort:

    01

    Audit your plugins and themes and remove what is not used.

    02

    Disable the file editor, one line in wp-config.php.

    03

    Tighten wp-config.php permissions, then the directories, testing after each.

    04

    Set the current header set, and remove X-XSS-Protection if it is there.

    05

    Reduce the database user’s privileges and rotate the keys.

    06

    Decide who applies and tests updates, and on what cadence.

    Verification step

    After each change above, run the same four checks from the permissions section again: load the site, log in, upload a media file, save a post. A hardening change you cannot confirm is a change you are trusting rather than one you have made.

    Would rather not run this list yourself?

    See what hardening is included in NoDrama’s WordPress security retainer.

    See Security Work

    Common misconceptions

    “A security plugin is hardening.”

    It firewalls, scans and limits login attempts: detection, not configuration.

    “Changing the table prefix and admin username secures the site.”

    The handbook frames this as obscurity, stopping scripted attacks rather than a targeted one. Cheap and worth doing, not a defense on its own.

    “Core updates are the priority.”

    6 of the 11,334 vulnerabilities disclosed in 2025 were in core, and core auto-updates already cover most of that.

    “My host handles security.”

    Hosting-level protection is a different layer from the application-level configuration described here.

    What this does not cover

    The exact permission numbers for your host, which depend on how it runs PHP. Writing a Content-Security-Policy for your specific third party scripts. Incident response and cleanup after a compromise. And no formal certification: hardening supports compliance work, not a compliant status.

    Where this leaves your site

    Hardening is a stack of configuration changes, most of it living outside WordPress itself: the server, the database, the response headers. It holds only as long as somebody keeps patching the layer where the vulnerabilities actually are, plugins rather than core.

  • What Are the Security Risks of WordPress?

    What Are the Security Risks of WordPress?

    Contents

    1. 01Understand where the risk actually sits. The short answer, and how it actually works.
    2. 02See why it matters for your site. Why it matters for your situation, and what good security discipline looks like.
    3. 03Know what to do and what still isn’t covered. What to do about it, and the common misconceptions.

    The short answer on WordPress security risks

    Of 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025, 91 percent were found in plugins, 9 percent in themes, and only 6 low-priority issues were in core, per Patchstack’s 2026 State of WordPress Security whitepaper. That split is not close. Core’s share is statistically negligible against plugins alone.

    The direct implication follows from the numbers, not from opinion: WordPress the platform is not where the risk sits. The unaudited third-party code running on top of it, chosen and installed by whoever manages the site, is.

    How WordPress security risk actually works

    Why plugins and themes carry the risk core does not

    Core ships from a single, reviewed codebase. It’s maintained by a security team of more than 50 people who backport fixes to older versions rather than forcing every site onto the newest release to stay patched, per the WordPress Security Team’s own review process.

    A plugin or theme is a different situation entirely. It’s an independently authored package, written by a separate developer of whatever skill level they happen to have. WordPress.org’s directory review checks a plugin at submission, but it doesn’t continuously re-audit every version update that ships after that. A plugin that passed review in 2022 can ship a vulnerable update in 2026 with no equivalent second check.

    This is also where the cost math changes. Verified, tested updates catch the failure mode where a legitimate patch breaks something on the live site, which is a different problem from a plugin’s own code carrying a vulnerability in the first place. See what tested, verified updates actually cost to have covered for how that piece works.

    Verify it

    For any plugin you’re evaluating, check whether it names a security team or a documented disclosure process on its own listing page. A plugin with neither has no equivalent of core’s review process behind it.

    The four vulnerability classes behind nearly all plugin and theme issues

    Nearly all of the 91 percent plugin figure and the 9 percent theme figure comes down to four recurring mechanisms, as WordPress’s own definitions of these vulnerability classes lay out.

    SQL injection

    Unsanitized input gets run as a database command instead of passed through a prepared statement.

    Cross-site scripting (XSS)

    Unescaped output lets attacker-supplied JavaScript run in a visitor’s or an admin’s browser.

    Cross-site request forgery (CSRF)

    A state-changing action fires using a logged-in admin’s own session, because the plugin skipped its nonce check.

    Broken access control

    A user reaches an action or a piece of data that should have required a higher capability level.

    Four cards covering SQL injection, XSS, CSRF, and broken access control, each with a one-line description of how it occurs.

    A nonce, in WordPress’s own terminology, is a Number Used Once. It’s the mechanism a plugin is supposed to check before it lets a state-changing action run, and a missing nonce check is what turns a normal admin action into a CSRF opening.

    Verify it

    For a specific plugin, check its own changelog for language like “sanitization,” “escaping,” or “capability check” fixes. That’s usually the tell that one of these four classes got patched in that release.

    Why this matters for a site you are responsible for

    An outdated plugin isn’t a slow decay. It’s a published map. Once a vulnerability is disclosed along with its fix, any site still running the unpatched version becomes identifiable by version fingerprinting and targetable at scale by automated tools, per WordPress’s own hardening guidance, which states plainly that the exploit information for a disclosed vulnerability is almost certainly in the public domain once the fix ships.

    An inactive plugin doesn’t remove that exposure. Its files still execute if they’re present on the server and registered, deactivation just stops the plugin from loading on the front end, it doesn’t delete the code. If you’re not using a plugin, delete it rather than deactivating it and leaving it there.

    The same logic that connects an unmaintained site to slow performance connects it to exploitability: both come from code nobody is watching. See why an unmaintained site slows down the same way it gets exploited for how that overlaps.

    What good security discipline actually looks like

    Running fewer, well-maintained plugins from established developers who patch quickly is a real, measurable reduction in risk. Risk scales with how many separate third-party codebases a site is running, not with running WordPress itself.

    Severity is the other variable worth watching directly. A high-severity vulnerability, 17 percent of 2025’s total per Patchstack, is associated with likely mass-scale, automated exploitation. That’s the practical test for how urgently a given patch matters: a plugin that’s unmaintained, has a large install base, and handles user input or authentication is high-risk regardless of how small it feels in your own stack.

    See what a maintenance plan should actually include for how that discipline gets specified rather than assumed.

    What to do about it

    1. 01Delete plugins you’re not using. Deactivating leaves the files on the server, where they still execute if registered.
    2. 02Check whether a plugin’s developer is still actively patching it. An abandoned plugin stays exploitable no matter how quickly you’d apply an update if one existed.
    3. 03Apply security updates on a defined schedule. Not whenever someone happens to remember.
    4. 04Confirm updates are tested in staging before they go live. A legitimate security patch can still break site functionality when applied blind, which is a different failure than the vulnerability it patches, and both need a fix.

    Not sure how many plugins on your site are still actively maintained?

    Send NoDrama your URL and get a free website audit, no pitch attached.

    Audit My Site

    Verify it

    After any update, confirm the site still renders and the admin dashboard still loads before considering the patch applied. A rollback path only helps if someone checks that it worked.

    Common misconceptions about WordPress security

    “WordPress itself is insecure.”

    Core’s share of 2025’s disclosed vulnerabilities was 6 low-priority issues, statistically negligible against plugins’ 91 percent. The platform isn’t the risk. The unaudited third-party code running on top of it is.

    “A security plugin covers this.”

    A security plugin helps with detection and hardening, but it doesn’t patch a vulnerable plugin’s own code. That code stays vulnerable until its own developer ships a fix, or a virtual-patching rule addresses it in the meantime.

    “Popular plugins are safer.”

    Popularity increases how worthwhile a plugin is to build an automated attack against. It doesn’t guarantee the code was reviewed for the four vulnerability classes above.

    Getting this in writing matters as much as getting it right in practice. See what a maintenance plan should actually specify about updates for the language that closes that gap.

    What this does not solve

    Tested updates and staged rollback catch the case where a legitimate patch breaks something. They don’t find an undisclosed, zero-day vulnerability, and they’re not a substitute for a web application firewall or real-time malware scanning.

    This guide isn’t a claim that any specific site is, or isn’t, currently compromised.

    So, what are the real security risks of running WordPress?

    The risk sits in the plugins and themes running on top of core, not in core itself, and it concentrates further in whatever is outdated, abandoned, or simply numerous. Fewer, actively maintained third-party codebases is the practical lever, not switching platforms.

  • Is WordPress Secure? The Honest Answer

    Is WordPress Secure? The Honest Answer

    The short answer

    Core is not where the risk lives.

    Patchstack tracks WordPress vulnerabilities two ways, and the two numbers don’t match:

    • Patchstack’s live database: 20 core vulnerabilities out of 11,259 tracked in 2025. That is 0% of the total.
    • Patchstack’s 2026 whitepaper: 6 core vulnerabilities out of 11,334 tracked in 2025. The whitepaper calls these “low priority” issues.

    This guide won’t average the two or pick a winner. Either way, the core sits at roughly 0 to 0.2% of everything tracked in 2025. Both reports agree on the rest: plugins account for 91% and themes for the remaining 9%.

    The other half of “is WordPress secure” is a market-share question, not a security one.

    As of 21 August 2026, WordPress runs 40.7% of all websites. It runs 58.9% of every site with an identifiable content-management system. That is according to W3Techs, an independent source that tracks this directly. WordPress’s own security page gives a different figure: “more than 43% of the web”. That is WordPress’s self-reported number. Don’t average the two.

    Running the largest share of the web makes WordPress the largest target pool. That is arithmetic, not the same as being the least secure platform on the web. The distinction matters before you look at what hardening actually covers.

    How WordPress security actually works

    Core, plugins, and themes get patched in different ways. That difference explains most of what follows.

    How core gets patched

    WordPress 3.7 introduced automatic background updates for core. The goal was security.

    Before WordPress 5.6 (released December 2020), a new install auto-updated only minor releases and translation files by default. From 5.6 onwards, a new install auto-updates both minor and major releases by default. WordPress’s own documentation calls turning that off “strongly discouraged”.

    Who patches the core? In WordPress’s own words: “more than 50 trusted experts, including lead developers, security researchers, and key contributors to every component of WordPress.” They even backport fixes to older, unsupported versions as a courtesy. No one is obligated to keep running those fixes for you, but the team ships them anyway.

    Confirm it

    Open the site’s update settings, or ask whoever manages hosting. Check that both minor and major core updates run automatically, not just minor ones.

    Why plugins and themes are different

    Plugins and themes don’t get the same treatment as core.

    WordPress.org’s security team can force an update to a specific plugin or theme, but only “in special cases”. This happens through the WordPress.org API, when a critical vulnerability needs patching everywhere at once, no matter what the owner set up.

    Outside that rare case, keeping a plugin or theme current is the owner’s job. An abandoned plugin stops getting fixes but stays installed, active, and reachable, which is the exact gap the 2025 numbers describe above.

    What a firewall or security plugin actually catches

    A firewall or security plugin checks the perimeter. It doesn’t patch anything.

    Patchstack’s 2026 whitepaper cites two penetration-testing studies. Hosting-level defences blocked only 12% of attacks on known, already-disclosed vulnerabilities. That rate rose to 26% across a broader set of vulnerability types.

    12–26%Attacks blocked at the perimeter

    A real layer, working by matching known attack patterns at the edge. It doesn’t rewrite the vulnerable code inside a plugin.

    It also can’t catch a backdoor already planted inside a theme or plugin file. That is exactly how a pirated (“nulled”) plugin works. The backdoor ships inside the same zip file a legitimate copy would use. Nothing forced its way in, so there is no signature to catch at the door.

    What a compromise actually costs to recover from

    What decides how a compromise ends? Not the firewall. The backup.

    A tested, offsite backup lets you restore the site to a known-good point. Without one, you rebuild from nothing.

    Whatever caused the breach, a vulnerable plugin, a guessed password, or a nulled theme, matters less at that point. What matters is whether you have a short restore ahead of you or a full rebuild.

    Why it matters even if the core is well maintained

    Sites still get compromised for a simple reason: almost all the attack surface sits in plugins and in what an owner does with them, not in core.

    Core didn’t get worse. The exposure lives in the 91% of 2025’s tracked vulnerabilities that sat in plugins, plus outdated versions, abandoned installs, nulled downloads, and reused admin passwords. None of that runs through WordPress’s security team. An unpatched plugin isn’t an abstract risk score. It is a defaced homepage or a compromised checkout page, the kind of thing a customer notices before the owner does.

    The 90% figure still gets repeated as if it were current. It isn’t. It traces back to Sucuri data from 2018, reported in a March 2019 Infosecurity Magazine article, which makes it roughly seven years stale. Whatever it measured about 2018 installs, it says nothing about security today, or even then. Treating it as a live statistic repeats the exact error this guide opened with: mistaking market share for a security score.

    There is a quieter point worth stating. Leaving WordPress’s free, built-in core auto-updates on solves the smallest slice of the real risk, and it costs nothing. A site owner who does only that has correctly handled the roughly 0 to 0.2% that lives in the core, for free. It doesn’t touch the 91% sitting one layer up in plugins, which is a maintenance question, not something core patches for you.

    What good WordPress security looks like

    What actually reduces this risk is a short, concrete list, not a product:

    • Keep core, plugins, and themes current. Test every update before it goes live, not after.
    • Remove abandoned or nulled plugins and themes. Check for ones you forgot were still active.
    • Use strong, unique admin credentials. Brute-force attacks against wp-login.php are their own attack surface, separate from any software bug. A weak or reused password doesn’t need a vulnerability to succeed.
    • Run file-integrity or malware monitoring. It tells you when a file changed after installation, so it catches a compromise that already happened. It doesn’t stop the first entry; that is what the points above are for.

    What to do about it

    Start with the plugin list, not the firewall. Three actions cover most of this:

    1. 01Audit every installed plugin and theme. Remove anything unused or no longer maintained by its developer. An abandoned plugin doesn’t announce itself. It just stops getting fixed. NoDrama’s free WordPress audit tool does this scan in minutes if you would rather not do it by hand.
    2. 02Turn on core auto-updates for both minor and major releases, if they are not on already. This slice of the problem is free and already solved.
    3. 03Decide who runs tested updates, file-integrity monitoring, and backups: your team, or a retainer that does WordPress operations full-time. Either answer works. What matters is that someone actually does it. See plan pricing and what’s included to compare that against doing it yourself.
    Confirm it

    After any of the above, log the date and what changed. Use a spreadsheet or maintenance log, something that outlives whoever made the change and stays checkable later.

    Common misconceptions

    “A security plugin is a complete answer.”

    It is a perimeter check, and it needs its own updates, like anything else on the site. The pentest figures above put its real block rate at 12 to 26% against known vulnerabilities. That is a partial layer, not a substitute for patching the plugin underneath.

    “My host’s security features cover this.”

    Hosting-level defences carry the same 12 to 26% block rate described above. They are the same category of perimeter defence. They harden the server. They don’t patch the vulnerable code inside a specific plugin.

    “WordPress gets hacked constantly because it’s insecure.”

    This usually traces back to the 90% figure: 2018 data, reported in 2019. It describes market-share exposure, not a security verdict. Running the largest share of the web means showing up in the largest share of hacked-site counts. That is just arithmetic, whatever the underlying security looks like.

    What this does not solve

    None of the above patches a specific vulnerable plugin for you. It doesn’t replace the judgement call of deciding a plugin is abandoned and removing it. It doesn’t replace reading what an update changes before it goes live, especially on a site that depends on that plugin working a certain way.

    Automation and monitoring narrow where your attention needs to go. They don’t remove the need for it.

    Is WordPress actually secure?

    The software WordPress ships from wordpress.org, backed by a security team of more than 50 people and a habit of backporting fixes to old versions, is well maintained. It is not the meaningful risk.

    What determines whether a WordPress site is secure is what runs on top of core and who keeps it current: which plugins are installed, whether they are still maintained, whether the admin password would survive a guess, and whether anything watches for a change after the fact.

    That is a maintenance question about one specific site, not a verdict on the platform every site like it happens to run on.