Release notes

Recent additions and fixes, in plain terms. The build you are running is shown at the top-left of the console and in the manual sidebar.

New

• Fixed: geo blocking in the WAF no longer uses a lot of memory or slows down every request. A geo policy applied in the WAF, or one that lets certificate checks through, gives the WAF the address list of every country it blocks. That is hundreds of thousands of ranges once a large country is in it. Every site kept its own copy of that list, about 20 MB per site for the United States alone, and every request was checked against the list one entry at a time, adding several milliseconds to each request from an allowed country. The WAF now keeps one copy of each list for all sites and finds an address in it straight away, so memory no longer grows with the number of sites and a request costs no more than without geo blocking. Blocking is unchanged: the same addresses are refused.

• Fixed: geo policies that challenge visitors no longer slow down every request. A policy whose response is Challenge checked every visitor against its countries' address list one entry at a time, about a millisecond per request for a large country, even for visitors it let straight through. The browser check, the flagged-visitor check and the threat-feed challenges used the same lookup. They now find an address straight away, whatever the size of the list.

• New: Protection Status warns when the WAF engine uses far more memory than the server's number of sites needs. The Engine memory card already warned when memory grew with every configuration change or with time. Memory that is simply too large from the start, as the geo lists above made it, did not grow and was not flagged. The card now compares the memory in use over the last hour with what the server's number of sites should need, and says so when it is far above. portwall-admin diagnose reports the same comparison.

• Fixed: geo blocking no longer keeps search engines out. Google and Bing crawl almost entirely from the United States, so blocking the US - or any country a search engine crawls from - refused every crawl, and the sites behind the block dropped out of search results. Let certificate checks through never covered this. A new Let search engines through switch on the Geo Blocking page, on by default, leaves the crawlers of Google, Bing, Apple and DuckDuckGo out of every country you block, at the firewall and in the WAF. They are recognised by the address ranges those search engines publish, refreshed daily, never by the name a visitor gives. If your sites dropped out of search results, ask the search engine to crawl them again (in Google Search Console, URL Inspection and Request indexing). See Geo-blocking.

• Fixed: geo blocking in the WAF always uses the current address list. When only the addresses behind a geo policy changed - for example after the GeoIP database was refreshed - the WAF could go on using the previous list until some other setting changed. This applied to policies applied in the WAF and to the web-port part of policies that let certificate checks through. Changes to the list now take effect straight away.

• Changed: requests refused by geo blocking are counted on the Geo Blocking page instead of filling the Attack Feed. With Let certificate checks through, or a policy applied in the WAF, every web request from a blocked country is refused by PortWall's WAF, and each one used to appear in the Attack Feed as if it were an attack. One crawler from a blocked country could fill the feed and hide the real attacks. These refusals now appear in a new Refused in the WAF table on the Geo Blocking page, per policy and country, for the last 24 hours and the last 7 days. They no longer add to an address's risk score, so they cannot get an address blocked on top of the country block. They are still sent to your SIEM if you export events. See Geo-blocking.

• New: the Attack Feed shows whether each request was refused. A new Result column says Refused (with the status PortWall answered, for example 403) or Logged (the request was let through, because the site's protection only reports or the rules that fired do not refuse on their own). Entries recorded before this update show "—". The API's attack list includes the same as verdict and responseStatus.

• Fixed: Malware Rules no longer offers a rule pack that cannot be downloaded yet. The PortWall webshell rules pack was listed, and selected by default, before it was published, so turning on rule packs showed a download failure for it. It is now shown as Not available yet and cannot be selected until it is published, and a server that had it selected stops trying to download it. The other rule packs, and PortWall's built-in webshell detection, work as before.

• Fixed: Malware Rules shows where each rule pack is downloaded from. The line under each pack's name was always empty. It now shows the address a one-file pack is downloaded from, or the folder and the number of files for a pack made of several.

• Fixed: no red Premium Threat Intelligence alarm while an update from an older release restarts PortWall. During an update from an older release, Protection status could show Premium Threat Intelligence in red for a couple of minutes, although the threat lists kept blocking. It now shows the amber "checking" state for those minutes, like the other protections, and red only if it still cannot be checked once the update is finished.

• Fixed: protection is never detection-only while an update replaces the WAF engine. The new engine checks its own files against the release record when it starts, and an update used to write that record only after its health check had passed. For a few minutes after an update that replaced the engine - longer on a server with many sites - the new engine could not confirm it was the released one and inspected requests without blocking them. The update now writes the record before it starts the services, so the new engine starts fully protecting, and an update that has to be rolled back puts the previous record back with the previous engine.

• Changed: Protection status says "checking" right after an update instead of raising alarms. While an update restarts PortWall, the part that reports on blocking can be out of reach for up to a minute, and for several minutes after that Geo Blocking and Threat Intel Feeds could show a red "could not verify this protection: the operation has timed out" although everything was still blocking. In the minutes around an update these cards now show an amber "checking: PortWall is restarting after an update" that clears by itself. A protection that still cannot be checked ten minutes after the update, or at any other time, is shown in red as before, and the amber state does not send an alert.

• Fixed: geo blocking is re-applied once after an update, not twice. After an update the server's country rules used to be sent to the part of PortWall that was about to be replaced, and then again to its replacement, so a server with many sites spent an extra minute and a half on a second full apply while the first one's failure was logged. PortWall now waits for the replacement to be ready and applies the country rules once. The rules that were in force keep blocking throughout.

• New: install PortWall with a small web installer. Download portwall-install.exe (a few MB) from portwall.net/download, run it as Administrator and enter your licence key. It downloads the current release, checks it, and opens the installer with your key already filled in. For scripts, portwall-install.exe --key <licence key> --quiet installs without a window. See Getting started.

• Changed: updates are downloaded from PortWall's download service, dl.portwall.net. PortWall releases are now available to licensed servers only. If your server filters outbound traffic, allow HTTPS to dl.portwall.net. Nothing else changes: updates are checked against PortWall's release signature as before.

• Changed: uninstall with portwall-install.exe --uninstall. It reads the licence key from the installation, downloads the installer and runs its uninstaller, and works even if your licence has expired or been cancelled. See Uninstalling.

• Fixed: the installer showed broken characters. The installer window, its console messages and some service log lines showed broken characters in place of dashes, arrows and section signs. They now show the intended characters.

• Fixed: port scans are detected again after Windows starts a new firewall log. When the firewall's dropped-packet log fills, Windows renames it to pfirewall.log.old and starts a new pfirewall.log. PortWall kept reading the old file, which nothing writes to any more, so from then on no port scan was seen until the Worker service restarted. PortWall now notices the new file and reads it from the start. The same fix applies to any other log PortWall reads for failed logins that is rotated by renaming it. Diagnose now shows which file port-scan detection is reading, how far it has read, and the previous log, and says so if it is still on the old one.

• Changed: Diagnose no longer reports geo blocking as a failure when you switched it off. With geo blocking switched off on the Geo Blocking page and your country policies kept for later, Diagnose now shows a note instead of a failure. It is still a failure when policies exist and geo blocking was never switched on.

• New: a site's fail mode now works, and every site is set to Open by this update. Fail mode says what happens to a request PortWall cannot fully inspect: Open lets it through, Closed refuses it. Until now the setting was saved but did nothing, and the Add site form chose Closed by default, so this update sets every site to Open - what they have actually been doing - and new sites start as Open. Choose Closed on a site's page where an unchecked request would be worse than a refused one: there, a request body larger than the WAF inspection limit is refused (413), and so is an upload the scanner could not check (403, shown in the Attack Feed as "could not be checked"). A backup made before this update restores its sites as Open too. See Fail mode.

• Changed: the API reports errors the same way everywhere, and lists attacks since a time. Refusals from blocking, the allowlist and tenant site grants used to be a bare text string; they are now { "error": "..." }, like every other error, so a script that read the string must read error instead. GET /api/events?since=<time> returns only the attacks after that time, so a script polling for new attacks no longer has to fetch the whole list. On Windows, saving a site through the API now refuses a paranoia level outside 1-4, an anomaly threshold outside 1-1000 and an unknown mode, as the appliance already did; a value you do not change is not checked again. See API keys.

• Fixed: example text in some boxes showed stray codes. Several boxes that show an example of what to type - paths never checked on Bot Protection, the sites to leave out on Sites, trusted proxies, management-port sources, certificate patterns, CORS origins, GraphQL sources and the failure-line pattern on Brute-force - showed 
 or < instead of a new line or a <. They now show the example as intended.

• New: Protection status warns if the WAF engine's memory keeps growing. A new Engine memory card turns amber when the engine uses more memory after each configuration reload, or when its memory keeps climbing over a day, and tells you how much and what to do. Until now a problem like that only showed up if someone happened to look at the server's memory by hand.

• Fixed: the WAF engine no longer grows a little every time its configuration is reloaded. The engine reloads its configuration whenever you change a setting, a certificate renews or a site is added. Each reload left behind a copy of the word lists the WAF rules check requests against - known scanners, forbidden file names and the like - for every site whose settings had changed, and they were only freed when the engine restarted. On a busy server that came to gigabytes within a day. The engine now keeps one copy of each list for all sites and frees the old ones after a reload, so it also uses noticeably less memory on servers whose sites have different WAF settings. Diagnose now shows how much of the engine's memory is in use and how much it is only holding for reuse.

• New: Windows may warn about the installer; the manual says what to click. The installer is not yet signed with a Windows code-signing certificate, so the browser and Windows SmartScreen can warn before it runs. Getting started lists each warning, what to click, and how to check you have the genuine file.

• New: Premium Threat Intelligence (Premium and Enterprise on Windows, every appliance edition). Attackers caught across the PortWall network are now blocked on your server before they reach your sites. PortWall scores every address it sees attacking PortWall servers - how often it comes back, on how many servers, and what it tries - leaves out shared infrastructure such as CDNs and search-engine crawlers, and sends your server a signed list every 15 minutes. Addresses seen attacking several independent PortWall customers, or attacking one relentlessly day after day, are dropped at the firewall; others are sent to the browser check or monitored. You choose per category (web exploits, brute force, scanners, bots and floods, other) whether listed addresses are blocked, challenged or only monitored, and your allowlist always wins. Look up any address to see why it is listed - for example "seen attacking 4 PortWall servers on 11 days, mostly SQL injection" - on the Threat-intel Feeds page or the Blocked IPs page. It is on by default on a Premium server, shows on Protection status, and is released at once if the licence moves below Premium. See Premium Threat Intelligence.

• New: bot protection is part of PortWall Premium. The browser check for sites under attack, the check for visitors a detection flags, what the bot-cluster and credential-stuffing detections do to the addresses they find, and TLS fingerprinting are now included with PortWall Premium and above on Windows, and with every appliance edition. On a plan without them the Bot Protection page says so and keeps what you set; it takes effect when the licence includes it. Detections are still reported in the Attack Feed and in alerts on every plan, and login protection - including its browser check on the login page - works on every plan, as do the paths never checked, difficulty and pass time.

• Changed: API specification checks and CORS controls are now part of PortWall Enterprise. They sit with JWT validation and GraphQL limits. Per-site allowed methods and route limits stay in every edition. If your plan does not include them, API Protection says so and keeps what you set; it takes effect when the licence includes it.

• New: the console names your plan the way you bought it, and the Licence page says what it includes. Windows is Standard, Premium or Enterprise; the appliance is Premium or Enterprise. The Licence page lists what your edition includes and what the next one adds, and each locked feature says which edition unlocks it.

• Fixed (Windows): a site deleted from IIS no longer stays in PortWall. PortWall kept serving a deleted site's configuration for good - a certificate, a health check and engine memory for a site that no longer existed - and its settings piled up on the Sites page. Now, about half a minute after a site is deleted (or renamed) in IIS, PortWall stops routing it. Its settings are kept, so a site re-created with the same name gets its tuning back. The Sites page lists these sites under Deleted from IIS with Remove and Remove all buttons. To have the settings removed automatically too, turn on "Also delete the settings of sites deleted from IIS" on the Setup tab. This now covers every site, not only sites created through a hosting panel.

• Security fix (Windows): other accounts on the server can no longer read or write PortWall's folder. PortWall's install folder took the system drive's default permissions, so every local account - on a hosting server, every customer's website - could read PortWall's database and logs and create files in its folders, including ones its services load settings and programs from. PortWall now closes the folder at start and after every update: only Windows itself, administrators and PortWall's own services can use it, and PortWall works exactly as before. The Diagnose report says so if the folder is ever open again.

• Fixed: a console page left open no longer acts after your session has ended. A page that stayed open kept working after its sign-in had run out: pressing a button - Install, for one - still carried it out, and only then did the login form appear. Now a page whose session has ended goes to the login form within seconds, and any change asked for after the end is refused, with nothing done. Restarting PortWall's services, which every update does, also no longer signs everyone out of the console.

• Fixed: an appliance update applied without a restart now finishes in the maintenance window. Most updates take effect at once, and the appliance only needs one restart to move fully onto the new release. That restart used to wait for someone to press Restart now, even with a maintenance window set, so the "restart pending" reminder stayed on every page. The appliance now restarts by itself the next time the window is open. It tries once; if the restart does not move it onto the new release, it says so and Restart now tries again.

• New: the appliance's System page lets you choose the update channel. Stable or Testing could only be chosen on Windows, so an appliance could not leave Testing from its own console - and on Testing an update never installs by itself, even with automatic updates on. The choice is now on System, next to automatic updates and the maintenance window.

• Fixed: a site with a named login page no longer slows down every blocked request on the server. Each site with a login page set on the Sites page kept a login log of its own, and every request the WAF blocked, on any site, cost extra processing for each of those logs - on a server with many such sites, enough to raise CPU noticeably during an attack. All sites now share one login log, as sites protected automatically already did. Failed logins are detected and blocked exactly as before.

• Fixed: the WAF engine's logs no longer fill the logs folder with uncompressed files. The engine's general log now has a file of its own, engine.log, rotated daily and at 100 MB, compressed and kept 30 days like PortWall's other logs. It used to be written to portwall-dataplane.err.log, whose rotated files were never compressed; on a busy server that came to over a gigabyte. That file now holds only start-up errors, its rotated files are compressed and removed after 30 days, and the ones already there are compressed within an hour of the update. The engine also no longer logs a warning every time a visitor leaves a page before it has finished loading.

• Fixed: Verify now no longer says an update failed while the server is still starting. After an update on a server with hundreds of sites the WAF engine needs several minutes to load every site. The update check used to fail the services and version steps for that time; they now say PortWall is still starting up, how long it has been, and re-check by themselves. A service that is really stopped, or a build that is really the wrong one, is still reported at once.

• New: you are told when the WAF engine is serving slowly. If the engine is still serving traffic but answering PortWall's health check slowly for more than a minute, PortWall does not restart it (that would only start another slow start-up) and now sends one alert per slow spell, in plain words, with the usual causes. It appears as "WAF engine serving slowly" on Operational Events and goes to your alert email like the other alerts; untick "DataPlaneSlow" on the Notifications page to turn it off.

• Fixed (Windows): an update repairs the console's and Worker's access to the WAF engine before it starts them. On a server whose permissions were missing, the first configuration change after an update was refused and only took effect about five minutes later; the permissions are now repaired during the update itself, before the services start, and the update's record says what was repaired.

• Fixed: the diagnostic report names a missing service permission and what it costs. portwall-admin diagnose now lists each folder or file the PortWall services have lost access to (for example the WAF engine's admin socket folder, which stops configuration changes being applied until the engine restarts), says how to repair it, and points to it when the engine is serving an older configuration than the one on disk.

• New: see which URLs a site is being asked for. The Who is sending it section on the Traffic page now also lists a site's most requested URLs over the last minute or the last 5 minutes, with each one's share of the site's requests, next to its busiest client addresses and networks; query strings are never shown.

• Fixed (Windows): "Who is sending it" on the Traffic page works on servers installed before October. On some older installations the console was not allowed to read visitor details from the WAF engine, and the Traffic page wrongly said the engine was not running. PortWall now repairs that permission by itself when it updates or restarts, and if it is ever missing again the page says what is wrong.

• Updates no longer interrupt your sites when the WAF engine has not changed. Most releases change only the console and the services around it. Such an update now leaves the WAF engine running, so sites keep answering throughout instead of pausing for a few seconds (and for several minutes on a server with hundreds of sites). PortWall still watches the engine after the update and puts the previous version back if it does not stay healthy. Windows also no longer records the hand-over as a service that "terminated unexpectedly". This takes effect for updates installed from this version onwards.

• Fixed (Windows): the engine memory limit takes effect when you apply it. Setting the limit under Global WAF Defaults, Advanced and restarting the engine could leave the engine running with the old limit until the server was rebooted. The limit is now written where the engine reads it at every start, so the restart you ask for is enough. The page shows the limit you saved next to the limit the engine is actually running with, and it no longer waits for the restart to finish: on a server with hundreds of sites the restart takes several minutes, and the page used to give up with a timeout error before it was done.

• Fixed: saving settings on a server with many sites no longer times out or silently does nothing. Saving Global WAF Defaults (Advanced limits, the request rate limit, exclusions), a site's settings, a certificate mode, a virtual patch or a bot or API protection change used to wait for the new configuration to reach every site before answering. On a server with hundreds of sites that took longer than the console would wait, the save appeared to fail, and the new setting was never written to the engine. A save now answers at once and is applied in the background; a banner at the top of every page shows that it is being applied, and says why if it could not be.

• Fixed: portwall-admin diagnose explains a struggling engine. It now reports an engine that is out of memory (it used to call one at twice its memory limit "not under strain"), a memory limit saved in the console that the engine is not running with, a WAF inspection or upload limit saved but not yet applied, when the engine last reloaded its configuration and whether that worked, and an engine too busy to answer its own status request - instead of skipping those checks.

• Fixed: the setup no longer prints the admin password again when you upgrade. The password is shown only when the setup creates the admin account. On an upgrade it tells you where the saved initial credentials file is and to delete it once you have recorded the password.

• Fixed: an update that is still being installed is no longer shown as failed. The part of PortWall that asks for an update is restarted by the update itself, and on a slow or busy server it could write "update failed" in the moment it was stopped, even though the installation went on and finished. The failure then stayed on screen until PortWall had finished starting again. A failure is now recorded only when the installer really reports one, and a failure that was written while the installer was still working is taken back.

• Fixed: Update Status no longer calls a server that is still starting up a failure. After an update on a server with many sites, the WAF engine needs several minutes to load every site, and during that time Update Status reported the configuration as not applied and left the check marked as failed until you ran it again. It now says that PortWall is still starting up and for how long, keeps checking by itself, and finishes green once the configuration is applied. A start-up that really does not finish is still reported as a problem.

• Fixed: PortWall no longer restarts a WAF engine that is still starting up or is just slow. On a server with many sites the engine can take several minutes to load every site after it starts, and under heavy load it can answer slowly. The engine's health check treated both as the engine having stopped, raised "not serving" alerts and restarted it, which began the long start-up again. The check now allows a start-up time that grows with the number of sites, tells a slow answer from no answer at all, and warns about a slow engine instead of restarting it. An engine that has genuinely stopped answering is still restarted.

• New: see who is sending a site its traffic. The Traffic page has a new Who is sending it section: pick a site (or click one under Busiest right now) to see its busiest client addresses and networks over the last minute or the last 5 minutes, with each one's share of the site's requests, and the requests the site is working on right now - who sent them, the page asked for, and how long each has been running. Query strings are never shown. Only PortWall itself can read these details from the WAF engine; other programs on the server, such as the websites it hosts, cannot.

• Fixed: other programs on the server can no longer see which visitors overload protection refused. The list of refused visitors, with their addresses and the pages they asked for, could be read by any program running on the server - on a shared-hosting server, by any customer's website. Only PortWall can read it now. Other programs can still read how many requests were refused, but not by whom.

• Fixed: high CPU on servers with many sites when requests are blocked. Every request that PortWall refused - a blocked attack, a rate-limited client, a browser check - cost far more processing than it should, and the cost grew with the number of sites on the server. On a server with several hundred sites, a burst of traffic could drive the CPU to its limit and slow every site down. A refused request now costs the same small amount however many sites the server has, and only real login attempts are written to the login-protection log.

• Fixed (Windows): uninstalling removes PortWall's own Windows Firewall rules. The rules the setup adds to let web traffic in ("PortWall data plane") stayed in Windows Firewall after an uninstall. They are now removed with the rest of PortWall. Firewall rules you created yourself are never touched.

• Choose whether PortWall installs updates for you. Update Status (and System on the appliance) now has an Automatic updates setting with three choices. Tell me is what PortWall has always done: a banner says an update is available and it is installed when you press Install. Install automatically installs each new release by itself, but only while your maintenance window is open, and only releases that have been made available to everyone (the Stable channel); a release that cannot be installed on your server is not tried again by itself, and PortWall says so on Protection Status. Don't tell me hides the banner. Nothing changes until you choose: every server starts on Tell me. Windows servers now have a maintenance window too, set on the same page. And if a newer release has been waiting for more than 30 days and has not been installed, Protection Status now warns you, whichever choice you made.

• Fixed: an update that is put back is reported as put back. When an update did not come up healthy, PortWall restored the previous version correctly - but Update Status could still say the new version had been installed. It now shows that the update was rolled back, why, and every step that was taken.

• Fixed: a release whose WAF engine will not stay running is put back within seconds. PortWall used to give the new version a minute and a half before restoring the previous one, with the websites behind the server failing for that time. It now restores the previous version as soon as the engine has stopped and been restarted twice.

• Fixed (Windows): the WAF engine is no longer interrupted at midnight. The service that runs the WAF engine could stop while rotating its own logs at midnight, leaving the engine to run unmanaged until PortWall noticed about 30 seconds later. Those logs now rotate by size, at 100 MB, so nothing happens at midnight. The change applies at the engine's next start (this update restarts it).

• Fixed (Windows): uninstalling removes everything PortWall added to IIS and Plesk. The module that lets your sites see each visitor's real address stayed registered in IIS after an uninstall, and on a Plesk server PortWall's internal address stayed hidden from Plesk's IP pool. Both are now removed.

• Very old Windows versions are asked to use the setup. An update offered to a server on a version older than 1.2.0 now says to install it with the PortWall setup, which brings an older installation up to date in one step.

• New PortWall virtual patches now arrive within minutes of being published, without an update. When PortWall publishes a patch for a serious new flaw, your server picks it up on its own, checks it, and adds it to every site; nothing restarts and you do not install anything. It appears on the Virtual Patches page with the same switches as the others, and a notice - "New PortWall virtual patch PW-... for CVE-... is now protecting N sites" - is recorded under Operational Events and sent as an alert email. Protection Status warns when the patches have not been refreshed for more than 3 days and reports an error if they run out or a patch could not be loaded.

• A Virtual Patches page, for the patches PortWall adds and the ones you write. The new Virtual Patches entry in the menu has two tabs. PortWall patches lists the patches PortWall has added for serious current flaws - the PHP2Shell protection is the first, PW-2026-0001 - with the CVE, how severe it is, on how many of your sites it is in force, how many requests it matched in the last 24 hours, and a switch for every site. Open a row to see what it refuses, the real fix, and each site with its own switch. Your patches lists the patches you wrote for individual sites, across all sites, where you can add, promote, demote and delete them. A site's own page now shows one line - how many PortWall patches are in force and how many of your own - with a link here, and Global WAF Defaults links here instead of carrying the protection's switch. Once a flaw's protection becomes part of the WAF rules in a later release, it leaves the PortWall patches tab and your on and off choices carry over.

• Fixed: an address you unblock is not blocked again on its next request. Unblocking an address removed the block but kept the risk score that had earned it, so a single further failed login or flagged request blocked it again at once. Unblocking now clears that score too, and also takes the address off the browser-check list, so it is judged afresh from then on.

• Fixed (Windows): removing a port on Management Ports also closes it in Windows Firewall. The firewall rule PortWall added to let a passed-through port in stayed after the port was removed from the list. PortWall now removes its own rule within about ten minutes of the port being removed. Firewall rules you created yourself are never touched.

• Fixed: saving Management Ports through the API refuses a field it does not recognise. A misspelt or unknown field used to be ignored without a word - for example, sending the allowed addresses under the wrong name saved the port open to every address. The save is now refused, and the message names the field.

• Fixed: turning off Enforce geo-blocking now turns off every geo policy. With the switch off, the firewall stopped blocking the listed countries, but policies applied inside the WAF - and the web-traffic part of policies that let certificate checks through - stayed in force. Depending on the policy, visitors from those countries were still refused, or each of their requests was recorded in the Attack Feed. Now nothing is blocked or recorded for any geo policy while the switch is off, and turning it on or off takes effect straight away.

• Fixed (Windows): upgrading by running the installer again no longer leaves the WAF engine stopped. When the installer was run over an existing installation, it could ask the WAF engine to start again while it was still finishing its shutdown. Windows refused, so the engine stayed stopped and the sites behind it were unreachable until the service watchdog started it a few minutes later. The installer now waits for the engine to stop completely before starting it again. Updates installed from the console were not affected.

• Fixed (appliance): the update history records the restart's boot check. After Restart now, the history ended at "restarting to switch to system B". It now goes on to record that the new system copy started and passed its boot check.

• Fixed: a newly added site's login protection starts within seconds. Failed logins on a site added in the last half minute were not counted yet, and changing a site between Detect and Block could take as long to take effect. A new site now counts failed logins from the very first one, and a change between Detect and Block applies within a few seconds.

• Fixed: a site keeps its own built-in protection choice. A built-in protection turned on on a site's own page, while it was already on for every site, was not remembered, so turning it off later under WAF defaults turned it off for that site too. A site now keeps the choice made on its own page, on or off, whatever is chosen for every site afterwards.

• Fixed: every page shows times in your time zone. The Attack Feed, Blocks and other pages that update by themselves still showed times in the server's own zone - UTC on the appliance - even with a time zone set. They now use the same zone as the rest of the console, on the appliance and on Windows.

• Fixed (appliance): a site in Detect no longer gets its visitors blocked. A detection on a site set to Detect could still block the visitor's address at the firewall, because the appliance did not recognise which site the request was for and treated it as a blocking site. A site in Detect now only records what it would have done, as it always should have; a site set to Block blocks as before. Failed SSH logins to the appliance itself are still blocked, as they protect the appliance and not a site.

• Appliance: a reminder on every page until the appliance restarts after an update. An update applied without a restart is in effect at once, but its own system copy only takes over when the appliance next restarts. Until then every page now says so, with a Restart now button, and the System page offers the same button. Before, only the System page mentioned it.

• Built-in protections are now shown in the console, with a switch. The PHP2Shell protection added in 1.2.23 was in force on every site but appeared nowhere. Each site's page now has a Built-in protections section above its virtual patches, showing what the protection refuses, whether it is on for the site, and how many requests it matched in the last 24 hours, with a switch to turn it off or on for that site. Global WAF Defaults has the same switch for every site, the dashboard shows on how many sites it is in force, and a new help page explains it.

• Protection against PHP2Shell (CVE-2026-109618 and CVE-2026-109619). These two critical flaws in PHP itself, disclosed on 21 October 2026, let an attacker run code on a server through a crafted form post or upload to any PHP page. Every site now refuses the requests these attacks need: a form that carries PHP's upload-progress field, or one with far more fields, files or nested levels than any real form. A normal form or upload is not affected. Updating PHP is still the only complete fix; this protects a server until then. Each rule can be turned off for one site by excluding it on the site's page (rules 1000014 to 1000017).

• Fixed: the browser check page identifies itself as PortWall, like every other page PortWall answers.

• New: Management Ports page. Control panel ports such as SolidCP's 9001, 9002 and 9003 can now be passed through on the server's public address from the console, under Network → Management Ports. The page suggests the ports your IIS sites use, lets you limit who can reach each port, and checks each one live, including whether Windows Firewall lets it in. Until now this could only be set during setup.

• "Connect to origin over HTTPS" works for sites with no HTTPS binding in IIS. When you turn it on for such a site, PortWall adds an HTTPS binding for the site's host names itself, on its internal address only and with its own internal certificate, instead of asking you to add one in IIS first. Visitors still get the certificate PortWall serves today. Bindings the site already has are not changed, and uninstalling PortWall removes the bindings and the certificate it added. Windows only.

• Appliance: change many sites at once, and see every site's certificate at a glance. Tick sites on Sites to change their protection mode, certificate, plain-HTTP redirect, CMS preset, login protection or status together; the change is applied in one step and is undone for every site if it cannot be applied. Each site now shows its certificate as one badge - valid with the days left, expiring, pending, failed, wrong certificate or HTTP only - and opening a site shows each hostname's certificate, issuer, expiry date and, when a certificate could not be issued, the reason the certificate authority gave. A filter box and a "Needs attention" view find a site quickly on a busy appliance.

• Fixed (appliance): the console shows times in the appliance's time zone. With a time zone set on System, most pages still showed times in UTC. Every page now shows times in the appliance's time zone, and changing it takes effect at once.

• Login brute-force protection is now on for every site, with nothing to set up. Until now a site was protected only once its login page had been typed into its settings. PortWall now finds a site's login pages by itself (such as /login, Login.aspx, /Account/Login or /wp-login.php) and steps in after repeated failed logins. First, that address is shown a short automatic browser check on the login pages, and only there: a person who mistyped passes it in a moment and carries on, and so does everyone else sharing the address (an office, a hotel, a mobile network), while a password-guessing tool cannot pass it. If the failed logins continue, the address is blocked. Logins from apps and scripts, which cannot show the check, are blocked straight away. The addresses being checked are listed on Brute Force. It follows the site's protection mode: a site in Detect only reports the address it would have blocked, in the Attack Feed. To watch one particular login page instead, or to turn it off for a site, use the Login protection setting on the site.

• Fixed: restarting or updating PortWall no longer blocks addresses for failed Windows logons from the past day. Each time PortWall started it read the last 24 hours of failed Windows logons again, counted them as if they had all just happened, and blocked dozens of addresses for half an hour on failures up to a day old. It also added those failures to the Attack Feed a second time. PortWall now carries on from where it stopped reading, and failures it reads back after a restart count only as much as they would have had it seen them as they happened, so an address still attacking while PortWall restarted is still blocked. The log line for a brute-force block now says what triggered it instead of "evidence (null)".

• Fixed: turning threat feeds off now stops their blocking. Switching threat feeds off stopped them being refreshed, but the last list stayed in force, and was put back each time PortWall started. Turning them off now removes their blocking within about half a minute, on Windows and on the appliance, and turning them back on applies them again straight away.

• Fixed: an attack seen during an update is no longer lost. A block PortWall decided while the part of it that programs the firewall was restarting for an update could fail, and the event behind it was dropped. PortWall now tries again for a few seconds until it is back.

• Fixed: updating no longer needs a restart for geo blocking to move to the faster method. After the update to 1.2.19, a server could keep blocking countries with its old Windows Firewall rules until PortWall was restarted. PortWall now notices when the part of it that enforces geo blocking has been updated or restarted and applies geo blocking to it again straight away, and it checks regularly that what is in force is still what it last applied.

• Fixed: the number of geo blocking filters in force is right while an update is tidying up. The Geo page and portwall-admin diagnose counted the old Windows Firewall rules still being removed after an update as if they were filters in force; they now show the filters, and diagnose mentions the old rules separately.

• Fixed: going back to a release before 1.2.19 no longer leaves geo blocking behind that it cannot remove. When this installer puts back an earlier release - a failed upgrade it rolls back, or an earlier release installed with it - it first removes the geo blocking filters, which that release cannot see, and that release then sets up geo blocking its own way. portwall-admin diagnose now warns when geo blocking filters are in force while geo blocking is off or no country is blocked, and says how to clear them.

• Fixed: threat-feed and Herd Immunity blocking update in seconds. Updating the threat feeds or the Herd Immunity list now takes about a second instead of minutes, changes only the part of the list that changed, and takes effect all at once with no moment unprotected. Like geo blocking, it is now enforced by Windows at the network layer, so it no longer appears as rules in the Windows Firewall console: portwall-admin diagnose shows what is blocked. It stays in force across restarts. After updating, the threat-feed and Herd Immunity rules earlier versions put in Windows Firewall are removed in the background once the new blocking is in place, and uninstalling PortWall now also removes the Herd Immunity rules earlier versions left behind.

• Fixed (appliance): uploads are answered at once while ClamAV updates its signatures. While ClamAV reloads its signatures after an update, uploads are scanned by the YARA rules and the webshell detection without waiting for it, and by ClamAV again as soon as it is back. Before, uploads in that minute could be held for several seconds, and with several at once some were let through without being scanned at all. The Upload Scanning status now shows how many uploads were scanned without ClamAV, and when. An appliance with 8 GB of memory or more keeps scanning with ClamAV while it reloads.

• Appliance: add or remove SSH keys in the console. Paste a public key on SSH Access to let it log in over SSH, or remove one, instead of giving it through the setup seed - a key is far too long to type on the appliance's own screen. The page shows each key's type, comment and fingerprint and whether SSH is running; a key the setup seed added can be removed there too and stays removed.

• Fixed: the engine uses less memory on busy servers. Per-site traffic counting no longer grows with every host name visitors send: each site now has one small counter, so the engine's memory stays the same however much traffic arrives. The Traffic page now lists the busiest sites by site name rather than by host name, and its "since startup" figures no longer start again each time the configuration is published.

• Fixed: geo blocking applies in seconds, even with many countries. Turning geo blocking on, or adding or removing a country, now takes about a second instead of many minutes, however many countries are blocked, and the change takes effect all at once with no moment unprotected. Geo blocking is now enforced by Windows at the network layer instead of as rules in the Windows Firewall console, so it no longer appears there: the Geo page and portwall-admin diagnose show what is in force. It stays in force across restarts from the moment Windows starts. After updating, the geo rules earlier versions put in Windows Firewall are removed in the background once the new blocking is in place. A policy that lets certificate checks through now also blocks protocols other than TCP and UDP from the blocked countries.

• Fixed: the Geo page's "last applied" time is when the update finished. It used to show when the update started.

• Geo blocking: let certificate checks through. Let's Encrypt and Google Trust Services check a certificate by connecting to your server from several countries they do not announce, so blocking a country at the firewall could stop PortWall-managed certificates being issued or renewed. A new option on a firewall geo policy, Let certificate checks through, blocks those countries on the web ports inside PortWall instead, letting only the certificate checks through; every other port stays blocked at the firewall. It is off unless you turn it on. When a managed certificate fails while a geo block could be the reason, the TLS / SSL certificates page and portwall-admin diagnose now say so.

• Fixed: saving a site on the TLS page is quicker and shows what was saved. Changing only a site's HTTPS redirect or Connect to origin over HTTPS no longer requests its certificate again, which took several seconds, and the confirmation of what was saved now stays on screen alongside the certificate's progress instead of being replaced by it.

• Fixed: geo blocking with many countries took hours to apply, and slowed blocking while it ran. Adding or changing countries now updates the firewall in minutes, changes only the rules that changed, and never delays the blocking of attackers. Geo blocking also needs far fewer firewall rules: countries blocked the same way share rules, so a server blocking 100 countries has hundreds of geo rules instead of thousands.

• Fixed (appliance): blocking a country or an address no longer cuts the appliance's own connections to it. A geo block or an IP block also dropped the replies to connections the appliance made itself - to a backend server, for updates and licensing, or for certificates - so a site whose server is in a blocked country stopped working. Only connections that start from a blocked address are dropped now.

• Fixed: PortWall never blocks the services it depends on. The addresses PortWall uses for updates and licensing, and those of the certificate authorities it orders certificates from, are now never blocked - not by an automatic block, a manual block, a threat feed, Herd Immunity or a geo block.

• Fixed: geo blocking stopped applying new countries when there was more than one geo policy. With several geo policies, PortWall could fail to update the firewall, so countries added later were not blocked although the Geo page showed them as enforced. Every country is now applied, and the Geo page and portwall-admin diagnose say so if the firewall could not be updated, naming the countries that are not blocked yet. PortWall also tries again automatically.

• Sites: connect to the site over HTTPS inside the server. A new per-site option on TLS / SSL certificates, Connect to origin over HTTPS, has PortWall pass a site's HTTPS visitors to the site's own HTTPS binding in IIS instead of plain HTTP, for apps that need to see HTTPS themselves. It fixes ASP.NET sign-in and form pages that failed with an error behind PortWall, and apps that kept redirecting to HTTPS. The site needs an HTTPS binding in IIS; Windows only.

• Fixed: adding or removing a host name in IIS no longer resets the site's settings in PortWall. When a site's host names changed in IIS, PortWall started the site again from its defaults: a site with a PortWall-managed certificate went back to reusing the panel's certificate, and its HTTPS redirect choice and other HTTPS settings were lost. The site now keeps its certificate and HTTPS settings, and only its host names are updated.

• Fixed: the engine uses much less memory on servers with many sites. After updating to 1.2.15, a server with hundreds of sites could see high CPU use, because the engine needed far more memory and spent much of its time freeing it. It now uses about as little as before 1.2.15, however many sites the server has. portwall-admin diagnose also now warns when the engine is at its memory limit and struggling, and says how to raise the limit.

• API Protection: methods and route limits per site. The new API Protection page (under Detection) lets a site whose API uses PUT, PATCH or DELETE allow them - until now PortWall refused them on every site - and gives any route its own rate limit, such as a login, a token endpoint or a search, counted per address or per TLS fingerprint.

• API Protection: cross-origin rules (Premium). A site can now have PortWall answer which other websites' pages may call its API from the browser. Report only lists the calls from origins you have not allowed in the Attack Feed; Answer and enforce answers the browser's questions for the origins you list, replaces the site's own answers, and refuses the rest. A visitor sent back to your site by a payment provider is never affected, and these browser questions are never shown the browser check.

• API Protection: check requests against your API's specification (Premium). Upload a site's OpenAPI document (JSON or YAML) and PortWall checks each API request against it: the endpoint and method exist, required parameters are present and of the right type, and the body has the documented shape. Requests that do not match are reported in the Attack Feed with the reason - for example "body.quantity must be an integer" - or refused. Requests to endpoints the document does not list are only reported unless you choose to refuse them too.

• API Protection: sign-in token checks (Enterprise). A route can now require a valid sign-in token (JWT) before the request reaches the site: the right issuer, audience and claims, not expired, signed with your sign-in provider's keys, which PortWall fetches and keeps current. Tokens signed with a shared secret are supported on the routes you choose. A request without a valid token is reported, or refused, with the reason in the Attack Feed - for example "expired 3 minutes ago".

• API Protection: GraphQL limits (Enterprise). A GraphQL endpoint can now be protected from queries built to overload it: too deep, too many aliases or fields, too many operations in one request, or too long. Schema queries (introspection) are refused unless they come from addresses you list.

• API protection findings never block anyone on their own. A request the API checks report - for example from an app version that sends an older request format - is shown in the Attack Feed and does not count towards blocking the address or towards bot detection.

• Fixed: report-only findings now reach the Attack Feed. A geo policy in audit mode, a virtual patch still on trial, and failed logins recognised by a message on the login page were recorded only when the site answered with an error, so most of them were never shown, and failed logins recognised that way did not lead to a block. They are now always recorded.

• Fixed: a site with the WordPress protection preset stopped every configuration change from taking effect. With the preset on any site, PortWall built a configuration its web service refused, so changes saved in the console - on any site - were not applied, and the server went on running the configuration from before. Changes now apply again.

• Fixed: each site's own login and spam limits apply to it. With the WordPress or forum preset on several sites, the limits of one applied to all of them, and a site's own limits did not take effect. Each site is now counted against its own limits.

• Fixed: a site's login path now catches login brute force. Giving a site a login path (for example /wp-login.php) was meant to count failed logins on it and block an address that keeps failing, but it did nothing unless a configuration-file setting was added by hand. It now works as soon as the path is set, on Windows and on the Linux appliance. Only requests to the login page are recorded, and a site without a login path is unaffected.

• Linux appliance: login & spam protection on Sites. Editing a site now has a Login & spam protection section, as the Windows product has: the WordPress or forum preset, which limits the login, comment and sign-up pages and, for WordPress, blocks xmlrpc abuse and the listing of user names; its rate limits; and the site's login page, so failed logins on it lead to a block. The Sites list shows each site's preset and login page.

• Bot Protection: a browser check you can turn on. The new Bot Protection page (under Detection) can ask every visitor to one site, to chosen sites or to every site to pass a short browser check before the site answers - for a site under attack. A real browser passes in well under a second and is then left alone; bots, scrapers and attack tools that cannot run JavaScript do not get through. Nothing is sent to anyone else. Search-engine crawlers (Google, Bing, Apple, DuckDuckGo) are recognised by the addresses they publish and never checked, nor is your allowlist, certificate renewals, or the paths you list for APIs, webhooks and apps.

• Detections now act on a bot spread over many addresses, and on credential stuffing. Until now these two detections only reported what they found. By default the addresses involved are now shown the browser check for an hour; on Bot Protection you can block them instead, choose how long, or go back to only reporting. Sites in detection mode are only reported, and your allowlist and search-engine crawlers are never challenged or blocked.

• TLS fingerprinting can be turned on in the console. Bot Protection has the switch that lets PortWall recognise one program behind many addresses by the way it opens encrypted connections.

• Fixed: a threat-intel feed set to Challenge now challenges. A feed whose action was Challenge sent its addresses nowhere unless a configuration-file setting was added by hand, so they were neither challenged nor blocked. They are now shown the browser check, as the action says.

• Linux appliance: a year of CPU, memory, network and disk history. The charts on System showed only the last ten minutes, and started again whenever the console restarted. The appliance now keeps its CPU, memory, network and disk use for a year, through restarts and updates, and the charts show the last 10 minutes live, or the last hour, 24 hours, 7 days, 30 days or year. Each point is the average over its stretch, with a dashed line for the highest reading in it, so a short spike during an attack still shows on a 30-day chart. Time when the appliance was off shows as zero. Below the disks, the page says how full the fullest disk got over the chosen stretch.

• Fixed: "check for updates" answers in seconds. On a server or appliance that was already up to date, the button took about a minute before it said so. It now answers as soon as the check is done, usually within a few seconds, and says plainly whether a newer version is available, you are up to date, or the update service could not be reached.

• Linux appliance: a time zone setting. System now has the appliance's time zone. The maintenance window is set in it, ClamAV's nightly signature update runs shortly after midnight in it, and the System and ClamAV pages show their times in it. Until you set one, an appliance with a maintenance window keeps that window's time zone, and one without uses UTC.

• Linux appliance: a ClamAV page. ClamAV in the menu shows whether ClamAV is running, the signatures it has loaded, how much memory it uses, and its signature updates. You can update its signatures now, start, stop or restart it, or turn it off - it then stays off across restarts, and uploads are scanned by the YARA rules and the webshell detection only.

• Linux appliance: ClamAV updates its signatures once a night. Instead of checking every hour, the appliance now updates ClamAV's signatures once a night, shortly after midnight in the appliance's time zone, when traffic is lowest. After each update ClamAV pauses for about a minute to reload its signatures; uploads are still scanned by the YARA rules and the webshell detection in that minute. The Upload Scanning card shows when the next update runs, and whether the last one failed. An appliance whose signatures are more than two days old updates straight away. This update changes the appliance's base system, so it is installed in the maintenance window, or when you choose to restart the appliance.

• Uploaded files are scanned before they reach your sites. Every file uploaded to a site PortWall protects is now scanned while the upload waits: by the antivirus - Windows Defender on Windows, ClamAV on the appliance - by the YARA rules on Malware Rules, and by PortWall's webshell detection. A file any of them finds malicious is refused, and the refusal appears in the Attack Feed; the file itself is never kept. It is on by default. Scan & Quarantine (on the appliance, Upload Scanning) shows whether scanning is working, with what, and what it has blocked, and the status panel warns if it stops - for example if the antivirus is not answering, or the appliance's ClamAV signatures have not been updated for three days. Only the first part of a request is inspected, 2 MB unless raised under Global WAF Defaults › Advanced, so a file further into a larger upload, or a single file over 25 MB, is passed without being scanned.

• Linux appliance: ClamAV. The appliance now runs ClamAV for upload scanning and keeps its signatures up to date by itself from ClamAV's servers over HTTPS. ClamAV holds its signatures in memory, so an appliance now needs 4 GB of memory. A new appliance downloads its first signatures within a few minutes of starting; until then, uploads are scanned by the YARA rules and the webshell detection. This update changes the appliance's base system, so it is installed in the maintenance window, or when you choose to restart the appliance.

• Linux appliance: Secure Boot. The appliance and its installer now start on computers and virtual machines with Secure Boot turned on, such as new VMware ESXi virtual machines. Until now, Secure Boot had to be turned off before the installer would start. An appliance that updates to this version can then also be restarted with Secure Boot on. This update changes the appliance's base system, so it is installed in the maintenance window, or when you choose to restart the appliance.

• Linux appliance: the installer shows each step on its own screen. The installer now shows PortWall's name above each of its three steps - the disk, the network and the installation - and a bar showing how far the installation has got.

• Fixed: the appliance's boot menu shows its artwork on machines without a serial port. On a computer or virtual machine without a serial port - which VMware ESXi virtual machines have unless one is added - the installer's boot menu and the appliance's start-up screen appeared as plain text instead of PortWall's artwork.

• Fixed: on the appliance, the console's protection settings now take effect. Global WAF Defaults (its exclusions, noisy-rule tuning, rate limiting, request limits and timeouts), Trusted Proxies, and the certificate authority and contact email on TLS / SSL were saved, but the appliance went on protecting its sites without them. They now apply to every site as soon as they are saved. An appliance that never set its certificate authority keeps getting its certificates from Let's Encrypt, as before.

• Linux appliance: herd immunity. The appliance now joins PortWall's threat-intelligence fabric as PortWall for Windows does: it receives the blocklist built from attacks seen across PortWall's network and blocks those addresses, as part of an appliance licence that includes it. Herd Immunity shows its state. Sending what this appliance sees back to the network stays off unless you choose it.

• Fixed: a configuration backup now includes Global WAF Defaults. Backup & Restore left out the global exclusions and noisy-rule tuning, the rate limit, and the request limits and timeouts, so restoring a backup, or moving to a new server, lost them. They are now in every backup, and on the appliance so are its sites. A restore now takes effect straight away. A backup made with an earlier version still restores.

• Fixed: the appliance has a country database. On the appliance, Geo-blocking said no GeoIP database was configured, and countries were missing from reports. The appliance now downloads the database itself, as PortWall for Windows does, and keeps it up to date.

• Linux appliance: tune each site. Each site on Sites now has a Tuning link, to the site's own page: rule exclusions for that site's false positives, which of the global exclusions it does not use, virtual patches, and its revision history. The protection mode can be changed on either page, and both show the same.

• Fixed: publishing or rolling back one site no longer affects the others. On a server with several sites, publishing one site, or rolling a site back to an earlier revision, rebuilt the WAF's configuration with only that site in it, so the other sites were no longer protected. The whole configuration is now rebuilt, with every site.

• Linux appliance: TLS / SSL shows what applies to the appliance. The page now holds the certificate authority, its contact email and the staging switch that every automatic certificate uses. Each site's own certificate is chosen on Sites.

• Fixed: the appliance's Sites and Network pages lost their buttons. A moment after the page opened, the Add site, Edit and Remove buttons on Sites, and the controls on Network, disappeared, so there was no way to add a site from the console. They now stay.

• Fixed: the audit log names the operator who made a change in the console. Changes made in the console were recorded under the console's own service key instead of the name of the person signed in. They are now recorded under that person's name. This also fixes setting up two-factor authentication on My Security, which could answer "No operator identity".

• Change your own password. My Security now lets every operator, whatever their role, change their own password: enter the current one and the new one twice. An administrator still sets another operator's password on Users.

• Linux appliance: reset a forgotten password from the appliance's own screen. The appliance's screen has a new menu item, Reset the console's administrator password. It gives the administrator you name a new password, shown once on the screen, makes them an enabled administrator and turns off their two-factor sign-in, so an appliance whose only administrator is locked out no longer needs reinstalling. Being at the appliance's screen is the proof that you may, as it is for the setup code.

• Linux appliance: the console shows only what applies to the appliance. Pages that only mean something on a Windows server - Set up PortWall, Scan & Quarantine, Port Scans, Egress, Campaigns, JA4 Throttles, Host Hardening, Self-Service Policy and Update Status - are no longer in the appliance's menu, and an old link to one opens the appliance's own page for the same job. Brute-force describes SSH logins to the appliance and no longer offers Windows log sources, Notifications no longer offers alerts the appliance never sends, and the Overview counts the appliance's own sites.

• Fixed: the Traffic page on a new appliance. Before its first site is added, the page said traffic statistics were unavailable because the WAF could not be reached. It now says the appliance has no sites yet and links to Sites.

• Linux appliance: network settings. The installer now asks how the appliance joins your network: automatically from a DHCP server, or a static address with its gateway and DNS servers. Afterwards, addresses can be added, removed or changed on the appliance's own screen - which now shows a menu with its addresses, the console's address and the setup code, instead of a login prompt - or on the new Network page in the console, where you also choose which addresses the WAF answers on. A change made in the console is tried first: unless you keep it within two minutes, the appliance goes back to the settings it had, so a mistake cannot leave the console out of reach.

• Linux appliance: PortWall from start to finish. The appliance's boot menu, its start-up screen, its own screen and its SSH greeting now show PortWall's name and artwork. This update changes the appliance's base system, so it is installed in the maintenance window, or when you choose to restart the appliance.

• Linux appliance: licences by CPU core. An appliance licence now covers a number of CPU cores: virtual CPUs on a virtual machine, physical cores on a physical server. PortWall inspects traffic on that many cores and leaves the rest of the server to the operating system and the console. System shows how many cores the server has, which of them inspect traffic and how busy they are, and the Licence page shows how many your licence covers. When the licence is extended, the new core count applies within a minute, without a restart. The status panel warns when the licensed cores are nearly fully busy. A trial covers 2 cores.

• Choose your update channel. Update Status now lets you choose which releases this server is offered: Stable, releases that have been tested and made available to everyone, or Testing, new releases as soon as they are published. Every server starts on Stable. Updates are still installed only when you approve them.

• Blocking now needs this server's own current licence. PortWall's web service blocks attacks only while this server holds a licence or trial that PortWall issued to it and, on Windows, only while its program files are the ones PortWall released. Otherwise it keeps serving your websites and keeps detecting and recording attacks, but does not block them, and the status panel shows a critical licensing problem with the reason. A new installation starts blocking as soon as it has contacted PortWall's licence service for the first time; until then it only detects. A licence that has expired or been suspended now stops blocking when its grace period ends.

• Fixed: after a restart, protection follows the licence straight away. If the licence ended, or was activated, while PortWall's services were stopped, the web service could carry on blocking after the licence had ended, or carry on only detecting after it had been activated, until the licence next changed. PortWall now checks the licence as it starts.

• Fixed: the Traffic page no longer says "traffic report could not be read" just after an update. For a few minutes after an update, until the web service picked up its new settings, the page could show this error instead of the numbers. It now shows the numbers throughout.

• Fixed: the appliance activates its licence and is offered updates. The appliance did not activate the licence key you gave it and did not contact PortWall, so it was never offered updates. It now activates the key at first boot, keeps its licence current and is offered updates like PortWall for Windows.

• Sites that are not behind the WAF are now pointed out. The Sites page listed every site PortWall found in IIS the same way, whether or not its traffic went through the WAF. A site PortWall cannot protect - for example one whose IIS binding has no host name, so visitors cannot be told apart from other sites' - looked like any other. Such sites are now marked Not protected on the Sites page, with the reason and what to do, and listed at the top of the page. The status panel warns when one stays that way for more than two minutes, and the diagnostic lists them.

• Fixed: a site added in IIS is protected within seconds, and shows the right website. PortWall noticed a new IIS site only on its once-a-minute check, and needed more than one check to finish setting it up, so a new site took minutes to appear on the TLS/SSL page. In the meantime it could show the IIS default page instead of the website, because IIS was not yet answering for it on the address PortWall forwards to. PortWall now notices a change to IIS within a few seconds and adds that address to the new site straight away, alongside the site's own addresses, which are left unchanged.

• Traffic now shows bandwidth, connections and active requests. Alongside requests per second, the Traffic page shows how much data is flowing in and out right now, in the last hour, the last 24 hours and since the web service started, for the whole server and for each site. It also shows new connections per second, how many connections are open, and how many requests are being handled at this moment, with charts of the last ten minutes. Data received per site is an estimate: an upload that does not state its size counts as its headers only. HTTP/3 connections are not counted.

• Fixed: the Traffic page no longer slows the web service on a server with many sites. To show its numbers, the page read the web service's full statistics every five seconds - on a server with hundreds of sites that is a large amount of work each time. It now reads a short summary instead. Two people viewing the page at once also no longer see the rate drop to zero.

• Traffic history is now kept for 90 days. The hourly traffic history was never cleared and grew without limit. Hours older than 90 days are now removed.

• Appliance: CPU, memory, network and disk usage. The appliance's System page shows CPU use and load, memory and swap, network traffic on each interface and how full each disk is, with charts of the last ten minutes. The status panel warns when the appliance's data disk is 85% full and reports a critical problem at 95%, before it fills and the appliance can no longer record attacks or save settings.

• Fixed: an update could roll itself back on a busy server. When an update changed how PortWall stores its settings, two of PortWall's services both made that change as they started. On a busy server one of them could fail to start, and the update then put the previous version back. The services now take turns, so the update completes.

• Fixed: log rotation changes in an update apply straight away. Some changes an update made to how logs are rotated only took effect the next time the web service restarted, so until then a log kept rotating the old way. They now apply as part of the update.

• Fixed: an address you add to the allowlist is protected straight away. PortWall picked up a new allowlist entry on its next refresh, up to 30 seconds later, so an address added just before it tripped a block could still be blocked. PortWall now checks the allowlist again before blocking any address.

• Fixed: Brute Force no longer reports Windows logon attacks as undetected on a busy server. On a server with a lot of other activity - many websites, or a database recording failed logins all the time - the status check looked only at the most recent events, so Windows logon attacks (RDP, SMB) detected a few hours earlier were missed and the check said none had been detected, even though the attack feed showed them. It now counts the whole last 24 hours.

• Fixed: Herd Immunity no longer shows a critical error on a Standard licence. With a Standard licence, your server shares the attacks it sees with the PortWall network, and receiving the network's blocklist is part of Premium. The status page reported this as an unrecognised, critical problem. It now says plainly that the server is contributing, and that receiving the blocklist needs Premium.

• Logs are now rotated daily and compressed. Every PortWall log - the web service's logs, the attack log, and the logs of PortWall's own services - starts a new file each day at midnight, and sooner on a busy day once a file reaches 100 MB. Older files are compressed (to a few percent of their size) and kept for 30 days. The attack log no longer grows into a single multi-gigabyte file, which could slow down how quickly attacks were acted on. The web service's console log switches over the next time the web service restarts. The diagnostic reports whether logs are rotating.

• Faster attack inspection. PortWall now checks requests against its attack rules with a much faster pattern-matching engine. On the same hardware it handles about half as many again of typical web traffic and about twice as many form submissions, and responds faster under load. What is detected is unchanged: every build is checked against the full set of attack test cases and must flag exactly the same requests. The web service uses about 100 MB more memory.

• Fixed: some attacks naming file paths were not detected. The rules that catch attempts to read system files (such as /etc/passwd), reach restricted files (such as a site's .git/ folder) or run Unix shell commands did not fire when the attempt contained a path written with forward slashes, so those attempts got through unless another rule caught them. They are now detected and blocked.

• Fixed: Smart Tuning exclusions now work on ASP.NET WebForms fields. WebForms names its form fields with $ separators (for example ctl00$ContentPlaceHolder1$msg_txt). Smart Tuning cut the name off at the first $ and suggested an exclusion for ctl00, a field that does not exist, so after you applied it the rule kept blocking. Smart Tuning now suggests the full field name. If you applied a suggestion like this before, apply the corrected suggestion and remove the old one.

• Fixed: attack details show which field a rule matched, even for HTML content. When the matched text contained a quote (almost any HTML, such as charset="utf-8"), the attack details showed nothing under Matched, and when the matched text was long, the field name was cut off. Either way you could not see which field to exclude, and Smart Tuning could not suggest an exclusion. The field name is now always kept.

• Fixed: an exclusion that could never work is now refused when you save it. An exclusion limited to a page or a field takes one rule id or one range, such as 941000-941999. A list such as 921130 941190 was accepted but excluded nothing (or only the first rule), so the rule kept blocking. Saving one now explains what to enter instead, and the site and Global WAF Defaults pages show the reason a save was refused instead of a bare error code.

• Fixed: the incident for an HTTPS-only fault now says what happened. When HTTPS stopped accepting new visitors while plain HTTP still answered, the incident, the log and the audit trail said the web service "has not answered" - pointing at the wrong problem. They now say HTTPS stopped taking new connections while plain HTTP still answers.

• Fixed: attackers are blocked within a second of their attack, even on a busy server. On a busy server, or one with email alerts set up, blocking a new attacker could lag several seconds behind the attack: sending the alert email held up the decision, and attack records were processed more slowly than a busy server produces them. Alerts are now sent alongside the decision instead of in front of it, and attack records are handled many times faster. The diagnostic also reports how quickly attacks are being acted on.

• Fixed: on Plesk servers, the diagnostic no longer reports the Plesk panel as unreachable when PortWall is serving it. Since PortWall began serving the Plesk panel itself (so the panel's logs show each visitor's real IP), the diagnostic still looked for the older connection relay, reported the panel as unreachable from outside, and advised re-running the setup — while the panel was working. It now checks the panel directly on the address PortWall serves it on, and reports a real problem only when the panel does not answer.

• PortWall now notices when HTTPS stops accepting visitors, and recovers by itself. PortWall's health check restarts the web service if it stops answering. It used to check only plain HTTP, so a fault that left HTTPS unable to accept new visitors while plain HTTP still answered went unnoticed until someone restarted the service by hand. The health check now also confirms that HTTPS is accepting new connections on every address PortWall serves, and if it is not, restarts the service automatically within about two minutes.

• Fixed: changes are applied on the first attempt. About every other change, the web service turned away PortWall's first attempt to load it, so the change only took effect on an automatic retry a few seconds later. Every change now loads first time.

• Fixed: saving a change no longer interrupts your websites. Every change PortWall applies — adding or editing a site, a rule, an exclusion, a certificate — is loaded into the running web service without a restart. On a busy server, applying one could leave that service unable to accept new visitors until it was restarted, and a few requests in flight at that moment could fail. Changes now take effect with no interruption: open connections are kept, new visitors are accepted throughout, and no request is dropped.

• Setup and handing the web ports over now follow one guided, verified path. Whether you protect the server during guided setup or hand the web ports over later from the Sites page, PortWall uses the same checked procedure every time: it proves it is serving every site — and that remote management stays reachable — before it commits, and if anything isn't right it returns the server to IIS automatically, with every binding and certificate intact. Setup is a single resumable flow, and stepping a server back to IIS is done the same verified way wherever you start it.

• The real visitor IP now reaches IIS and your applications. Behind PortWall, IIS and the applications on it used to see PortWall's internal address as the client. PortWall now installs a small server-wide component so every website's access log (the c-ip field) and every application (REMOTE_ADDR, and frameworks such as PHP and ASP.NET) record the real visitor address — automatically, for current and future sites, with no per-site configuration. A request that reaches IIS directly, not through PortWall, can never forge its logged address. The component is removed cleanly when PortWall is uninstalled.

• Exclude a false positive on a cookie or header, not just a form field. When a rule wrongly matches on a cookie or a request header, the exclusion can now be aimed precisely at that cookie or header — not only at query-string and form fields as before. The exclusion editors (on a site and under Global WAF Defaults) now have a Where choice — query/form field, cookie or header — so the rule keeps inspecting everything else.

• Fixed: a protected server now recovers on its own after a reboot. On a protected server, after a restart Windows could leave the internal web listener and the management-port relays unbound — even with every service running — so websites returned 502 and remote management (WinRM) was unreachable until someone intervened by hand. PortWall now checks shortly after it starts and, if the server isn't serving its internal address, re-establishes those listeners automatically.

• Plesk panel logins now record the visitor's real IP address. The Plesk control panel is now served through PortWall, so its logins and access logs show the real client address instead of the server's internal one — essential for tracing who reached the panel if an account is ever misused. Its certificate, sign-in, two-factor prompts and live screens keep working exactly as before. This applies from the moment a Plesk server is switched over; where the panel's certificate cannot be reused, the panel keeps working unchanged.

• Fixed: a renewed or newly-issued certificate is now served without a restart. When a site's certificate was renewed or replaced (for example issuing a Let's Encrypt certificate for a site that started on a self-signed one), PortWall could keep serving the old certificate until its services were restarted. The new certificate is now picked up and served on its own.

• Plesk: setup no longer asks about webmail and shared hostnames. That question is for servers where a single default website answers webmail, autodiscover and other hostnames that have no site of their own. Plesk gives every hostname — webmail included — its own website, so on a Plesk server the step does not apply and is skipped.

• Plesk: setup confirms Plesk was detected. On a Plesk for Windows server the setup page now shows that Plesk was detected and PortWall is running in Plesk support mode, and the control to turn Plesk's own web application firewall off is available there during setup, not only afterwards.

• Fixed: uninstalling now fully removes PortWall's internal network adapter. When uninstalling, PortWall's internal network adapter could be left behind — disabled and inert, but still listed. It is now removed completely, and the uninstaller confirms it is gone.

• Fixed: uninstalling over remote PowerShell could stop half-way. An uninstall started from a remote PowerShell (WinRM) session could cut off that session part-way through and stop with the services removed and no site answering. The steps that end a remote session now run last, after everything else is done.

• WinRM comes back on servers that were already protected. Servers cut over before the WinRM relay existed now get it automatically after updating - no second cutover needed. PortWall checks shortly after it starts and every few hours, adds only what is missing, and never interrupts a remote session that is already connected. On a Plesk server the same check restores the Plesk panel ports.

• Plesk: one web application firewall, not two. Plesk runs its own web application firewall inside IIS, on by default. With PortWall in front every request was inspected twice and Plesk blocked on its own - those blocks never reached PortWall's attack feed and PortWall's exclusions did not apply to them. On a Plesk server the Sites and Global WAF Defaults pages now show Plesk's firewall setting with a button to turn it off (and back on), and diagnose warns while it is on.

• Plesk: certificates for mail and the panel keep renewing. Plesk issues Let's Encrypt certificates for names no website uses - mail. for the mail server, and the server's own hostname for the panel. PortWall now passes those validation requests to Plesk for any hostname, so they renew as they did before PortWall.

• Plesk support. PortWall now recognises a Plesk for Windows server and switches to Plesk support mode automatically. HTTPS is passed to IIS over HTTPS and plain HTTP is passed through untouched, so Plesk keeps handling its own HTTPS redirects and Let's Encrypt renewals; webmail and the Plesk panel stay reachable; and PortWall's internal address is kept out of Plesk's IP list. The on-box diagnose report has a Plesk section that checks each of these.

• WinRM keeps working after cutover. PowerShell remoting (WinRM) used to stop answering on the server's public address once PortWall took over the web ports. PortWall now relays it, unchanged and still fully authenticated, to its new home, reachable from the addresses on your allowlist (or your local network if the allowlist is empty).

• Sites keep their HTTPS certificate when it doesn't name the site. When a site's certificate in IIS doesn't carry the site's own name (common for webmail and control-panel defaults), PortWall now serves the same certificate IIS did, instead of serving that site without HTTPS.

• The diagnose report now says when a detection source has stopped. If PortWall stops reading one of its event sources (for example the WAF event log), portwall-admin diagnose now names it, says those events are not being recorded, and gives the step to recover — instead of only a line in the log.

• Fixed: a new installation logged errors before it had been set up. In the first seconds after installing, the logs reported that sites were unreachable and that the release was not in effect, although nothing had been configured yet. Those messages now appear only when something is really wrong.

• Attack summaries shared with PortWall threat intelligence. Servers that contribute to herd immunity now also send a short summary of each address that attacked them — how often, which kinds of attack (for example SQL injection or brute force) and whether it was blocked. These summaries build the repeat-offender intelligence behind the upcoming PortWall Premium Threat Intelligence. Nothing about your sites leaves the server: no site names, page addresses, request content or visitor data, and your allowlisted, private and internal addresses are never included. It uses the same setting as herd-immunity contribution, so turning that off stops both.

• PortWall plans: Standard, Premium, Business and Enterprise. Protection from herd immunity (attackers already confirmed across the PortWall fleet, blocked before they reach you) and the Smart Tuning Advisor (formerly "Suggested exclusions") are included with the Premium, Business and Enterprise plans, which have the same features and differ in their support terms. On the Standard plan a server still contributes the attackers it confirms to herd immunity. Your plan is shown at the foot of the menu and on the Licence page, and each premium feature says what it requires. Everything else — the WAF, blocking, scanning, managed certificates, rate limiting, overload protection and the built-in threat-intelligence feeds — is unchanged in every plan.

• Fixed: a newly installed server did not record WAF events until it was restarted. On a fresh installation the attack feed stayed empty — and attacks were not used for automatic blocking — until the PortWall services next restarted (for example after an update). Attacks are now recorded from the first request.

• Fixed: saving several settings in quick succession could leave one of them not applied. Configuration changes are now applied one at a time, and a change the data plane did not pick up is retried automatically.

• ASP.NET WebForms preset — much less CPU on WebForms sites. WebForms pages send large page-state fields (__VIEWSTATE, __EVENTVALIDATION) with every postback, and checking them against every rule is where most of the WAF's CPU goes on those sites. ASP.NET already signs and verifies those fields itself, so for the sites you choose under Global WAF Defaults → Exclusions → ASP.NET WebForms preset, PortWall skips them (every other field is still fully inspected), turns off the Java and PHP attack rules that cannot apply to an ASP.NET site, and stops re-scanning the raw body of ordinary form posts whose fields are already inspected one by one. In our tests this cut the inspection work for a typical postback by up to about 40×. Select only ASP.NET WebForms sites.

• Per-site timeouts. The response and upload timeouts on the Advanced tab apply to every site, and the response timeout is a hard deadline — it cuts a request that is still working, unlike IIS's idle timeout. When one application legitimately needs longer (a long import or report), you can now give just that site, or just its slow pages such as /import, a longer deadline under Global WAF Defaults → Advanced → Per-site timeouts, instead of raising it for every site on the server.

• See who overload protection would refuse. The Overload protection panel now lists the visitor addresses, sites and pages that were refused — or, in Measure mode, would have been — with how often and when. Check it before switching to Enforce: if they are your own users (an app sending several large requests at once, an office behind one address), raise the per-visitor limit or allowlist them first.

• Overload protection. Inspecting a large form or API request takes a lot of memory while it is being checked, so a burst of them — even a small burst, well within the rate limit — could exhaust the server and take every site down. PortWall can now cap how many of these heavy requests are inspected at once, for the whole server and per visitor. Ordinary page loads and small forms are never affected; allowlisted addresses are exempt. It starts in Measure mode, which changes nothing and simply shows what it would have done, so you can check your real traffic first. Switch to Enforce under Global WAF Defaults → Advanced → Overload protection: extra heavy requests then wait their turn, and only if they can't get in within the wait time does the visitor see a short "server busy, please retry" page. Its live status is shown on the same page and in the on-box diagnose report.

• Set the WAF inspection limit in KB. On the Advanced tab of Global WAF Defaults, the WAF inspection limit now has a KB / MB choice, so you can set a limit below 1 MB (for example 256 KB) instead of whole megabytes only.

• Choose how far back "Suggested exclusions" looks. The Suggested Exclusions tab now lets you analyse either the last N WAF events or the last N days — pick whichever fits and set the number. On a busy server a fixed event count can only reach back a few hours, so "last N days" helps surface a false positive that only fires occasionally. The page also tells you how many events it analysed and roughly how long a span they covered.

• Turn off the HTTP → HTTPS redirect for a single site. By default a site served over HTTPS redirects plain HTTP visitors to the secure address. On the TLS / SSL page you can now switch that off for an individual site, so it answers over both plain HTTP and HTTPS — for a legacy client, a health check or a callback that has to reach it over http://. HTTPS keeps working exactly as before, and the choice is per-site, so every other site still redirects.

• Per-argument inspection cap (big efficiency win, on by default). Some apps put bulk data in form fields — a large HTML table, an embedded document — and inspecting those against the full rule set makes the engine work far harder than the request rate suggests (high CPU and memory for only a handful of requests). PortWall now skips inspecting any single field larger than 128 KB by default: that field is passed for that request, every normal field is still fully inspected, and the heavy cost disappears. Normal fields are far smaller than 128 KB, so most sites are unaffected; an app with genuinely large legitimate fields can raise or turn it off, and a stricter site can lower it, on the new Advanced tab.

• Advanced tab for engine tuning. Global WAF Defaults now has an Advanced tab that gathers all the host-wide engine settings in one place — request body size, the WAF inspection limit and oversize-body handling, connection/response timeouts, the per-argument cap, and the engine memory limit. Each setting is labelled by whether it applies instantly or needs a brief engine restart; the one that needs a restart (the memory limit) is applied with its own button so you choose when.

• Automated false-positive tuning — "Suggested exclusions." A new tab on Global WAF Defaults analyses recent traffic and finds rules that are false-positiving on a specific field — for example an injection rule matching an uploaded file (a PDF or image) carried in a form field. For each one it shows why it looks like a false positive and offers a ready-made, scoped exclusion you review and apply in one click — either just on that path, or for that field everywhere. Nothing is excluded automatically, and the rule keeps protecting every other field and endpoint. (Available on advanced licence tiers.)

• Request limits and timeouts are now in the console. A new Request Limits & Timeouts page lets you set the maximum upload size, how much of a request body is inspected, what happens to bodies larger than that, and the connection/response timeouts — all from the console, applied to every site on the next publish. No more editing configuration files on the server.

• Every button now shows it's working. When you press an action button it immediately shows it's running (and can't be pressed twice), so on a busy server you're never left wondering whether your click registered while the change is being applied.

• A confirmation before anything disruptive. Actions that can interrupt live traffic — cutting over to PortWall, returning the ports to IIS, taking the bind address, or switching every site's protection mode at once — now ask you to confirm first and name exactly what will happen, so a mis-click can't take a site offline.

• The Sites page is split into Sites and Setup. Everyday work — changing a site's protection mode, editing policy, searching the site list — stays on the Sites tab. The one-time, host-level setup steps (discovery and fronting, cutover, the bind address, the loopback origin, provisioning defaults) now have their own Setup tab, so the controls you use daily aren't mixed in with the ones you touch once.

• Global WAF Defaults split into tabs. Exclusions, noisy-rule tuning and rate limiting each have their own tab now, so the page is quicker to navigate.

• Tune false positives with one click. The Global WAF Defaults page now lists the rules matching most across your recent attack feed. If one is tripping on legitimate traffic, click Exclude and it's added to the defaults and applied to every site — no need to hunt for rule IDs. (Scoring rules are left off the list; they fire on every request and aren't false positives to exclude.)

• Adjust port-scan sensitivity from the console. The Port scans page now lets you loosen, tighten or turn off port-scan detection — how many ports or dropped packets count as a scan, the window, and the quiet period after a detection — if it's flagging legitimate traffic like a monitor or load balancer. Changes apply within about 30 seconds, no restart.

• Automatic rate limiting (on by default). PortWall now caps how many requests a single visitor IP can make per minute (default 1200), shedding scanners and bots with a quick 429 before they reach the inspection engine — so a busy site, or one you're running in monitor mode, can't be overwhelmed. It acts purely on request volume, never on what a rule matched, so it can't block a real visitor over a false positive; allowlisted addresses and your trusted proxies are exempt. Tune the limit or turn it off under Global WAF Defaults → Rate limiting.

• Data-plane memory ceiling. On a server where RAM is tight (for example shared with other web software), you can now cap the amount of memory the data-plane engine uses so it can't crowd out everything else. The on-box diagnose report shows the engine's current memory and the ceiling in force.

• Change protection mode for selected sites — including Off. On the Sites page you can now tick individual sites and set them all to monitor, blocking, or off in one step, instead of only all-at-once. Off turns the WAF off for the chosen sites (with a warning first) — for the occasional application that genuinely can't run behind it. Per-site mode is still editable on each site.

• Clear all temporary blocks at once. The Blocked IPs page has a new button to flush every automatic and timed block in one click, while keeping the permanent blocks you set by hand — useful after you've tuned away a false positive that auto-blocked a batch of real visitors.

• Diagnose now reports the data plane's memory. portwall-admin diagnose shows the engine's resident memory (and, when per-site traffic counting is on, how many distinct site names it is tracking), so "is its memory healthy?" is answerable on the server itself.

• Excluded Attack Feed. The Attack Feed page has a new tab showing hits that matched a rule you've excluded — logged for visibility so you can see what your exclusions are catching, and never blocked. It fills for sites in monitor (Detection) mode; in blocking mode an excluded rule is removed outright, so it won't appear there.

• Tune a false positive once for every site. A new Global WAF Defaults page lets you add a rule exclusion that applies to every site at once — so a rule that mis-fires across your whole fleet (for example on ASP.NET endpoints that send an empty JSON body) is fixed in one place instead of site by site. Any individual site can turn an inherited default off for itself, from its own page.

• Switch every site to monitor or blocking in one click. The Sites page can now put all your sites into monitor mode (log attacks, block nothing) or blocking mode at once — handy for rolling PortWall out in monitor mode first, then enforcing once the attack feed looks clean. Per-site mode is still editable on each site.

• Serve HTTP/3. You can now turn on HTTP/3 (QUIC) for your sites from TLS defaults. PortWall frees UDP 443 from Windows and serves it itself; because that involves Windows' own HTTP/3, the server needs one reboot after you enable it, and HTTP/3 then activates on its own. It's off by default.

• Client fingerprinting now covers HTTP/3. Fingerprint-based blocks and rate limits previously applied only to TCP connections; they now cover HTTP/3 (QUIC) traffic too, so an HTTP/3 client can't sidestep them.

• Choose your certificate authority — including one that works on older devices. Managed certificates are issued by Let's Encrypt by default. You can now switch to Google Trust Services instead, whose certificates are trusted by older phones and devices (for example Android 6 and 7) that reject Let's Encrypt. Google Trust Services is free but needs a one-time account credential you create with Google's Public CA API; paste it into TLS defaults and every managed certificate is issued from Google Trust Services from then on. See TLS / SSL certificates.

• The TLS page now tells you when a site's existing certificate can't be reused. If a panel-issued certificate can't be imported (its private key isn't exportable), the site's certificate column says so plainly and points you to switching it to a managed certificate, instead of leaving the field blank.

• Turn on HTTPS across many sites at once — safely. Select your sites and PortWall enables managed (Let's Encrypt) certificates in paced waves that stay under the certificate authority's rate limits, holds back any site whose DNS doesn't point here yet, and tells you up front roughly how long it will take. It keeps going on its own and survives a restart. See TLS / SSL certificates.

• Update verification. After an update, PortWall now confirms it actually landed healthy — the new version is running, every service is up, permissions are in place, and the configuration has been delivered — and if something didn't finish it says exactly what to do, instead of a version number quietly never changing. See the Update Status page.

• A manual page for TLS / SSL. The in-console manual now covers the TLS/SSL certificates page in full — certificate modes, DNS pre-checks, the bulk rollout, webmail routing and admin-console HTTPS. See TLS / SSL certificates.

• Guided, verified setup. Setup now runs as one ordered flow that checks the live result of each step before moving on, and only takes the web ports once everything before it is proven — so a half-finished setup can't take a site offline. See Set up & cut over.

• Webmail and shared apps stay reachable. During setup PortWall asks what should answer for hostnames with no site of their own — webmail, a control panel, phpMyAdmin — serves the one you choose over HTTPS, and confirms its DNS points to this server before requesting a certificate (so a mispointed name can't burn the certificate authority's retry limit).

• Windows-account brute-force protection is on by default. RDP, SMB and network-logon password-guessing is caught out of the box — you no longer have to switch it on — and a fresh install immediately reflects the last 24 hours of attempts. See Brute-force detection.

• Mail-server log presets. For mail brute-force detection, pick hMailServer, MailEnable or SmarterMail and PortWall fills in the log location and matching pattern for you (or choose Other for a custom log).

• Faster setup. Your server's address is filled in automatically during setup, so there's less to enter by hand and less to get wrong.

• In-console manual. This help section — how-to guides for every feature and a full command-line reference — ships with the console, so it always matches your version.

• Two-factor authentication. Add a one-time code from an authenticator app to your sign-in, per operator, with recovery codes for a lost device. See Two-factor authentication.

• API keys. Create keys for scripts and integrations, each with a role, and revoke them from the console — no more sharing a login. See API keys.

• Backup & restore. Export your whole configuration to one file and import it back, for disaster recovery or moving to a new server. See Backup, restore & migrate.

• Better alert email. You can now add several recipients, each filtered to the alert types they care about; give the server a name that appears in every alert so you can tell your servers apart; set a threshold so noisy low-score WAF hits don't page you; and send a test before saving. See Notifications.

• Delivery you can trust. If alert email stops being delivered, PortWall now tells you — on the dashboard, the errors panel and the Notifications page — instead of failing silently.

• Protection status at a glance. Every security feature now shows whether it is not just enabled but actually enforcing, with a top-right panel that lists anything that needs attention. See Protection status.

Fixed

• Linux appliance: updates could be refused with "no release trust bundle loaded". An appliance could refuse a newer version it had downloaded, because it had nothing to check the release's signature against. The appliance now carries what it needs to check updates itself. Appliances already in service have been fixed without an update: if an update was refused this way, approve it again on System.

• A server whose settings file was edited is no longer reported as a modified installation. PortWall keeps your own settings files when it updates. If one of them had been edited on the server, PortWall's check of its program files counted it as changed after the next update, and kept reporting the installation as modified. Settings files you are allowed to edit are now left out of that check; every program file is still checked.

• An update in progress is no longer reported as failed. While an update was being applied, the Update Status page could say "did not complete ... the installed version did not change", and then clear the message a minute later once the update had finished. It now shows the update as in progress until it has actually finished or failed.

• Rate limits with exceptions or page-specific limits no longer stop the web service. From version 1.2.5, PortWall's web service could not start on a server where a rate limit had an exception - addresses on the allowlist or verified search-engine crawlers - or applied to particular pages, as the WordPress and forum protection presets do. A server set up like this stopped serving its websites after updating. The web service now starts with every setting the console can produce, and every release is checked against all of them before it is published.

• An update now puts the previous version back if the web service does not stay running. An update counted as successful once the console answered, even if the web service kept stopping and restarting. It now also waits until the web service has stayed running, and if it does not, restores the previous version.

• An update can no longer leave the old web service running. On a busy server, an update could replace PortWall's files while the previous version of its web service was still running. That old copy went on serving your sites with the settings from before the update, used a lot of CPU, and stopped any change you made from taking effect, while the new copy restarted every few seconds. PortWall now makes sure the old copy has stopped before it updates, and ends a copy left running like this by an earlier update.

• Diagnose reports geo blocking correctly. It said geo blocking was switched off when you had switched it on in the console.

• Linux appliance: the disk space check works. The status panel said "the appliance's disk usage could not be read" on every appliance, so it would not have warned you before the disk that holds your settings, certificates and attack history filled up. It now reads the disks and warns at 85% full.

• The engine memory limit can now be applied from the console. On Global WAF Defaults → Advanced, "Apply memory limit & restart engine" was refused with "'dataplane.memlimit' is not available to the API account". It now applies the limit and restarts the engine. The limit must be 0 (no limit) or at least 256 MB.

• A damaged API-key file can no longer lock you out of the console. A malformed or duplicated entry in the API-key file is now skipped instead of making every console and API request fail.

• Rate limiting now counts real visitors behind a CDN or load balancer, and honours the allowlist. If your sites sit behind trusted proxies (a CDN or load balancer you have configured), the per-visitor rate limit was counting every visitor as the proxy's address, so they all shared one limit and a busy period could throttle everyone. It now counts each real visitor. Addresses on your allowlist (WAF scope) are now genuinely exempt from the rate limit, as the console said they were. Without a valid licence, rate limiting and overload protection's refusals now stay off as intended (detection continues).

• Much lower, steadier data-plane memory on busy servers. On servers handling forms or API calls with many fields, the data-plane engine's memory could climb to several gigabytes and stay there even when traffic was light, because memory used to inspect large requests was never released. It is now released as soon as each request finishes, so memory follows your current traffic instead of the heaviest requests seen since the last restart. No settings to change; protection is unaffected.

• Task Manager now shows the data plane as PortWall. The data-plane process now identifies itself as PortWall in Task Manager, Services and the file's properties.

• No more "PortWall is restarting" when you return to a background tab. A console tab left in the background could lose its connection, and switching back showed a "PortWall is restarting" message even though nothing had restarted. The console now keeps the connection much longer and picks up where you left off; if it does need to reconnect, it says so plainly and recovers straight away. The restarting message now appears only when the server really is not answering, for example during an update.

• Switching a site to a managed certificate now works even under a wildcard. If a site was covered by a wildcard certificate that another site on the same domain loads (for example a *.example.com panel certificate), setting that site to a managed (Let's Encrypt / Google Trust Services) certificate used to silently have no effect — the engine kept serving the wildcard. A managed site now obtains and serves its own certificate regardless, and prefers it over the wildcard. Sites still using the panel/wildcard certificate are unaffected. (Note: after upgrading, any site already set to "managed" that had been quietly served a covering wildcard will begin obtaining its own certificate.)

• Large uploads no longer strain memory or get rejected as "too large." The protection engine now inspects a request body only up to a set size and lets larger uploads (for example Excel imports) pass through, instead of buffering and scanning the whole thing — so big uploads keep working and the engine's memory use stays bounded. The maximum size, the inspection limit, and whether to allow or reject oversized bodies are all adjustable on the new Request Limits & Timeouts page (defaults: accept up to 10 MB, inspect up to 2 MB, allow larger). Raise the maximum for apps that upload large files.

• A saved change no longer says "not picked up yet" when it already applied. Saving an exclusion, a noisy-rule exclude or a bulk mode switch could show a confusing "the data plane has not picked this up yet" even though the change had already taken effect. The console now checks whether the engine is already serving your change before showing any such message, and when a change genuinely is still being applied the wording makes clear it happens automatically within about a minute, with nothing for you to do.

• The Attack Feed now reads as a true timeline. The feed could appear to "skip" a stretch of attacks — they were in the store and showed up when you searched the IP, but weren't in the list — if the engine was reloaded while attacks were arriving (for example right after switching every site to blocking mode). The cause: the feed was ordered by when each event was recorded rather than when it happened, and a reload can briefly make recording lag behind. It now always orders by event time, so nothing goes missing from the timeline.

• "The data plane has not picked this up yet" no longer appears for a routine save. On a busy server, applying a change (a bulk protection-mode switch, a global exclusion) runs a full reload that occasionally couldn't reach the engine for a moment and reported that the change hadn't applied — even though the engine was healthy and the change landed on its own shortly after. Reloads now retry a brief hiccup, so saves apply straight away; a genuinely stopped engine or a mid-cut-over is still reported as before.

• Excluded rules now land in the Excluded Attack Feed, not the main one. A false positive you'd excluded still showed up in the main attack feed whenever it fired alongside the WAF's internal anomaly-scoring rule (which is almost always) — so only one standalone rule ever reached the Excluded feed. Suppressed hits are now routed correctly, and the scoring rules are ignored when deciding whether a hit is fully excluded.

• Monitor mode no longer bans visitors. A site in monitor (Detection) mode now never auto-blocks a visitor's IP — it logs what it sees for review without enforcing. Previously the detections from a monitored site could still accumulate and block an address, which could ban real visitors from a site you only meant to observe.

• Site changes now take effect immediately. Saving a site's settings — its protection mode, rule exclusions or virtual patches — now applies to live traffic straight away, instead of being saved but left waiting for a separate "publish" step that the console never actually offered a button for. If the data plane can't apply the change that instant (for example during the initial switch-over), the console says so and it applies as soon as it can.

• A hostname with no DNS record no longer blocks a site's certificate. If a site has a name — often a www. subdomain the control panel created but DNS never had — with no DNS record, PortWall now leaves that one name out of the Let's Encrypt request instead of letting it fail the whole certificate and trip the hourly rate limit. The names that do resolve still get their certificate; a www. that doesn't resolve is simply skipped. If none of a site's names resolve yet, PortWall serves it over HTTP and waits until a DNS record exists rather than repeatedly failing — so issuance stays fast instead of taking many minutes.

• Upgraded servers cut over cleanly. When switching a server over to PortWall, the configuration is now regenerated for the version you're running just before the engine starts — so a server upgraded from an older build can't fail the switch-over on a stale configuration left from the previous version.

• Managed-certificate status tells you what's actually happening. After turning on a Let's Encrypt certificate, the status no longer freezes at "pending" or stops updating after two minutes with "may still arrive." It now shows a clear phase — waiting to start, issuing, issued, or failed (with the reason) — and keeps updating on its own until it resolves, so you never have to refresh the page to find out whether it worked.

• A setup switch-over can no longer get stuck. If the server restarted — or a PortWall service was stopped — while the switch-over was taking the web ports, that half-finished switch used to stay "in progress" indefinitely, blocking further configuration changes and needing manual recovery. PortWall now detects an interrupted switch-over on start-up, automatically returns the server to IIS, and settles it, so you can simply re-run setup. A stalled switch also can no longer block configuration updates.

• "Return traffic to IIS" can now override a stuck switch-over. The button gained an "override a stuck cut-over" option that clears a switch-over jammed "in progress" and stands the server back down to IIS — previously only possible by calling the API directly.

• The "Done" button on the completed setup screen now works. It was inert once setup finished; it now returns you to the dashboard.

• HTTP/3 keeps working after enabling it on an upgraded server. HTTP/3 (QUIC) runs over UDP 443, which needs its own firewall opening separate from the HTTPS (TCP 443) one. On a server updated in place — rather than freshly installed — that opening could be missing, so HTTP/3 was advertised but the traffic was silently blocked and browsers fell back to HTTP/2. PortWall now ensures the HTTP/3 firewall opening whenever HTTP/3 is enabled, so it works without any manual step.

• Port-scan detection recovers immediately after a reboot. A restart makes Windows recreate the firewall log with default permissions, briefly leaving port-scan detection unable to read it. PortWall now restores its access on a fast cadence right after boot instead of waiting for the next periodic check, so the brief "not enforcing" window after a reboot closes on its own in seconds.

• A finished update no longer shows a false "update did not complete" banner. Installing an update briefly restarts PortWall's services; the top-of-page update banner could latch onto that restart as a failure and keep saying the update didn't complete — on a server that had in fact updated correctly. The banner now reflects the version actually running, and a status left over from the restart corrects itself once the new version is up.

• Country/region blocking applies reliably for large blocklists. On a server blocking countries with very large address lists, the firewall rules could fail to program (leaving that blocking not enforced). The rules are now split so each stays within the size the firewall accepts, and one rejected slice no longer stops the rest — matching how the threat-intel blocklists are already applied.

• Setup no longer stalls at "Let PortWall take :80 and :443" on some servers. On a server where another service had reserved the UDP port used for HTTP/3, the data plane could fail to start and setup would hang with the sites offline. The data plane now serves over HTTP/1.1 and HTTP/2 and won't be taken down by that, so setup completes and the sites stay up. (HTTP/3 support is coming as a separate, opt-in step.)

• "Return traffic to IIS" always works, even after a stalled cut-over. Previously a cut-over that got stuck could refuse the revert that was needed to recover; you can now force the revert to return the ports to IIS.

• The data plane reliably restarts after an update. A leftover control socket from a previous run could stop the engine from coming back up cleanly; that socket is now cleared on restart.

• The Update Status page shows the correct running version immediately after an upgrade. After an in-place upgrade the page could keep showing an older version as "running" until you clicked Verify now, even though the rest of the console already showed the new version. It now reports the version actually running straight away.

• Onboarding no longer fails at "Publish the data-plane configuration" after an update. On a server updated in place, the account that writes the configuration could be left without permission to create it, so setup stopped with an "access denied" error. PortWall now re-establishes that permission on every start and after every update, so onboarding — including the first publish on a freshly updated server — completes on its own.

• "Update available" no longer shows for the version you're already on. After promoting a release (or right after updating), a server already running the latest build could briefly show it as an available update. The console now only flags an update when the offered version is genuinely newer than what's running, and a completed update clears its own offer.

• Setup completes the switch-over on a fresh server, unattended — it puts every site behind the WAF and takes the web ports without manual steps in between.

• The old setup wizard is retired in favour of the guided flow above; existing links open the new one.

• Clearing an optional log-file pattern now sticks on the Brute-force page, instead of reappearing after a refresh.

• Setup completes on more servers. Setting up PortWall on a new server no longer stops at the configuration step — it continues to the switch-over as expected.

• More of your SSL certificates are reused automatically, so more sites are served over HTTPS without extra steps.

• Fixed a fresh-install permissions issue that could stop PortWall applying its configuration.

• Alert email now delivers reliably once configured in the console. Previously alerts could stay silent even though a test message worked.

• Threat-intel feeds keep enforcing even when a feed contains a bad entry — the bad entry is skipped instead of stopping the whole blocklist.

• Brute-force status is accurate for RDP/SMB login attacks — it now recognises detections across each service instead of under-reporting them.

• Clearer messages throughout — the status cards read in plain English (no more "entr(y/ies)"), and the brute-force card makes clear when it means Windows-account attacks rather than web attacks.