When does rotation stop being optional?

A few scenarios bring this up often enough that I keep a rotation plan ready for them. I’d rather not improvise one under pressure.

A plugin or CMS on a hosted site gets compromised. I wrote about one real case on this kind of server in PHP2Shell: how I protected my servers while waiting for the patch, a PHP vulnerability that let an attacker drop a web shell before a patch existed. Once a web shell runs under a hosting user, it can often read that site’s own config.inc.php. On a shared ISPConfig box, that file sits next to credentials for the control panel’s own database. Not only the one credential the attacker was actually after.

A configuration file ends up somewhere it shouldn’t. A backup archive left in a public folder. A repository pushed with a stray file in it. A log that’s more readable than anyone intended. config.inc.php and mysql_clientdb.conf have no business in any of those places. Mistakes happen anyway, including mine.

A system administrator leaves the team. However amicable the departure, shared database credentials they once held are credentials I no longer fully trust. Trust doesn’t transfer automatically when someone walks out the door.

A suspected intrusion, even an unconfirmed one. This case is hardest to explain to anyone who hasn’t run a server under suspicion of attack. You don’t wait for proof before acting. You assume compromise and rotate. An unnecessary rotation costs an afternoon. A skipped one, after a real breach, can cost every site the server hosts.

Why manual database credential rotation is so error-prone

The first time I rotated ISPConfig’s database credentials by hand, I underestimated how many files were involved. They all have to change together, or something quietly breaks a few hours later.

There’s config.inc.php on the server side, and a second copy on the interface side. Both need the same new values. There’s mysql_clientdb.conf, which ISPConfig reads to manage every hosted site’s own database, not just its own housekeeping. Dovecot, Pure-FTPd and Postfix each keep their own copy of some of the same credentials. Mail and FTP can stop authenticating silently if you update the database user and forget just one of those three.

Then there’s the Master/Slave topology some of my setups use. A Slave node authenticates to its Master’s database over the network, under a separate password. That password has to be rotated on the Master itself, not only locally. Get the sequence wrong, and a Slave can lock itself out of the very Master it’s supposed to be replicating from.

None of that is conceptually difficult. It’s a lot of files. Several services to restart, in a sensible order. Almost no tolerance for a typo, especially while you’re doing it under pressure, right after finding something you didn’t want to find. That combination is exactly why database credential rotation kept feeling riskier by hand than the task itself should be. It’s why I wrote reset_DB_password.sh, after living through the problem myself more than once.

What reset_DB_password.sh actually does

reset_DB_password.sh detects whether the node is Standalone, Master or Slave. It then runs only the phases that role needs.

Phase A rotates the local MySQL root password. That’s the password ISPConfig itself uses to manage every hosted site’s database. The script updates mysql_clientdb.conf to match the new value.

Phase B rotates the ispconfig control user’s password. It updates config.inc.php on both the server and interface side. Then it updates the matching credentials inside Dovecot, Pure-FTPd and Postfix, so mail and FTP keep authenticating without a separate manual pass through three more config files.

Phase C runs only on a Slave. It connects to the Master’s database remotely. It rotates the Slave user’s password there, then updates dbmaster_password locally, so replication keeps authenticating correctly against the new value.

After Phase B, the script offers to restart Dovecot, Pure-FTPd and Postfix for you. I almost always say yes. A credential rotation that leaves a mail service running on the old password isn’t finished, it’s just quiet about being broken. Restarting in the same run, right after the config files change, keeps the whole thing inside one short maintenance window instead of three separate ones discovered later.

Backups before anything changes

Before touching a single file, the script takes a full rsync copy of /usr/local/ispconfig/ into a timestamped folder. It also attempts a non-blocking mysqldump of the mysql and dbispconfig databases. Non-blocking on purpose: I’d rather finish a credential rotation than sit waiting on a dump that’s stuck for some unrelated reason. Every configuration file it edits gets its own .bak copy first, before any string inside it gets replaced.

None of that replaces an independent backup strategy. I still take a separate snapshot, or a full backup, before running this on any server that actually matters. The script’s own disclaimer says the same thing, more bluntly than I just did.

Dry run first, every time

Every phase asks for confirmation before changing anything. –dry-run simulates an entire run without touching a single file. I use dry-run first on every server, every time. Even on ones I’ve rotated credentials on before, and think I know well. –skip-local-root skips Phase A, for when only the control user’s password needs rotating. –role=master or –role=slave overrides the automatic detection, for the rare case where it doesn’t read a server’s topology correctly on its own.

The passwords it generates are 32 characters, letters and digits only. Long enough to resist guessing. Plain enough that MySQL’s and PHP’s own parsers never trip over a stray symbol in a connection string. I’ve tested the script on ISPConfig 3.3.1p1. I haven’t run it against older or newer branches. I wouldn’t assume identical behaviour there, without checking first myself.

A node’s role isn’t always obvious at a glance, especially on a server you inherited rather than built yourself. That’s why –role exists, and why the dry-run output is worth reading line by line the first time, not skimmed. I’d rather spend two minutes confirming a Slave is really a Slave than find out the hard way mid-rotation.

What I’d tell you before you run it

Disclaimer: the script is provided as-is, for informational purposes. You use it entirely at your own risk: I accept no responsibility for data loss, downtime, or any error caused by incorrect use or by running it in a context different from the one I use it in myself. Always keep an independent backup or VM snapshot before running it in production, regardless of what the script’s own backup step already captures for you.

It’s free software. You can redistribute and modify it, with attribution to me as the original author. The source for reset_DB_password.sh, and the rest of the ispconfig-fast-tools collection, is on GitHub at github.com/matteocisilino/ispconfig-fast-tools.

Database credential rotation is a habit, not a cleanup job

Database credential rotation after a confirmed breach is just competent incident response. Most administrators would do it without being told twice. The harder habit is doing it after a merely suspected one, before anyone has proof. That’s the only version of the plan that actually limits the damage, while it’s still limitable. A script that runs the right phases for a server’s role, takes its own backups first, and lets me dry-run the whole thing before touching anything real. That’s what makes the habit practical on a Tuesday night, instead of theoretical in a blog post.

ISPConfig, MySQL, PHP, Dovecot, Pure-FTPd, Postfix and the other names mentioned are trademarks of their respective owners. They are used only to identify the products.

The post Database credential rotation after an ISPConfig breach first appeared on Matteo Cisilino.

What MPTCP is, and why it matters even if you don’t use it

Multipath TCP (MPTCP) is the RFC 8684 standard. It extends classic TCP so a single connection can travel over several network paths at once. A phone can use WiFi and mobile data at the same time, for the same connection. A server with several interfaces can do the same, for redundancy or for combined bandwidth. Apple has used it in production since iOS 7, back in 2013, for Siri: it’s the best-known real-world case. Some mobile carriers, for example in South Korea, use it for WiFi/LTE bonding. Several data centres adopt it for multi-homing across different uplinks. It’s been in the mainline Linux kernel since 5.6.

The point that made me raise an eyebrow is a different one. From version 1.24 onwards, programs written in Go require MPTCP by default for listening sockets. The Go Security Team confirmed this on 29 October. Along with it, they gave an uncomfortable warning: the bug we’re talking about today isn’t MPTCP-specific. A system with no active MPTCP listeners can still be exposed to similar attacks. The vulnerable code sits in the generic IPv4 TCP path, not in an optional module. You can disable MPTCP per program, with the GODEBUG=multipathtcp=0 runtime variable. But the Go Security Team calls this mitigation “fragile”: a single MPTCP listener left exposed is enough to undo it. Nobody has shown that every working exploit actually depends on MPTCP. That’s why the MPTCP code stays an attack surface, even if you never consciously enable it in your stack: it just needs to be compiled into the kernel and reachable.

The MPTCP project itself states, on its own page, that the main current Linux distributions ship the kernel with MPTCP support compiled in by default (CONFIG_MPTCP=y). It explicitly names Debian, Ubuntu, RHEL and Fedora. That’s a statement from the project itself, not an independent distro-by-distro check, but the underlying point still holds: support is switched on at the kernel level, not “opt-in” at the operating system level. Only the per-connection negotiation is left to the application.

CVE-2026-98432, the Linux kernel vulnerability, in brief

The Linux kernel CVE team published CVE-2026-98432 on 15 October 2026. The upstream fix had already landed ten days earlier, on 5 October. It often happens that publication lags behind the commit. The CVSS score of 9.8 (critical) only arrived on 24 October, nine days after the CVE was published.

The problem lies in TCP handshake handling for IPv4, specifically in the tcp_v4_syn_recv_sock() function. When a connection is created, the IP options from the SYN packet are passed from the pending request socket to the new socket. For example Record Route or Timestamp, if the client includes them in a crafted SYN. The problem is that they’re passed by reference, not by copy, and without the listener’s lock. According to the technical analysis of the patch, the structures involved are called inet_opt and ireq_opt. A second CPU can free that buffer with kfree(), called from inet_sock_destruct() or from tcp_v4_reqsk_destructor(). Meanwhile a first CPU is still reading it in ip_options_build(), to build the SYNACK. It’s a classic use-after-free caused by a race condition. The equivalent IPv6 path, tcp_v6_syn_recv_sock(), copies the options instead of passing them by reference: it isn’t vulnerable to the main race. There’s also a second attack route, through request-socket migration: net.ipv4.tcp_migrate_req=1 or an eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program. Both are disabled by default.

The bug is remote and needs no authentication or user interaction, according to the kernel team’s assessment. It’s been present since kernel version 4.4. The fix is signed off by Eric Dumazet, reported by Xinyang Ge of Anthropic. It moves the memory release to after an RCU grace period, with kfree_rcu(): that way no CPU can read a buffer that’s already been freed. The fixed stable versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and mainline from 7.3-rc7.

Conflicting CVSS scores: not every vendor agrees

Here’s where the story gets complicated. The kernel CVE team and Ubuntu rate attack complexity as low, and give it 9.8 (critical). Oracle and SUSE instead give 8.1 (important): same CVSS vector, but high attack complexity. Red Hat, oddly, has two assessments that don’t match each other. The public CVE page shows “Moderate, 5.9”. The machine-readable advisory file, updated on 29 October, shows instead “Important, 8.1”, with high impact on confidentiality and integrity. The same day, Red Hat’s internal bug tracker raised the severity from medium to high. Amazon, for its part, assigns 7.0. At the time of writing, the NVD hasn’t yet published a score of its own.

It’s worth saying this plainly. This internal inconsistency at Red Hat isn’t a detail I worked out myself: it’s reported that way by the original article from The Hacker News, my main source for this data. It’s not the first time a vendor has published two different numbers for the same bug, on different channels. But here the jump from “moderate” to “important” on the same day says a lot. Even for the people who write the code, reliably estimating the real exploitability of a kernel race condition is hard.

Patch status: Debian already fixed, others not yet

This is the point that affects me most directly: the hosting servers I manage run Debian stable. And here the facts speak for themselves, no need to add emphasis: Debian has already fixed this Linux kernel vulnerability, on both trixie and bookworm. Debian trixie (stable) was fixed on 16 October 2026, with package linux 6.12.113-1, advisory DSA-6568-1. Debian 12 (bookworm) was fixed in two steps: on 17 and 22 October 2026, with linux 6.1.190-1 (advisory DLA-4841-1) and linux-6.12 6.12.113-1~deb12u1 (advisory DLA-4850-1). In its own tracking table, Debian doesn’t list a separate CVSS score for this CVE. It simply marks the fix status for each release: that’s the information that actually matters, for anyone deciding whether to reboot a server.

Comparing this with the status of other widely used distributions helps put it in perspective. As of 30 October, Red Hat has updated the status for RHEL 8, 9, 10 and OpenShift 4. It used to be “fix deferred” (marked on 29 October), now it’s “affected”. No release date has been given. Ubuntu, across all supported versions (22.04, 24.04, 26.04, 26.10), is still listed as “in progress”, with no date. Ubuntu 16.04, 18.04 and 20.04 are listed as vulnerable, with no fix listed at all. SUSE Linux Enterprise Server, from SP4 through SP7 plus 16.0, is in the same situation. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 and Amazon Linux 2023 are, instead, already fixed. RHEL 7 isn’t affected: the vulnerable code path was never shipped on that release.

I’m not saying this to score points against Ubuntu or RHEL. They remain serious distributions, with solid security processes. I’m saying it because, on this specific bug, in this time window, the facts are these: anyone relying on hosting built on Debian stable already has the fix installed. On other very widely used distributions, the server stays exposed for an indefinite period. It’s a concrete, verifiable advantage, just by looking at the dates. It isn’t an opinion about the Debian project in general.

Anthropic’s exploit (reported, not independently verified)

The most unusual part of this story involves Anthropic, the company that first reported the bug through Xinyang Ge. According to industry reports, one of its internal AI models, not released publicly, built a working root exploit entirely on its own. Starting from nothing but the patch and the report as a prompt. The two-stage attack reportedly works like this. In the first stage, the race makes the kernel’s response leak extra bytes to the attacker. From there the attacker recovers a kernel address, defeating KASLR. In the second stage, the same bug reportedly causes a buffer overflow. It overwrites a callback pointer with the address of a payload the attacker has already placed in kernel memory. When the kernel calls that pointer, the payload runs an arbitrary shell command as root. A lost race would only fail that single connection attempt, without crashing the system: so repeated attempts would be possible. In the test described by Anthropic: 48 minutes to steal the kernel address, another 5 minutes to reach command execution.

Red Hat says a remote attacker reaching an exposed TCP service can generally trigger the race. The root exploit described by Anthropic, though, reportedly targeted specifically servers with an active multipath TCP listener. Anthropic’s post doesn’t clarify whether a server without MPTCP is exploitable in the same way. Neither the CVE record nor the upstream fix mention MPTCP anywhere. It’s trade press, not a primary source, reporting this link: so I’m writing it with the scepticism it deserves, not as a hundred-percent established fact. Anthropic hasn’t published the exploit code, the exact kernel version used, or the target server’s configuration. Another company, Innora, has published a root-cause analysis, with a QEMU reproduction environment. It stated it won’t release a weaponised exploit in the short term. At the moment there’s no evidence of real-world exploitation by vendors or CERTs. The bug isn’t in the CISA KEV catalogue, according to the copy maintained by Luxembourg’s CIRCL, updated as of 28 October.

What to do on your servers right now

No vendor has published an officially sanctioned workaround for this Linux kernel vulnerability. Red Hat states explicitly that none of the measures circulating so far meet its standard for ease of deployment and stability. The primary mitigation remains applying the fixed kernel and rebooting, once the patch is available for your distribution. On Debian it already is. On RHEL and Ubuntu, not yet, at the time of writing.

As defence in depth, not as a definitive fix, a few things are worth doing. Check that net.ipv4.tcp_migrate_req is set to 0. Check that no BPF_SK_REUSEPORT_SELECT_OR_MIGRATE eBPF programs are loaded. Consider filtering incoming IPv4 packets that carry Record Route or Timestamp options. Monitor for any crashes mentioning ip_options_build, ip_build_and_send_pkt or skb_under_panic. Take stock of any exposed MPTCP listeners, and avoid leaving them reachable without a reason. If you also manage defences against more common application-level attacks, how I protected my servers while waiting for the PHP2Shell patch takes the same approach: mitigate what you can while waiting for the definitive fix, without promising protections that don’t exist.

For anyone asking me whether to patch now: if you run Debian stable, the fixed kernel is already in the security repositories. The update is straightforward, and the exposure window is already closed. If you run other distributions, there’s no patch to install yet today. It’s worth following your vendor’s advisories closely over the coming days: the situation is changing quickly.

Sources: The Hacker News, the Debian Security Tracker and the fix commit. Debian, Red Hat, Ubuntu and the other names mentioned are trademarks of their respective owners.

The post Linux Kernel Vulnerability: a Use-After-Free in TCP IPv4 first appeared on Matteo Cisilino.

Why I check the WordPress email log before the server logs

The typical case is always the same. A contact form that “isn’t arriving”. A client who never gets the password reset email. An order left without a confirmation. Without a log at hand, the first guess is the spam folder. Then the SMTP server logs. Then maybe the firewall. With FluentSMTP I skip those steps. I can see straight away whether WordPress actually tried to send that email. To whom, when, and with what response from the sending server.

FluentSMTP logs every call to wp_mail(). Not just emails from third-party plugins, but also the ones generated by core: new-user notifications, update reminders, error alerts. For every send, the log shows the sender, recipient, subject, full headers, and message body. And the response from the SMTP provider or API used. If an email failed, that server response is right there. I don’t have to guess it.

What I actually find in the sending log

The plugin supports dozens of connectors: Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. Also Google Workspace and Microsoft 365 via OAuth, as well as plain authenticated SMTP. On the sites I manage I almost always use authenticated SMTP with the client’s own domain. Sometimes a dedicated API, when the email volume grows. Either way, the WordPress email log doesn’t change. Every row has a status, sent or failed. There’s a button to review the content or resend the message, without the user having to repeat the action that triggered it.

Manual resending is the feature I use most. A form filled in twice because “it never arrived” becomes one click in the log. Not a fresh complaint from the client. For repeated failures I’ve set up notifications on Telegram. As soon as a connection stops working, I know before anyone writes to tell me. Instead of finding out from a support ticket.

The log isn’t only about notifications aimed at me or the client who manages the site. Every outgoing email the site generates towards third parties ends up there too: the order confirmation an online shop sends to its customer, a payment receipt, a shipping notice. If that confirmation doesn’t arrive, I see it in the WordPress email log exactly like an internal notification, with the same button to resend it to the right recipient without making them repeat the purchase.

How I set up FluentSMTP on the sites I manage

After connecting the right connector, I change the log retention. By default it stays on for a long time. I set it to 30-60 days, depending on the site’s traffic. That’s enough to trace back a problem reported late. Without filling the database with rows I’ll never look at. I then turn on at least one notification channel for failures, Telegram or Slack depending on the client. The log alone doesn’t alert anyone: it has to be opened to be read.

On sites with contact forms I also use Cisilino Site Defense Network to block bots. Less incoming spam means fewer emails generated by the forms. The log stays easier to read, with less noise to filter through when I’m looking for the right message.

SMTP credentials don’t stay in plain text in the database

One detail I always check before saving a connection: where the credentials end up. FluentSMTP encrypts them by default with WordPress’s own SALT keys, the ones already present in wp-config.php for session security. Encryption can be switched off, but the plugin itself flags that as not recommended. On the sites I manage I prefer another option: saving the API or SMTP password directly in wp-config.php, outside the database, by defining the constants before the plugin reads them. That way, even a database dump or unauthorised access to the dashboard doesn’t expose the sending provider’s key. It’s the same principle I apply elsewhere: fewer secrets in the database, the better.

Several connections together, not just one at a time

FluentSMTP lets you configure several connections together, not just one at a time. On one site I set a default connection and add a second one as a backup: if the first provider doesn’t respond, sending switches automatically to the backup connection, without me having to step in. Which connection gets used depends on the sender address: each connection has its own “From”, everything else goes through the default one, with the backup kicking in only if the default one really fails (a provider error, not an email that ended up in spam). It’s one of the reasons I prefer it to a single SMTP setup with no alternative: if SendGrid or Amazon SES has a problem for a few hours, the site keeps sending anyway, and I see it straight away in the WordPress email log. All included in the free version, with no paid pro version: you only pay the sending provider you choose, not the plugin.

A daily health check, not just when something breaks

Besides the row-by-row log, FluentSMTP runs a connection health check every day, automatically. If the provider stops responding, the alert arrives before a client writes to tell me “the site isn’t sending emails any more”. The same dashboard shows a chart with daily totals of successful and failed sends: useful for seeing at a glance whether a drop is normal or a sign that something is breaking, without having to open the WordPress email log row by row every time. There’s also a periodic email summary, with the week’s totals: it isn’t a failure alert, it’s a bulletin I skim through to know whether the sending volume is within the norm.

For anyone who, like me, manages several sites from the command line, FluentSMTP also exposes WP-CLI commands: a test send, a connection health check, statistics, and cleanup of old logs. I use them in the same scripts that already run on the servers for other maintenance checks, without having to open every site’s dashboard one by one.

The honest limits of the WordPress email log

It isn’t a magic solution. Retention is based on days, not on a maximum number of rows. On a site with a lot of transactional traffic the log table can grow quickly. It’s worth keeping an eye on it, or setting a shorter retention period. Failure notifications only arrive on the chat channels you’ve configured, not by email. That makes sense: an email warning about a failed email risks failing in turn too. But it’s worth knowing before relying on it.

Finally, the log records what happened on the WordPress side and the provider’s side. It doesn’t guarantee delivery into the recipient’s inbox. If an email is marked as sent but ends up in spam, that’s a domain reputation or SPF/DKIM configuration issue. Not something a log can fix on its own. It’s still the first place I look, before any other check.

The plugin is free and open source. Official page on wordpress.org, with no features locked behind a pro version. For anyone managing even a single site with a contact form, it’s worth installing just for the WordPress email log. The first time it turns “I never got the email” into a one-minute fix instead of half an hour, it’s paid for itself.

The post WordPress email log: why I check it with FluentSMTP first appeared on Matteo Cisilino.

Where it is

Open Plugins > Installed Plugins (point 1 in the image). On the row for Cisilino Site Defense Network (point 3) you’ll find the Deactivate link. After deactivation (point 4) the same row shows Activate and Delete.

What happens on deactivation

Deactivating the plugin stops it without touching the data. On deactivation the plugin does four things.

1. it logs the event “Plugin deactivated on this site” and tries to deliver it to the panel, if configured.
2. it cancels the three scheduled tasks.
3. it empties both .htaccess blocks, the blocked-IPs one and the hardening one.
4. it updates WordPress’s rewrite rules.

Warning: while deactivated, no rule stays in force. Blocked IPs can access the site again, and hardening no longer applies. The plugin isn’t even loaded, so the other protections don’t act either. The security headers stop too, though a browser that already received HSTS will remember it for the time that was set.

The database stays intact. If you reactivate the plugin, the .htaccess blocks are rebuilt, and you’ll find the settings exactly as you left them.

How to uninstall the plugin

To uninstall the plugin you need to press Delete in Installed Plugins, after deactivating it. Before you do, follow these steps.

1. In the Activity log tab, check that the “awaiting delivery to the panel” row is at zero, if you use the panel.
2. In the Debug log tab, download any files you need. Then, if you want, press Delete all files.
3. Back up the site, if you haven’t already.
4. Deactivate the plugin and press Delete.

What gets removed and what stays

When you choose to uninstall the plugin, it first logs “Plugin uninstalled from this site: local data removed” and tries to deliver that to the panel. Then it deletes everything, whatever happened with delivery.

The following is removed.

• the four tables csdn_events, csdn_overrides, csdn_rate_hits and csdn_activity.
• almost every option whose name starts with csdn_, including the panel credentials, the whitelist and the tab settings. Three remain, listed below.
• the rate limiting suspension data on every user.
• the plugin’s temporary data.
• the rules in the plugin’s two .htaccess blocks and the rewrite rules. The # BEGIN and # END markers stay in the file, empty.

The following stays instead.

• the debug log files in the csdn-debug-* folder inside uploads, because they are your own data: delete them by hand, or with the Delete all files button, before uninstalling.
• the history already delivered to the panel, which sits on the panel, not on your site.
• the lines in .htaccess that sit outside the plugin’s markers.
• three minor options: csdn_registration_lock (the User registration policy), csdn_remote_ban_reasons (the reasons for blocks received) and csdn_trigger_token (the token received from the panel). The user data csdn_registration_blocked_at also stays, if present, along with the temporary csdn_rl_block_* data, which expires on its own. These can be removed by hand from the database.

Warning: uninstalling the plugin also deletes the local activity log. Rows not yet delivered to the panel are lost if the panel doesn’t respond.

Personal data processed by the plugin

The plugin keeps its data on your own site, in the database. Never the password. Here’s what it processes.

• Failed logins: IP address, username tried, number of attempts, first and last occurrence, and block status. There’s no automatic deletion: they stay in the database until you uninstall the plugin.
• Activity log: date and time, WordPress user (id, login, role), IP, type of action, the object involved (for content, its title) and a short description. In some cases it adds details: for a new user, the email and roles; for a profile edit, the previous and new values of email, login, display name and website. It doesn’t save the content of posts, comments or files. For options with a suspicious name, such as keys or tokens, it only logs that they changed.
• Rate limiting: the IP and type of submission from guests, kept for one day. Author suspensions sit in the user’s own data.
• IP overrides, whitelist and the blacklist received.
• Debug log, if you switch it on: files that can contain paths and fragments of data.

The local log keeps 30 days by default, and at most 500 rows. You can change both values in the Activity log tab.

What leaves the site

Only if you connect the panel. Every 15 minutes the plugin sends the failed logins: IP, username, outcome “failed” and date. It sends up to 200 at a time. It adds the customer code and the site’s URL. It receives the blocked IPs. The activity log, with the details above, is normally sent straight away, at the end of the request, and whatever is left queued goes out with the 15-minute round. It only runs if both the log and the “Send activity to the panel” option are on. Manual overrides are never sent.

What to write in your privacy notice

For as long as you haven’t decided to uninstall the plugin, your site’s privacy notice should mention at least these points.

• that the site logs the IP and username of failed login attempts, for security reasons.
• that it keeps a log of user actions, with IP addresses, and for how many days it keeps them.
• that, if you’ve connected the panel, some of this data is sent to the external service.
• who the data controller is, and how users can exercise their rights.

Adapt the text to your own situation, with your advisor if you have one: this manual is no substitute for legal advice. For the basics on plugins, the official WordPress guide also explains the difference between deactivating and deleting.

If something goes wrong

If the site shows an error after deactivation, check .htaccess via FTP and see the chapter Troubleshooting and frequently asked questions. If you decided to uninstall the plugin by mistake, the local data doesn’t come back: you’ll need a site backup.

Previous chapter: Troubleshooting and frequently asked questions. Back to the index with the introduction to the CSDN manual.

The post Deactivation, uninstallation and personal data first appeared on Matteo Cisilino.

Troubleshooting CSDN: where to start

Before hunting for the exact answer, run through this checklist.

1. Can you still open wp-admin? If so, almost everything can be fixed from the plugin’s Settings page.
2. Read the notices at the top. The plugin explains the outcome of its actions in coloured boxes.
3. Remember the last thing you changed: a hardening rule, a policy, a limit.
4. If there’s a Check now button, use it before guessing.
5. If you can no longer get into the site, get your FTP access or the hosting’s file manager ready.

Logins and blocks

I’ve locked myself out: what do I do?

If you still have access to WordPress, for example from your phone on mobile data, open the Blocked IPs tab. Find your IP and press Unblock. If your IP isn’t listed but you’re still blocked (which can come from the optional security list), go to the General tab, “Local IP overrides” section: enter the IP, choose “Always unblock (unban)” and press Save override. Then, in the General tab, press Add to whitelist.

If you’re blocked from the site too, and see a 403 error, log in via FTP and open .htaccess. Remove the line with your IP, or the whole block between # BEGIN Cisilino Site Defense Network and # END Cisilino Site Defense Network.

Warning: the manual edit is temporary. The same source will rewrite the block at the next event: a failed login, a sync, or the 15-minute round. As soon as you’re back in, use Unblock and the whitelist.

Why didn’t the whitelist unblock me?

The whitelist only stops failed logins from being counted. It doesn’t remove blocks already in place. To remove a block you need Unblock, which creates a permanent unblock override on this site.

A legitimate user has been blocked

The attempts counter is cumulative per IP and never resets on its own. Even scattered mistakes over weeks can reach the threshold, which defaults to 10. Unblock the IP and whitelist it, or raise the threshold in Remote settings, where the field is called “Local block threshold (failed attempts)”.

An IP’s block never ends

A local block doesn’t expire. A manual block expires after the chosen duration, from 1 hour to 7 days. If you chose “Permanent (until you remove it)”, it doesn’t expire. A block received from the panel disappears once the panel removes it from the list. A timed unblock, once it expires, brings the block back if the original source is still there. For a definitive unblock use Unblock, which is permanent.

Blocks look odd behind a proxy or a CDN

The plugin reads the IP only from REMOTE_ADDR and ignores the X-Forwarded-For header, because it can be forged. Look at the line “Your current IP is …” under the IP address field in the General tab. If it isn’t your public IP, the plugin is seeing the proxy’s address. In that case, avoid blocking or whitelisting that address until you’ve sorted it out with whoever manages the proxy.

Errors after the .htaccess rules

This part of troubleshooting CSDN covers rules written to the server’s own file.

The site shows a 500 error after saving the hardening rules

The plugin makes no copy of .htaccess and doesn’t check the syntax after writing it. An error, or a rule your server doesn’t accept, shows up straight away as a 500 error.

1. Log in via FTP or the file manager.
2. Make a copy of .htaccess.
3. Delete the block between # BEGIN Cisilino Site Defense Network - Hardening and # END Cisilino Site Defense Network - Hardening.
4. Reload the site, then correct the settings in the Hardening / IDS tab.

The hardening block is only rewritten when you save that tab or reactivate the plugin, not by the 15-minute round. Your manual fix therefore stays in place.

I wrote a custom path and the whole site gives a 403

In the custom paths box, every line is literal text, with no wildcards. The rule blocks any address containing that string. Writing / or wp blocks everything, including wp-admin. Remove the hardening block via FTP, as above. Then, in the Hardening / IDS tab, fix or empty the “Custom paths to block” box and save. If you don’t fix it, a new save or a plugin reactivation will rewrite the rule, and the site will go back to giving a 403.

You see “Settings saved, but writing to .htaccess failed”

The .htaccess file isn’t writable: check the permissions. The rules in that block aren’t active. The two switches that act in PHP, meaning XML-RPC and ?author=N, stay active regardless.

The test says the PHP block in uploads doesn’t work

In the Test tab, the “Check PHP execution block in uploads” box reports whether the test file was executed. Check that your hosting allows .htaccess in that folder, and that there’s no more specific <Directory> block. On nginx the rules have no effect. The rule only covers the standard uploads folder.

A plugin or the theme has stopped working

Switch off the last rule you turned on and save. The most common cases: blocking PHP in uploads breaks plugins that write PHP files there; disabling XML-RPC stops remote apps and functions; blocking executable uploads also rejects files such as .svg.

Users, authors and visitors

An author can no longer publish: “your account is suspended”

Rate limiting has seen too much content created too quickly. By default the limit is 150 items in 300 seconds, with a 3600-second suspension. From the Rate limiting tab, in the suspended users table, press Revoke suspension. Otherwise, wait for it to expire.

Switching off “Rate limit active” doesn’t remove a suspension already under way. Before a large import, raise the limit N or switch off the cap.

A visitor sees “Too many submissions”

A guest has sent too many comments or forms too quickly: more than 2 in 60 seconds by default, with a 3600-second block. The block is by IP, so it can hit several people in the same office. Raise the N value in the visitors section. There’s no list of exceptions.

I can’t create an editor or administrator user

That’s intentional. The default User registration policy is “Low-privilege roles only”, and it makes no exception, not even for you. Switch temporarily to “No restriction”, create the user, then switch back. With “No registration (exclusive)” nobody can create users. Also check the default role under Settings > General in WordPress: if it’s a forbidden role, registrations are rejected.

Connecting to the panel

The panel connection doesn’t show

The status is in the “Panel connection status:” box at the top of the Remote settings tab. If the box is missing, the fields were incomplete: you need the Customer code, the API key and the Panel URL. After “Save and verify connection” no separate banner appears.

• “Panel URL not secure: https is required …”: the address must start with https. The plugin also refuses to save an http URL.
• “Authentication rejected by the panel: customer_code or API key incorrect.”: double-check both values.
• “Unable to reach the panel: …”: a network, DNS or certificate problem.
• “Invalid response from the panel (not JSON).”: the address doesn’t point to the right panel.

If the panel doesn’t respond, local protection carries on and the queued data is sent on the next round. The plugin works even without the panel.

Activity isn’t reaching the panel

In the Activity log tab, look at the diagnostics table and the “awaiting delivery to the panel” row. Press Try sending now: the result appears in the diagnostics. The row cap, 500 by default, deletes the oldest ones even if they haven’t been delivered.

Debug log, integrity and headers

The debug log won’t turn on

There are two possible messages. “the uploads folder is not writable”: fix the permissions on uploads. “the files in its folder appear reachable from the internet”: probably a server with no .htaccess, such as nginx. Block access to the csdn-debug-* folder in the server configuration and try again. If the log stopped because of the 200 MB cap, download or delete the files and turn it back on.

Integrity says “the plugin’s files do not match”

If you’ve edited a plugin file by hand, that’s normal. Otherwise, treat the site as potentially compromised: reinstall the plugin from a trusted copy and check the rest. If the message says there’s no reference at all, reactivate the plugin to take a new snapshot.

HSTS won’t turn on, or won’t turn off

To turn it on you must open the plugin’s settings over https, otherwise you’ll see “HSTS was NOT activated”. Always save from an https page. Unticking the box stops the header being sent, but browsers that already received it will remember it for a long time.

If you can’t find the answer

If this troubleshooting CSDN page isn’t enough, turn on the debug log, reproduce the problem and read the entry. Then open a discussion on the plugin’s support forum: it’s the place to get help and see problems already reported. Don’t paste server paths or sensitive data.

Previous chapter: Debug log: PHP errors in their own file. Next chapter: Deactivation, uninstallation and personal data. For the index: the CSDN manual.

The post Troubleshooting CSDN: FAQ first appeared on Matteo Cisilino.

Where it is

Go to Settings > Cisilino Site Defense Network (point 1 in the image) and open the Debug log tab (point 2). There are three sections:

• point 3: “Site debug log”, with status and activation.
• point 4: “Collected files”.
• point 5: “Latest entries”.

What the WordPress debug log is for

It comes in useful when the site shows a blank page or a critical error, when something breaks after an update, or when your hosting won’t let you edit wp-config.php or read the logs. The WP_DEBUG and WP_DEBUG_LOG constants are defined before the plugins load, so a plugin can’t turn them on. This log instead uses a PHP error handler hooked onto the plugin’s own loading.

This log adds to things, it doesn’t replace anything. Errors keep arriving wherever they arrived before, meaning debug.log and the server log. It sends nothing to the panel.

How to use it

1. Open the Debug log tab.
2. Choose Stay on for: 1 hour, 24 hours (default) or 7 days.
3. Choose Maximum size per file.
4. Press Turn on the debug log. You’ll read “Debug log turned on. It switches itself off when the chosen time runs out; the files stay.”.
5. Reproduce the problem on the site.
6. Go back to the tab. Read “Latest entries”, or download the file from the “Collected files” section.
7. When you’re done, press Turn off the debug log, or wait for it to expire. You’ll see “Debug log turned off. The files collected are still here below.”.

The “Status:” line tells you whether the log is “on, switches off on dd/mm/yyyy hh:mm”, “off (expired on …)” or “off”. While the log is on you can change the size with Save size.

Collected files

The table lists name, size, and the Download and Delete buttons. Below you’ll find Delete all files. Before deleting, the plugin asks for confirmation: “Delete this file? This cannot be undone.”. For Delete all files the text is “Delete all debug log files? This cannot be undone.”. If there’s nothing you’ll read “No files: the log has never been switched on, or it hasn’t logged anything yet.”.

Latest entries

The box shows the 200 most recent entries, newest first. The All levels menu lets you filter by Fatal error, Parse error, Recoverable error, Warning, Notice or Deprecated. Then press Filter. For anything else, download the files. If the filter finds nothing, you’ll read “No entries match this filter.”.

An entry has this shape:

[2026-10-29 10:15:03 UTC] Warning: message in /path/file.php:12 | GET /page

• The time is in UTC, different from the site time shown in the Activity log.
• After the vertical bar you’ll find the method and path of the request, without the query string. From the command line or cron you’ll see “cli/cron”.
• A multi-line message, such as a stack trace, stays a single entry, with the following lines indented.
• The lines “Info: debug log enabled (user N)” and “Info: debug log disabled (user N)” carry no level: a filter hides them.

Default values and limits

• Duration of the WordPress debug log: 1 hour, 24 hours or 7 days. Any other value becomes 24 hours.
• Size per file: 1, 5, 10, 25 or 50 MB. The default is 5 MB. The chosen size is saved when you press Turn on the debug log or Save size. Watch out: Turn off the debug log resets the size to 5 MB, because that form doesn’t include the size menu.
• Overall cap: 200 MB, adding up the .log and .zip files together.
• Every message is truncated to 4000 characters.
• It only logs PHP errors: not slow queries, JavaScript errors or HTTP requests.

Examples

• A critical error after a plugin update: turn it on for 1 hour, reload the page, filter “Fatal error”. The entry shows the file and line, for example /…/plugins/xyz/file.php:210 | GET /shop/.
• Occasional warnings: 24 hours, filter on Warning or Deprecated. If the file has been rotated, download the zip.
• A slow site with no clear cause: 7 days with 25 MB files, then look for Notice and Warning entries that keep repeating.

Keep it on for only as long as you need: often 1 hour is enough.

Warning: the debug log files contain server paths and fragments of data. Don’t share them publicly. They stay on disk even after switching off and after uninstalling the plugin, which deletes the options but not the files. Delete them yourself when you’re finished. The overall cap is 200 MB.

Warning: on an nginx server, turning it on can be refused until the server blocks the csdn-debug-* folder. The message is “Debug log not turned on: the files in its folder appear reachable from the internet (probably a server with no .htaccess support, such as nginx). The logs can contain paths and data: block access to the csdn-debug-* folder in the server configuration and try again.”. If you don’t manage the server yourself, ask whoever does.

Warning: the log doesn’t see errors suppressed with @, nor ones generated before the plugin loads. For example, it doesn’t see errors from wp-config.php. The plugin’s WordPress debug log doesn’t replace the server’s own logs.

What happens behind the scenes

The WordPress debug log saves its files in a folder named wp-content/uploads/csdn-debug- followed by 16 random characters. Inside are an index.php, a .htaccess denying access, and the file in use, csdn-debug.log. On activation the plugin writes a test file and tries to read it over HTTP. If it responds, the plugin refuses to turn the log on.

When the file in use exceeds the chosen size, it is closed, compressed into a .zip, and a new one starts. No entry is lost. The original .log is only deleted once the zip has been verified. If the compression fails, the .log stays. “Latest entries” only reads from the file in use, so after a rotation the older entries sit inside the zip files.

Before rotating, the plugin checks the 200 MB cap. If it’s reached, the log stops so nothing gets overwritten. The yellow notice reads: “The log has stopped because the files reached the space cap (200 MB): to avoid overwriting data, it stops writing. Download or delete the files, then turn it back on.”. To start again, delete the files and turn the log back on.

On expiry the log switches itself off, but the files stay. The plugin never truncates or deletes them: only you do that, with Delete or Delete all files. For fatal errors, the entry is written at the end of the request.

If the WordPress debug log doesn’t work

• “Debug log not turned on: the uploads folder is not writable.”: check the permissions on the wp-content/uploads folder.
• The log doesn’t write: if writing fails, the plugin reports it with an entry “Site debug log: …” in the “Last attempts” of the Activity log tab.
• The log has stopped for the cap: download what you need, delete the files, and turn it back on.

The general guide to the manual explains where this tab fits in. To understand the WordPress constants better, look at the official WordPress debugging guide: it explains WP_DEBUG and WP_DEBUG_LOG, which this plugin cannot replace.

Previous chapter: Activity log. Next chapter: Troubleshooting and frequently asked questions.

The post Debug log: PHP errors in their own file first appeared on Matteo Cisilino.

Where it is

In the backend go to Settings > Cisilino Site Defense Network (point 1 in the image). Open the Activity log tab (point 2). From top to bottom you’ll find these sections:

• point 3: “Activity log settings”.
• point 4: the status row above the form, with the row counters.
• point 5: “Panel delivery diagnostics”.
• point 6: “Logged activity”, the table with the filters.
• point 7: “Clear the local log”.

What the activity log WordPress keeps is for

It helps you answer questions like “who deactivated that plugin?” or “which IP did that user log in from?”. Every event is a row in the site’s database table.

Don’t confuse it with the per-IP failed-login counter, which decides the blocks. They are two separate pieces of data, with different retention rules. A failed login attempt, though, also shows up here, one row per attempt.

For a long history and for serious searches, the panel is better. The local log also works without the panel. The connection is set up in Remote settings.

How to use it

1. Open the tab and look at the row “Rows in the local log: N — awaiting delivery to the panel: M”.
2. In the form, choose the settings described below.
3. Press Save log settings. You’ll see “Activity log settings saved.”.
4. To read the events go to “Logged activity”. Choose a group from the All groups menu, or type into the User, object or IP field, then press Filter.

The form settings

• “Log activity on this site”: turn it off and no new rows are written. Old ones stay.
• “Local retention (days)”: from 0 to 3650. With 0, nothing is deleted for age.
• “Rows kept cap”: from 0 to 1,000,000. With 0 there’s no cap.
• “Send activity to the panel”: requires the connection set up in Remote settings.
• “Immediate delivery”: sending starts at the end of the request, without making the visitor wait. Turn it off, and sending happens only with the 15-minute synchronisation.
• “What to log”: one box for each of the 18 event groups.

The event groups

The groups carry these labels, identical in the “What to log” boxes and in the All groups menu: Logins (login, logout, failed attempts); Users (creation, profile edits, roles, deletion); Content (posts, pages, custom post types); Categories and tags; Comments; Media (attachments); Plugins (activation, deactivation, installation, update); Themes (theme switch, update, customisation); WordPress updates; WordPress settings; Navigation menus; Widgets; Theme/plugin file editor from wp-admin; Content export; File uploads (including those outside the media library); Plugin file integrity; Plugin settings (including this plugin’s own); Plugin lifecycle (deactivation, uninstallation, log clearing).

For WordPress settings only a selection of the main options is logged, for example blogname, siteurl, admin_email, default_role and active_plugins. For other plugins, only settings declared with register_setting() or saved through options.php are visible. The file editor logs the attempt, not the outcome.

How to read the table

The columns are When, User, IP, Group, Action, Detail and Sent. There are 50 rows per page, most recent first. Use Previous and Next to move around. If there’s nothing, you’ll read “No activity recorded (with these filters).”.

Group and Action appear with their raw name, for example plugins and deactivated. Anyone not logged in shows as “(not authenticated)”. In the Sent column you’ll find the panel’s confirmation date, or “—” if the row is still queued. The technical details field isn’t visible here: it’s read on the panel.

An example row: 12/10/2026 09:14:02, user mario (administrator), IP 203.0.113.5, group plugins, action deactivated.

Examples of reading it

• The “Logins (login, logout, failed attempts)” group and a suspicious IP: a run of failed followed by a success can mean someone has guessed the password.
• A users row with action role_changed and an unexpected user: check whether it’s a privilege escalation.
• A row in the Uploads group with a block warning: someone tried to upload a dangerous file.

Default values for the activity log WordPress keeps

• Logging on, sending to the panel on, immediate delivery on, every group active.
• Retention: 30 days. The age-based deletion runs once a day.
• Row cap: 500. The check runs every 100 inserts, so the table can exceed it by about 100 rows.
• If you save with no group ticked, the log stays on but writes nothing.
• It doesn’t log normal visits, and it doesn’t export data.

Warning: a failed login saves the username typed. If someone types their password into the username field, that text stays in the log, which can go to the panel. The plugin doesn’t filter it out. Keep this in mind when you share or read the log.

Warning: the row cap (default 500) deletes the oldest rows even if they haven’t been sent to the panel yet. The cap takes priority over the delivery guarantee. On sites with a lot of unauthenticated traffic (failed logins, comments, file submissions), 500 rows can run out quickly. If you need the full history, raise the cap, but bear in mind that setting it to 0 removes the limit on disk space.

Warning: “Clear activity log” is irreversible locally. It first asks for confirmation: “Clear the whole local activity log? This cannot be undone.”.

What isn’t saved

Plain-text passwords are never logged. When a profile is edited, only the fact that the password changed is saved. The plugin’s “API Key” field is shown as ***. Options from other plugins whose name contains words like key, secret, token, password, auth, salt, nonce, license or credential have their value replaced with “*** (value not logged)”. Option values are truncated to 200 characters.

Panel delivery diagnostics

The section at point 5 is useful when activity isn’t reaching the panel. A failed send shows no visible error: the rows stay queued and retry. The only symptom is the “awaiting” counter that doesn’t drop.

The table shows, among other things, “Panel connection”, “Activity log”, “Sending to the panel”, “Immediate delivery”, “Rows queued”, “error_log() destination” and “Last send attempt”. Problem values are in red. If the last attempt shows fewer rows accepted than sent, you’ll see “Rows rejected by the panel”: those rows aren’t retried.

There are three buttons:

• Try sending now: makes a test send immediately. The result appears in the table.
• Enable detailed logging (then Disable detailed logging): also logs successful sends.
• Clear diagnostic log: clears only the “Last attempts” list, which holds at most 25 entries. It only appears if there are entries.

What happens behind the scenes

At the end of the request the plugin closes the response to the visitor, where the server allows it, and sends the rows to the panel in batches of at most 200, oldest first. A row counts as delivered only once the panel confirms receiving it. A synchronisation every 15 minutes acts as a safety net.

Age-based retention deletes old rows once a day. If sending is on and the panel is configured, it only deletes rows already confirmed. Otherwise it deletes purely by age.

Clearing the log first tries to send the backlog, then deletes everything. It logs the clearing event, which becomes the first row of the new log. It sends no delete command to the panel: the history already sent stays there. After clearing you’ll read “Local activity log cleared. History already sent to the panel was not touched.”. If there were rows never delivered, a bold warning tells you how many were lost.

If the activity log WordPress keeps won’t send

• The “awaiting” counter doesn’t drop: open the diagnostics, check the last attempt and the HTTP code, then press “Try sending now”.
• A yellow box on the panel that doesn’t confirm: the panel may be out of date. The rows stay queued and nothing is lost.
• Connection “NOT configured”: without a customer code, API key and URL nothing is sent. Go back to Remote settings.

For a wider guide to good logging practice, read the OWASP logging guide: it explains what’s worth logging and what to avoid.

Back to chapter 1, the index of the manual. Previous chapter: Rate limiting. Next chapter: Debug log.

The post Activity log WordPress: the CSDN tab first appeared on Matteo Cisilino.

Where it is

Go to Settings and choose Cisilino Site Defense Network (point 1 in the image). Open the “Rate limiting” tab (point 2). Saving requires the manage_options permission; on multisite you need manage_network_options.

There are four sections. Point 3 is “How it works, in practice: what gets counted”. Point 4 is “1. Authors: publishing too often”. Point 5 is “2. Visitors: comments and contact forms”. Point 6 is “Currently suspended users”. All time values are in seconds.

What it’s for

The cap on authors stops an account publishing at full speed before it fills the site with content. The cap on visitors slows anyone flooding comments and forms. The code also knows a third cap, the mandatory email. You’ll find it in the “User registration” tab, described in the previous chapter.

How to use it

What gets counted (point 3)

The info box explains the rules. For authors, the check fires when WordPress saves a post or a page. The plugin counts how many posts and pages by that author have a creation or publication date within the last T seconds. If there are more than N, the author is suspended. The save that crosses the threshold goes through fine: the suspension blocks the ones that follow.

Plugins and themes don’t count, nor do logins, edits to content older than the window, auto-drafts, revisions, the trash, media, comments or other content types. Temporary environments, like the Plugin Check test one, are ignored.

Warning: the example written in that info box still quotes N=3. It’s old text. The real default value is 150 items in 5 minutes, from version 1.0.13.

Authors (point 4)

1. Tick “Rate limit active” to limit authors’ publishing.
2. Decide whether to keep “Email alert”: you get a mail when an author is suspended.
3. Set “N: allowed items”, from 1 to 1000. Default 150.
4. Set “T: window (seconds)”, from 10 to 86400. Default 300, meaning 5 minutes.
5. Set “S: suspension (seconds)”, from 60 to 2592000. Default 3600, meaning 1 hour.
6. Press Save rate limiting settings.

The mail goes to the admin address set under Settings > General. It contains the user, the content within the window, the expiry, and a list of up to 20 recent items to check. The suspension doesn’t change that content.

Visitors (point 5)

1. Tick “Rate limit active” to limit guest submissions.
2. “Email alert” is off by default. On an exposed site it could generate a lot of mail. It goes to the same admin address under Settings > General, once per block.
3. “N: allowed submissions”, from 1 to 100. Default 2.
4. “T: window (seconds)”, from 5 to 3600. Default 60.
5. “S: IP block (seconds)”, from 60 to 2592000. Default 3600.

This cap only concerns people who aren’t logged in. It counts submissions by IP and by type, comments or forms. A block on comments doesn’t block forms. The contact forms covered are Contact Form 7’s. A rejected comment shows “Too many submissions” with a 429 error.

If a value is outside the limits, the plugin moves it to the nearest allowed one. Saving shows “Rate limiting settings saved. Values outside the allowed limits have been moved to the nearest one.”

Rate limiting WordPress: suspensions and blocks

A suspended author keeps their role and can still use the rest of the admin panel. They lose, though, the permission to create and publish posts and pages. “Add New Post” and the pages menu items disappear, and opening those screens gives “permission denied”. An unclosable notice appears in the dashboard.

Warning: author suspension affects administrators too. A suspended administrator loses the ability to create and publish, but can still open Settings and revoke their own suspension. There’s no list of exceptions for users, roles or IPs: the IP whitelist in the General tab doesn’t exempt anyone from rate limiting.

Warning: the visitor block is by IP. Several people behind the same IP, such as an office, can be blocked together. In that case raise N. The plugin only reads the connecting address (REMOTE_ADDR) and not proxy or CDN headers: behind a reverse proxy or a CDN every visitor can appear with the same IP and end up blocking each other.

How to revoke a suspension

You have two routes.

1. Wait. The suspension ends on its own after S seconds.
2. In the section at point 6, “Currently suspended users”, press Revoke suspension on the user’s row. You’ll see “Suspension revoked: the user can create and publish content again.” If the table is empty, you’ll read “No suspended users.”

The table shows at most 100 users. The dashboard notices carry the links “Revoke the suspension” and “Check and revoke”, which lead to the same tab.

Switching off “Rate limit active” doesn’t remove a suspension already in progress. To remove it you have to revoke it, or wait for it to expire.

What happens behind the scenes

The suspension is information saved on the user, with an expiry date. For guests, every submission is logged for 24 hours in a plugin table, then counted within the window. If two requests arrive together, one extra may slip through. Suspensions and blocks land in the Activity log, if it’s on and if the Users and Comments groups are enabled.

Warning: a legitimate bulk import can trip the cap on authors. Before a migration, switch off the cap or raise N.

Examples of rate limiting WordPress

• A blog with a single author: you can lower N to 10 or 20 with T=300. You’ll catch a compromised account sooner. These are trial values, not a rule of the plugin.
• A newsroom that duplicates or imports pages: keep 150/300 or higher.
• Offices with a shared IP: raise visitors’ allowed submissions to 3 or 5.

Useful conversions: 300 seconds is 5 minutes, 3600 is 1 hour, 86400 is 1 day. To learn more about the general topic, read the OWASP guide on Blocking Brute Force Attacks, which explains why limiting repeated attempts matters.

Previous: User registration: who can create accounts. Next: Activity log: what happened on the site. For the general index go to chapter 1 of the manual.

The post Rate limiting: limits on authors and visitors first appeared on Matteo Cisilino.

Where it is

In the WordPress menu open Settings and then Cisilino Site Defense Network (point 1 in the image). Choose the “User registration” tab (point 2). Saving requires the manage_options permission; on multisite you need manage_network_options.

There are three sections. Point 3 is “Registration policy”. Point 4 is “Allowed roles (only at the “low-privilege roles” level)”. Point 5 is “Mandatory email”.

What it’s for

The policy applies to every route of account creation: the wp-admin panel, the REST API, XML-RPC, WP-CLI, and any plugin or theme using WordPress’s own functions to create users. The check is done in PHP, without touching the .htaccess file.

How to use it

Registration policy (point 3)

Choose a single level out of three. They don’t add up.

• “No restriction (disabled)”: the module is off and WordPress behaves as usual.
• “Low-privilege roles only (never administrator/editor/author)”: this is the default level. The allowed roles at point 4 apply.
• “No registration (exclusive)”: no new user can be created at all.

Allowed roles (point 4)

This only applies at the low-privilege roles level. You can tick subscriber (ticked by default), contributor and customer (useful with WooCommerce). The administrator, editor, author and shop_manager boxes are always disabled, marked “never allowed”.

Mandatory email (point 5)

The box “Don’t create users without a valid email address” is on by default. It stops users being created without a valid email, through any route. It doesn’t touch users who already exist. This setting is saved together with the rate limiting ones, but is managed here.

At the end, press Save registration policy. You’ll see “User registration policy saved.” The save lands in the Activity log, under the label “User registration”.

User registration WordPress: default values and limits

• The default policy is “Low-privilege roles only”, active even if you’ve never saved anything.
• The starting allowed role is subscriber alone.
• Forbidden roles are always discarded, even if someone tries to submit them by hand.
• The list of roles is fixed: it doesn’t show your site’s custom roles.
• There are no email domain lists, captchas or anti-spam checks on registrations.

Warning: with “No registration (exclusive)” nobody can create users, not even the administrator. The “Add New User” item disappears from the menu, and opening user-new.php by hand gives a 403 error. If, at the low-privilege roles level, you untick every role, the list stays empty and no user is allowed at all. Here, though, the menu item and the page stay visible: the 403 error only arrives when you try to create the user.

With the default level you can’t create an editor or an author, not even as an administrator. The plugin makes no exception for someone already logged in. To create a user with a high role, switch temporarily to “No restriction”, create the user, and then switch back.

Also check the “New user default role” under Settings > General in WordPress. If it’s a forbidden role, such as Editor, every registration without an explicit role is rejected.

What happens behind the scenes

The main check acts on the pre_insert_user_data filter, only when a user is created. Changes to existing users always go through. A rejected attempt shows the title “Registration not allowed” with a 403 error. On the REST API you get a 403 JSON error instead of the page.

With any policy active, the plugin removes the XML-RPC method wp.newUser. With the exclusive policy it also forces WordPress’s “Anyone can register” option to false. At the low-privilege level, that option stays whatever you chose.

There’s also a safety net after creation. If an account is somehow created in violation of the policy, the plugin immediately strips its role and writes an event to the Activity log. The account isn’t deleted, so you can examine it.

Warning: a compromised plugin or theme writing straight to the users table with a database INSERT doesn’t pass through any filter. No PHP plugin can stop that. The user registration WordPress protection in this tab is a strong barrier, but it isn’t absolute.

Examples

• A showcase site with no public users: choose “No registration (exclusive)”.
• A site with subscribers or comments: leave the default level with subscriber.
• A shop with WooCommerce: add customer.
• You need to add a collaborator with a high role: use “No restriction” only for as long as needed.

If something goes wrong

If a sign-up is rejected with the message about a role not being allowed, check WordPress’s default role and the roles ticked at point 4. The Activity log tells you if an account has had its role stripped by the safety net. To understand the roles better, read the page on roles and capabilities in the WordPress documentation. It lists what each role can do.

Previous: Paranoic Hardening: security headers and the admin session. Next: Rate limiting: limits on authors and visitors. For the general index go to chapter 1 of the manual.

The post User registration: who can create accounts first appeared on Matteo Cisilino.

Where it is

In the WordPress side menu go to Settings and choose Cisilino Site Defense Network (point 1 in the image). Open the “ Paranoic Hardening” tab (point 2). Saving requires the manage_options permission; on multisite you need manage_network_options.

The tab has four sections. At point 3 you’ll find “Paranoic Hardening — HTTP security headers”. At point 4 there’s “HTTP Strict Transport Security (HSTS)”. Point 5 is “Security header check”. Point 6 is “Autologout of inactive administrators”.

What it’s for

Headers are instructions the site sends the browser along with every page. The plugin sends them through WordPress’s send_headers hook, without touching the .htaccess file. So you don’t risk a 500 error, and they work even without mod_headers.

The headers only cover the public site. They are never sent in the admin area. The plugin offers no Content-Security-Policy, and it doesn’t send X-XSS-Protection.

How to use Paranoic Hardening

HTTP security headers (point 3)

• X-Content-Type-Options sends nosniff. The browser stops “guessing” a file’s type. The risk here is practically nil.
• X-Frame-Options sends SAMEORIGIN. The site can no longer be embedded in an <iframe> on another domain. If a partner site shows your pages, it will stop doing so.
• Referrer-Policy sends strict-origin-when-cross-origin. Towards other domains only the domain travels, not the path. Third-party statistics tools wanting the full referrer won’t get it.

Tick the boxes you need and press Save Paranoic Hardening. You’ll see the notice “Paranoic Hardening settings saved and applied.” Boxes you don’t tick are saved as off.

HSTS (point 4)

HSTS tells the browser to always use https with your domain. There are three boxes: “Enable HSTS”, “includeSubDomains” and “Preload”. The header sent carries max-age=31536000, meaning one year. The value is fixed and cannot be changed.

The plugin refuses to activate it if the page wasn’t opened over https. In that case it saves the rest and shows a red warning: “Settings saved, but HSTS was NOT activated: this request did not arrive over https. Open the panel over https and try again.” If the page is over http, the three boxes are also disabled.

If you turn off “Enable HSTS”, on saving “includeSubDomains” and “Preload” are reset too. If you turn HSTS back on, you’ll need to tick them again.

Security header check (point 5)

Press Check now. The plugin makes a real request to the site’s home page and checks which headers genuinely arrive. The result appears in the box, with the date of the last test.

• Green: “All the expected headers are present in the site’s real response.”
• Red: the active headers that didn’t arrive. This can be a proxy, a CDN or another plugin removing them. HSTS shows as missing even if the home address is http rather than https, because the plugin only sends it on https requests.
• Blue: “No active header to check: enable at least one option above and save.”
• Red with “Check request failed”: the request didn’t succeed.

The test checks whether a header is present, not its value. It doesn’t run on its own: you have to press it.

Autologout of administrators (point 6)

This section of Paranoic Hardening has its own button, Save autologout for administrators. Tick “Enable” to log out inactive administrators. Then set the “Inactivity timeout (seconds)”. If the browser blocks localStorage (in a private window, for instance), the check never fires and you’re never logged out.

The default value is 900, meaning 15 minutes. The minimum is 60 and the maximum is 86400. If you write a number outside those limits, the plugin moves it to the nearest allowed value. For example, 30 becomes 60. The notice stays green, so reread the number in the field after saving.

Only users with the manage_options permission are logged out. Editors and authors aren’t touched. Inactivity is measured in the browser: mouse, keyboard, scrolling and touch all count. The session closes just as with “Log Out”, and unsaved changes in an open form are lost.

Recommended order of activation

1. Open the panel over https.
2. Turn on X-Content-Type-Options, save and press “Check now”.
3. Turn on Referrer-Policy, save and check.
4. Check that no site embeds yours, then turn on X-Frame-Options, save and check.
5. Turn on autologout with a generous timeout, for example 1800. Lower it only after a few days.
6. Last of all, consider HSTS, without includeSubDomains and without Preload.

Turn on one option at a time. If something breaks, you’ll know straight away which one did it.

The risk of HSTS, includeSubDomains and Preload

Warning: HSTS can’t be undone from the site. If you untick it, the plugin stops sending the header, but browsers that already received it will remember it until it expires. The plugin never sends max-age=0, so there’s no “cancel”. The tab’s own banner says so too: the effects can stay visible for weeks or months.

With HSTS on, the browser refuses any non-https connection to the domain. If the certificate expires or breaks, the browser no longer even shows the “proceed anyway” screen. The site becomes unreachable from that browser.

• includeSubDomains extends the rule to every subdomain. A single subdomain without valid https, even a test one or a future one, becomes unreachable for anyone who has already visited the site. Only turn it on if every subdomain is, and will remain, https.
• Preload only adds the preload flag to the header. On its own it doesn’t register the site: submitting it to the browsers’ list is done by hand on hstspreload.org. The list sits inside the browsers, and getting out of it takes weeks. Treat Preload as a final, one-way decision.

Always save from the https version of the panel. Disabled boxes aren’t sent by the browser: saving from an http page switches off HSTS and its sub-options.

What happens behind the scenes

The Paranoic Hardening settings are WordPress options, not server rules. Autologout prints a script only on admin pages. The script records the last activity in the browser’s localStorage and checks the timeout every 5 seconds. On expiry it asks admin-ajax.php to log you out and takes you to the login page. The save only lands in the Activity log if you actually changed something.

If something goes wrong

• The box turns red after “Check now”: a proxy, a CDN or another plugin is stripping the headers. Check their configuration.
• A partner site no longer shows your pages: untick X-Frame-Options and save.
• You can’t turn on HSTS: reopen the panel with the https address.
• To check the headers by hand, use your browser’s developer tools or curl -I on the site’s https address.

To understand HSTS better, read the page on Strict-Transport-Security on MDN. It explains max-age, includeSubDomains and preload precisely.

Previous: Test tab: checking that the protections work. Next: User registration: who can create accounts. For the general index go to chapter 1 of the manual.

The post Paranoic Hardening: headers and autologout first appeared on Matteo Cisilino.