A password-reset link should never become translatable website content. But TranslatePress 3.3.1 and below could pass an administrator’s reset email through its translation system and save the full reset URL, including the key, in a secondary-language dictionary. A public action could then retrieve that entry. The attack required specific conditions, including automatic string saving and a published secondary language matching the administrator’s profile language. Update to 3.3.2.

A security patch needs to pass two tests: The exploit no longer works. The legitimate feature still does. For the WPMU DEV SSO issue, researchers confirmed that the patched version rejected the replayed signature. They also tested a legitimate SSO response and confirmed that login still worked. Blocking every request would stop the attack too but it would also destroy the feature. A successful patch closes the malicious path without closing the real one.

Security automation is not only about finding vulnerabilities. WordPress is tightening its security-release process, improving end-to-end testing and scheduling upcoming security releases. That is the less glamorous part of security: getting the correct fix built, tested and shipped predictably-without breaking the feature it is supposed to protect. A patch sitting in a queue protects nobody.

As of August 28, the WordPress Test Team had 130 Core issues waiting to be reproduced and another 125 waiting for patch testing. That’s a good reminder for all of us: reporting a serious bug is only the beginning. Someone still needs to reproduce it, confirm what’s happening, and make sure the fix actually works. A useful report should include exact versions, the conditions needed to trigger the issue, clear reproduction steps, what you expected to happen and what actually happened, and a negative control. This isn’t just paperwork. If nobody can reproduce the problem, it’s much harder to build and verify the right patch.

AI is finding more WordPress vulnerabilities. That sounds like an obvious win. But WordPress says incoming security reports have increased substantially, and the work now has to scale around triage, validation and fixes. Finding a possible bug is only the first step. Someone still has to reproduce it, understand the conditions, build a patch that doesn’t break the feature, test it and get it onto real sites. AI can increase discovery but security still depends on everything that happens after the finding.

WordPress 7.1 has an Icon Registration API for SVG icons. That does not mean “all SVG is trusted now.” The API uses a deliberately limited allowlist and strips unsupported elements and attributes. If your workaround is to disable SVG sanitization globally, you’ve taken a careful new feature and removed the careful part.

Directory listing: stops the server from showing visitors a convenient list of files. Disabled PHP execution: stops PHP files from running in selected directories. Neither removes the files. And disabling directory listing won’t protect a malicious file whose exact URL is already known. Different controls. Different jobs.

“Download this image” sounds harmless until an AI agent can follow arbitrary URLs from your server. The URL might redirect to a private service. The “image” might be enormous. The destination might change after the first check. Safe automation validates the entire journey-not just the address it was initially given.

During a reinfection, timestamps can tell you more than filenames. If an unknown administrator appears at 10:00 and malicious files return at 12:00, don’t assume the files created the account. The account may be the persistence mechanism recreating the files. Build the timeline before choosing the culprit.

DISALLOW_FILE_EDIT removes the theme and plugin editors from wp-admin. That closes one convenient route from a stolen admin account to live PHP. It does not block plugin uploads, SFTP, SSH, hosting file managers, vulnerable plugins, or an attacker who already has server access. Use it because production is a bad place for casual code edits—not because it turns an admin compromise into a harmless event.

Turning off directory browsing removes the public file list. It does not hide a file whose address is already known. Options -Indexes can stop an “Index of…” page, but it does not delete exposed files, block direct requests, or disable PHP. Think of it as closing the directory—not changing the locks on every file inside it.

A public WordPress author name is not automatically a vulnerability. Publishers often need visible bylines, author archives, and profile pages. The mistake is assuming that hiding one author URL protects the account. First determine what each route reveals: display name, author slug, user ID, or actual login name. Remove unnecessary exposure, but secure the account as though its identity will eventually become known.

A failed WordPress login proves the password was rejected. That’s all. It does not prove the account exists, and it does not prove the site was breached. Before declaring an incident, look for the event that matters: a successful login followed by an unfamiliar admin, password change, plugin installation, or file modification. Rejected attempts show pressure. Successful access and unexpected changes show impact.

Changing “admin” fixes one problem: a predictable login name. It does not make the account private. Author URLs, display names, REST responses, and login messages may still reveal useful identity clues. Treat a harder username as added friction—not a security boundary. The account still needs a unique password, two-factor authentication, limited privileges, and protection against automated login attempts.

Your WordPress site can look totally fine and still be hacked. Some malware only shows up for certain people—like first-time visitors, mobile users, or people coming from Google. If you’re logged in, you might never see it. So when a customer reports something weird, don’t just try to “check it yourself.” Ask for the exact page, time, device, and how they got there. Then match it with logs and run a proper scan.

A search box shouldn’t be able to touch your database. But in WP Directory Kit (before 1.5.6), it can. A crafted search request can interact directly with the database—no login needed. That could let an attacker extract data just through the search feature. Fix: update to 1.5.6 or later. And if you were on a vulnerable version, don’t stop at updating. Check for unusual database activity, new users, or unexpected content. A patch stops future attacks. It doesn’t confirm past ones.

There’s a WordPress plugin called JSON Options that appears completely harmless at first glance—it’s just meant to manage site settings. But in versions 0.0.4 and below, it fails to check who is sending requests. That means even unauthenticated users can change core WordPress settings. An attacker can: Enable user registration Set new users to Administrator Create an admin account At that point, they own the site. The issue was disclosed on August 18, and there’s no confirmed fix yet. If installed: Disable it immediately Check for new admin users Review recent settings changes

HSTS isn’t just a WordPress setting - it’s a browser memory. Turn it on, and visitors may keep enforcing HTTPS long after you’ve changed your site. Enable includeSubDomains too early and old staging, APIs, or forgotten subdomains can suddenly stop working. Not because WordPress broke — but because browsers refuse to even try HTTP anymore. So don’t rush it. Start with a short max-age, test every hostname, then increase slowly. And preload? That’s not a toggle. That’s a permanent promise to the internet. HSTS is less a switch… and more a commitment.

Security scanners can totally miss this one. Referrer-Policy is basically what your browser “tells” other websites when someone clicks a link from your site. And if it’s too relaxed, it can quietly leak parts of your URL — sometimes even stuff like IDs, names, or tokens sitting in the address bar. The fix is simple: set it to strict-origin-when-cross-origin. It’s the safe middle ground most WordPress sites should be using anyway. But here’s the real point — don’t trust the green “all good” score. Click around like a real user. Test payments, forms, embeds, everything. Because scanners don’t break your site… people do.