Release Notes

Last updated: 2026-09-10

This page records only what you can see or will run into: screens, behaviour, and how upgrades work. Internal cleanups and tooling changes are not listed. The newest release is at the top.

From 2026-09-06 each part is released separately and carries its own version number. A heading names which one it is (for example "Hub"); headings with no name are the SvrGuard program on your own host.

1.0.24 · Hub 1.0.21 — 2026-09-12

Notification mail no longer uses emoji — the icons in the subject and at the top of the body are gone. Some receiving servers treat them as a spam signal, and an attack notice that lands in the spam folder is not a notice at all. The body encoding changed with it, so the same text is now readable in the raw message instead of looking deliberately obscured. The first line of a notification now reads Host: your machine name.
Notification mail can carry an unsubscribe target — a new unsubscribe key under [email] puts a URL or mailbox into the message's List-Unsubscribe header, which helps delivery. It is empty by default, and empty means the header is not sent — pointing it at something nobody acts on is worse than leaving it out. One-click unsubscribe is deliberately not supported: these are security alerts, and one stray click must not be able to silence a host.
The program no longer refuses to start when the database is not there — on Synology this left an upgraded host stopped dead — the previous release treated "the database file does not exist" as "the database is damaged". ⚠️ A Synology upgrade reaches exactly that state: when the installer finds the restored database damaged it sets it aside (which is right — the evidence has to be kept) and tells you the service will rebuild what it can on start-up — and the previous release's service would simply refuse to start, even with a good backup sitting beside it. On ordinary Linux hosts this was reached by pointing the configuration at a database of your own, or by restarting after the file had been deleted. Now: restore from the backup if there is one, so your host keeps its identity, and otherwise treat it as a first start and create a new one.
The last line of defence after a failed Synology upgrade now has something to fall back on — when an upgrade fails and DSM's own rollback fails too, the program is meant to put the previous executable back itself. ⚠️ That path had never once worked since 1.0.13: it read the wrong field when checking the version and compared the build number against the version, so it decided every time that the executable was not the one it wanted. When this actually happened, the host was left with no service running at all. The comparison is now correct and the executable goes back.
Synology DSM 7: package upgrades work — and until now not one of them ever had — our package was missing two control scripts DSM requires before it will upgrade anything, so DSM refused every time (error 261). ⚠️ It made no difference how the upgrade was started: Package Center, the console's update button, or the automatic check all ended the same way, and all the screen said was that the version had not changed. In practice a DSM 7 host could be installed but never upgraded, from the first Synology release onwards; the only way forward was to remove the package and install it again. The two scripts are now in the package. DSM 6 was never affected — it has always upgraded.
Synology DSM 7: failed SSH logins are detected — these hosts could not read that log before — on DSM 7 the program runs as an unprivileged user, and the system's authentication log is readable only by root. ⚠️ So on those hosts SSH attack detection had no input at all: it ran every five minutes, the console looked healthy, and what it read was always empty. The package now asks DSM for read access at install time, which is the mechanism DSM supports; the previous approach tried to take it from inside the installer, which DSM 7 does not permit. DSM 6 runs as root and could always read it. Website and firewall detection were not affected by this.
A host rescued that way now says so in its console — the rescue above has a cost: it puts the old executable back, but the package information cannot always be corrected (on DSM 7 it cannot). That leaves the host believing it is already up to date, so it stops updating, and says nothing about it. That state is now shown as a standing notice in the console, together with what to do about it: reinstall from Package Center. Hosts this never happened to see nothing.

1.0.23 · Hub 1.0.20 — 2026-09-10

Upgrading the Synology package no longer damages the database on your host — the backup taken during an upgrade copied files into the backup folder instead of replacing it, and a clean shutdown removes the database's write-ahead file — so the write-ahead file from the previous upgrade was restored alongside the new database. Paired together, the database was corrupt, and every step of the upgrade reported success. The backup is now a single file exported by the database itself, built beside the old one and swapped in only once it has fully succeeded.
When the database really is damaged, the host now recovers on its own — previously it simply failed to start, every time, with the reason only in the system log. It now restores from the backup, restarts, and says on the console what happened. If even the host's identity cannot be recovered it refuses to start rather than running with an empty database — that would quietly consume another one of your subscriptions.
Hosts that block with address sets no longer claim an IPv6 address is blocked — that layer used to build a set, attach a rule, and on failure leave a single log line, while the block list still showed the address as enforced. Such hosts now list IPv6 targets under "why this is not in effect", with the reason. Hosts using nftables are unaffected and continue to block IPv6. Old IPv6 sets are also withdrawn, rather than being left in the kernel dropping packets.
Hub: the duplicate-name notice now actually appears — the previous release said joining a fleet would warn you when a name is already in use, and that notice had in fact never appeared once: the query named columns that do not exist, and a failing query was read as "no duplicate". It appears now.
On DSM, asking whether an address is blocked now gives the right answer — the address-set name in that query was fixed, while these hosts actually use a different one — so it asked about a set that does not exist and then reported "this address is not enforced".
"Installed on" no longer shows the time of the last self-update — the two shared one field, so they always agreed, and could never show that they disagreed.
A host that has just joined a fleet now recovers by itself if the Hub rejects it — after the host rotates its key the Hub may still hold the old one, and every request is refused. That used to last until the next sync; the host now asks the Hub to re-read its identity as soon as it is refused.

1.0.22 · Hub 1.0.19 — 2026-09-10

Synology DSM 7: blocks now really do reach the firewall — and a correction to the previous note — 1.0.20 said installation "now obtains the privilege needed to write firewall rules". On DSM 7 that route does not exist: the package's own installation process has no authority to ask for it, so those machines were still detecting everything and writing not one rule. A small program that does nothing but firewall work now ships inside the package and performs the writes; the main program hands it a sync every 5 minutes. Measured on two physical NAS units (two processors, two kernel generations): the address count in the kernel matches the block list exactly.
On DSM, asking whether an address is blocked no longer reports "could not read" as "not blocked" — reading the block list needs privilege, and when it could not be read the answer was "this address is not enforced", together with a repair command that would have changed nothing. At that moment the address was in fact being dropped. It now says it could not look, and names what to ask instead.
A host will no longer hold a large set of blocked addresses that no rule ever consults — the check used to ask only whether the kernel could build an address set, never whether the firewall could point a rule at it. Those two can disagree, and every message still reported success. A rule is now actually inserted and withdrawn as part of the check; if it cannot be, a different blocking method is used.
With no notification channel configured, there is no longer a red banner on every page — the reason is now stated on the update page itself. Configuring an email address takes effect immediately, with no wait for the next day's check and no restart.
The dashboard's "firewall backend" line no longer trails a parenthetical when everything is fine — that reason is only needed when nothing can be blocked at all, and it is still shown in full then.
The console's version line now carries the build number — when two builds share a version number, that number is the only thing that explains why an update is still on offer; without it the row reads as if it contradicts itself.
The updating screen is no longer an unstyled white page — its styling used to be served by the very process that was restarting, which is what that screen exists to cover. The styling is now part of the page itself.
Hub: joining a fleet now warns when the name matches one of your own existing hosts — this notice never appeared before. It is a hint, not a gate (two hosts may legitimately share a name), and it is shown only when you are signed in, comparing only against your own machines — otherwise anyone holding the link could use it to probe whether a given name exists.

1.0.20 — 2026-09-09

A Synology NAS could not update itself, and the button looked fine — the package never wrote an update source into its configuration, so pressing "Update the program" only ever answered "No update source configured", and the daily automatic check stopped at the same place. A new install now carries the update source, and an existing NAS has it added the next time the package is installed. If you cleared it yourself, that is your setting and it is left alone.
On an ordinary Linux host the same situation used to report success — with no update source configured the screen said the update had started and put up the updating cover, while the program was never replaced at all; the failure went to the system log and nowhere else. Installation packages now always carry the update source.
With no update source, a button that could only ever refuse is no longer drawn — the row now says "No update source configured — this row cannot be updated" instead. When the source is merely unreachable for the moment, the button stays — that is temporary, and you need somewhere to try again.
On Synology DSM 7, blocks now actually reach the firewall — DSM 7 runs a package under a restricted account, and installation never asked the system for the privilege needed to write firewall rules. On those machines attacks were still detected and not one rule could be written. Installation now obtains it, and says so in the installation messages if it cannot rather than quietly falling back to watching only.
The DSM 7 packages are on the download page too — DSM 6 and DSM 7 need different packages, and the download page carried only the DSM 6 three, so a DSM 7 machine had no manual install path at all. Both generations are there now, for all three architectures. Check Control Panel → Info Center for the DSM version AND the CPU before installing — both have to match, and DSM refuses the wrong package outright.
On a host that changed blocking method, unblocking now takes effect — after a host moved from one address-set type to the other, the old IPv6 set stayed in the kernel and kept dropping packets while no longer appearing in any list — so "unblocked" and "still blocked" could both be true at once. The old set is now retired once the new one has taken over.

1.0.19 — 2026-09-09

Blocking now uses a kernel address set; until now every host fell back to one rule per address — there are three blocking tiers, and the middle one (ip_set) was probed with a request that left out a required field. Every host got the same error back, so that tier was never actually selected anywhere. With the request fixed, a host whose kernel has the feature now uses one rule plus one address set instead of a separate rule for every blocked address. What gets blocked does not change; the cost of matching does.
Kernels that only support single addresses — Synology NAS among them — can now use address sets too — those kernels ship only the "single address" set type, while we always asked for the "network range" type, so on those machines it could never succeed. The type is now chosen from what the kernel actually carries.
On such a kernel, blocking a whole network range does not take effect — and the screen now says so — a single-address set cannot hold a range. Such an entry used to be skipped silently while the console still showed it as blocked; it is now listed under "why this is not enforced", with the reason. Ordinary blocking is unaffected: detections and the threat feed produce single addresses. You only meet this if you block an entire range by hand.
The firewall backend line no longer contradicts itself — that sentence was hardcoded as "the kernel does not support nf_tables; fell back to ipset", while the tier actually chosen could be a different one, leaving the real reason in the brackets disagreeing with the first half of the same sentence. It now shows the actual reason only.

1.0.18 · Hub 1.0.18 — 2026-09-08

A host is no longer refused once by its own Hub right after it joins (Hub) — a host's identity is written on the management side, while the Hub recognises hosts from its own copy of it, and that copy only learned about a new host at the next sync. Measured at 18 seconds — and the host's next request falls inside those 18 seconds, so the join had in fact worked while the screen said it had failed. The Hub now brings its copy up to date before it answers the host.
When the join works but the sign-in that follows does not, it no longer says "binding did not complete" — both cases shared one sentence, and it left people thinking they had to bind the host again. It now says "joined the fleet, but this sign-in did not complete" and states plainly that binding again is not needed — signing in once more is. The host console's sign-in page keeps that explanation too, so it is still there after the dialog is dismissed.
The sign-in page says which host you are signing in for — after pressing "bind to my account" on a host, that page used to look exactly like an ordinary sign-in. It now lists the name the host reports, the hostname the host reports, and the source address the Hub saw, and says where each value came from — the first two are the host's own word for itself, not our assertion.

1.0.17 · Hub 1.0.17 — 2026-09-08

Two hosts with the same name can now coexist on a Synology NAS (Hub) — this is the item the previous entry said was still unresolved. Deciding whether two hosts were the same machine required both pieces of hardware identity to differ, and on a Synology one of them is always empty, so two of them were never different — the second host took over the first one's place, and every upload from the first was refused from then on, with no error shown on either side. That decision now uses an installation identifier the host generates for itself, and each host keeps its own name and history. A host that gets a new network card is still the same host and is not treated as a new one.
A refused connection no longer claims the host was disabled — a connection can be refused for several reasons, and the screen said "the Hub has disabled this host" for all of them. The most common reason is in fact that the name is already used by another host, so that sentence sent people looking for something that was not there. Both possibilities are now named, along with the one step that fixes either (bind the host again).
A host nobody signs in to now gets an identity of its own — the installation identifier was only created when somebody opened the console or bound the host again, so a host left alone after installation stayed known only by its name — and therefore always met the problem in the first item. The host now does this by itself, with nobody signed in.

1.0.16 · Hub 1.0.16 — 2026-09-08

Opening a site's front page is no longer treated as probing — the two rules that look for someone probing an admin site asked only which sites an address had touched, never what it asked for. A single visit to the front page already leaves two records (the plain HTTP request, then the redirect to HTTPS), and those two were enough for both rules to fire, so simply loading the site could get an address blocked for seven days. There now has to be at least one request for something an ordinary visitor does not ask for. The front page, icons, stylesheets and any address the site really does serve no longer count. Detection and blocking are not weaker: an address genuinely hunting for /wp-login.php or /.env is still caught.
A second host with the same name is no longer refused on every connection (Hub) — the Hub gives the second host of a duplicated name an identifier of its own, but that identifier never reached the host, so the host kept connecting under its old identity and every upload was rejected, with neither side saying why. It is now sent back to the host. Duplicate names on a Synology NAS are still unresolved; that has a separate cause and is still being worked on.

1.0.15 — 2026-09-08

Hosts that restart often now really do update themselves — the daily update check counted 24 hours from the moment the program started, so a host that restarts more than once a day (a NAS especially) never reached that moment: automatic updates looked switched on and had never once run, with nothing on screen to say so. The time of the last check is now recorded, and a check that is more than a day overdue is made up at start-up. If your host has been sitting on an older version with automatic updates on, this is why.

1.0.14 · Hub 1.0.15 — 2026-09-07

Hosts that share a name can now really both join — the previous release described this, and the host side of it was in place, but the Hub was not passing the host's identifier into the decision, so binding was still refused. Fixed: a second host with a duplicate name is now given an identifier of its own and joins normally. The host needs to be running this version or newer for it to apply.
When binding does not succeed, the reason is shown — on the screen where you pressed the button — it used to take you to another screen that only said "go back to the console and try again". That sentence tells you nothing, and following it does not produce a different outcome.
Two hosts carrying the same install identifier are told why — cloning a VM or restoring a backup copies the identifier along with everything else. That case used to produce an error with no explanation; it now says which host to unbind, or to reinstall.

1.0.13 · Hub 1.0.14 — 2026-09-07

Hosts that share a name can now both join your fleet — a host used to be identified by the name it reported, so two hosts with the same name (two boxes both called NAS, say) were treated as one: the second one failed to bind, and the first one could be displaced by it. Each host now generates an identifier of its own at install time, so a duplicate name no longer affects binding and both hosts are listed separately in your fleet. Names may still repeat — a name is only a label for you to read.

2026-09-07 — Changes to downloading and installing

The one-line install now picks the right package itself — a .deb where apt is present, an .rpm where dnf / yum / zypper is, and the tarball only when there is neither. The two package-manager paths resolve dependencies for you and put the binary at /usr/bin/svrguard.
Installing no longer asks you anything — log paths are detected, the service is registered and started, and the only thing left afterwards is binding the host to your account. If you would rather answer the questions yourself, install from the tarball by hand: unpack it and run sudo sh install.sh, which is now the only path that asks.
Hosts installed by an earlier one-line install are left on that path — those live under /opt/svrguard, and a package install cannot pick up their configuration or blocking history. The script detects them, stays with what is there, and says why.
On a Synology NAS the install script now refuses to run and tells you which .spk to use instead. DSM records the installed version in the package's own metadata, and a binary put there behind Package Center's back no longer matches it — with nothing failing along the way.
Four corrections on the download page — the command for checking that blocking is live, the DSM version Synology packages support, how the firewall back end is described, and the fact that the console has no separate admin password (you always sign in with your Hub account).

1.0.12 — 2026-09-07

Pressing "Update" no longer leaves you on a server error page — an update restarts the service, and for those few seconds the browser could previously land on a "Service Unavailable" page. It looked like something had gone wrong while the update was in fact proceeding normally. The "updating" screen is now drawn by the response to the button press itself, so it no longer has to wait for the service to come back, and you can follow the progress and the outcome the whole way through.
"An update is available" and "pressing it actually updates" are now the same condition — in a few cases the console would offer an update that the updater then declined to perform, leaving the screen waiting. Both decisions now come from one set of rules.
Refreshing the page after an update no longer asks whether to resubmit the form.

Hub 1.0.12 — 2026-09-07

The Hub console's update screen now matches the host console — as above, pressing update shows SvrGuard's own "updating" screen rather than a server error page.
An installed update is now verified after the fact — previously only the service coming back was checked, and a service that starts is not proof that the new binary is the one running. The installed build is now checked against the one that was meant to be installed, and a mismatch is reported as a failure.

1.0.11 — 2026-09-06

Nothing in this release changes what the software does — it exists so that we could run the update process itself, end to end, on real machines and confirm the result. There is nothing for you to do: update the way you normally would, and the behaviour afterwards is identical to 1.0.10. It is written up here anyway because your console will offer you the update, and "a new version with nothing you can read about it" is not a state we want you to be in.

Hub 1.0.10 — 2026-09-06

Account mail now uses the language you chose in the console — the password-reset mail was written in the language of whichever browser asked for it, and since you are not signed in when you ask for a reset, the language you had chosen was never consulted: the same account, asked from browsers in two languages, received two different letters. It now follows the language the account chose; an account that never chose one still gets the language you are reading the site in.
Account mail no longer carries a machine identifier in its subject — password reset and address verification had a host label appended to the subject. That label exists to answer "which of your machines is this about", and an account letter is about none of them, so all it added was a string with no meaning. Attack notifications and monitoring alerts still name the host, which is where you need it.

1.0.10 — 2026-09-06

The cover shown while updating now actually finishes — the previous release split the outcome into three separate messages, but the credential the cover used to ask the host disappears when the service restarts, so what it reached was the sign-in page rather than an answer. The cover ran to the ten-minute ceiling exactly as it did before the fix. It now asks in a way that needs no sign-in, so the question still gets through after a restart and the three outcomes really appear. The upgrade from 1.0.9 itself still shows the old behaviour — that screen is drawn by the version you are upgrading away from; the difference shows from the next update after this one is installed.

Hub 1.0.9 — 2026-09-06

Renewal reminder mail no longer states an amount — the amount actually charged is the one on the receipt you get from Paddle; the mail itself only tells you which subscriptions are about to renew and how to turn one off before it does.
The update page now gives two separate dates — it used to say only that the management server names the version at check-in, which left both "when did this build get installed" and "when was a version last named" unanswerable. Those are different questions: "up to date since June" and "nobody has asked since June" looked the same on the page. Both dates are now shown, and if the build did not arrive by self-update the page says so rather than inventing a date.
Automatic updates no longer tell you to press a button that is not there — with automatic updates off, the page always said "someone has to press the button above", including on pages with no button at all (already on the offered version, or no version named yet). Each of those now describes its own situation.

2026-09-06 — Pricing change

Pro is now US$59 per host per year (previously US$30) — this applies to subscriptions bought from 2026-09-06 onwards. Subscriptions already bought are unaffected: the expiry date does not change and the service runs normally until then. Nothing that was free has changed — detection, blocking, unblocking and whitelisting after a false positive, and attack notifications still need no subscription.

1.0.9 — 2026-09-06

Updating now waits for the host to come back, and says how it went — pressing update covered the console and then simply stayed there; when the ten-minute ceiling expired all it said was "refresh and check the current version", which handed the question of whether it worked back to you. The cover now keeps asking whether the host is back (being unreachable while the service restarts is expected and is not treated as failure), and ends in one of three ways: update complete shows which version replaced which and offers to sign you in again; update did not take (the service returned but the version is unchanged) says exactly that; stopped waiting says we did not get an answer and asks you to check the current version. The three no longer share one sentence.
The threat address database row is no longer blank — that row has no button (the daily schedule checks and applies for you), so what it says is your only clue. "The source has a newer copy that has not been applied yet" and "the source cannot be reached at all" looked identical, and the second one means this host has stopped receiving the database. Each is now named: up to date / a newer version will be applied by the daily schedule / versions cannot be compared / update source unreachable.
The local database now has a ceiling — rule-hit records and IP profiles had no retention limit and grew without bound. Both are now kept for 90 days. Addresses currently being blocked are unaffected: the country, category and history shown on the block list stay in place.

1.0.8 — 2026-09-05

The daily database tidy-up is no longer skipped by restarts — SvrGuard clears access records past the retention you configured. That job ran 24 hours after the program started, so on a host that reboots, updates its package or restarts the service more often than once a day, it never ran at all — the database kept growing with nothing on screen to say so. One machine had accumulated 12 days of records against a 3-day setting, in a 235 MB file. The last run is now recorded, and a missed one is caught up at start-up.
Per-URL statistics nothing displayed are no longer collected — one row was kept for every URL requested each day, and kept for ever. Scanners try URLs that do not exist, so that table grew with the attacks rather than with the site: 229,000 rows on one machine. None of it appeared on any page. It is no longer written, and existing rows are removed during the upgrade. Detection, blocking and the traffic charts are unaffected.
The database write-ahead log is reclaimed regularly — SQLite's write-ahead file had no moment at which it was folded back, so on a busy host it only grew. The daily tidy-up now checkpoints and truncates it.

1.0.7 — 2026-09-05

Synology package updates now show that an update is running — on a Synology NAS, the “updating” cover flashed once and vanished, leaving a page that still showed the old version, as if nothing had happened. The update itself always succeeded; the screen simply did not say so. It now behaves like the other platforms: the console is covered and the current stage shown while the update runs, clearing itself when it finishes.

1.0.6 — 2026-09-05

Blocks from a threat address database update now take effect immediately — after applying a new threat address database, the console reported how many addresses had been blocked, but those addresses only reached the firewall at the next sync. In between, the database said they were blocked while the firewall did not. The firewall is now synced as soon as the update is applied.
“Sign in again” on the signed-out page no longer leads to an error page — after signing out of the console, that link produced a plain-text error. The page now offers only the two routes that actually work: back to where you were, or on to the Hub console.

1.0.5 — 2026-09-05

The “rule pack” is now the “threat rule database” — one thing that used to go by three different names across the console, this site and notification emails. Nothing about the feature changed, only the name. Together with the threat address database renamed in the previous version, the two now say what each of them does: one judges behaviour, the other records addresses.
You can no longer click something else mid-update — once an update starts, the console (including the side menu) is covered, leaving only the current stage and progress, and it clears itself when the update finishes. Previously the page stayed clickable, and navigating away and back left no way to tell whether it had finished.
Shared threat intelligence only offers an update button when there is something new — matching the other three rows. Previously the button was always available, and pressing it usually just confirmed again that nothing had changed.
Account emails now follow your interface language — verification, password reset, expiry and renewal reminders, 11 messages in all, used to be sent in Chinese regardless. They now use the language you picked in the console.
Two display faults fixed — on the English interface, three status lines on the system update page came out in Chinese; and the rule update notification email printed the version as a garbled string (for example v%!d(string=1.0.2)). Both affected the display only — updating itself was always working.

1.0.4 — 2026-09-04

The “malicious IP database” is now the “threat address database” — the wording is consistent across the console, this site and notification emails. Nothing about the feature changed, only the name: it blocks more than bare IP addresses, and the new name matches what it actually does.
The system update page now shows “last updated” — the rule pack, the threat address database, shared threat intelligence and the program itself each show when they were last fetched or applied. Previously you could see the version but not whether it arrived today or stalled two weeks ago.
One manual upgrade is required — the rule pack and threat address database now carry the same three-part version numbers as the program. An older agent cannot read the new format, and it reports nothing: it simply stops updating, quietly. Get the installer from the download page and upgrade each host by hand once; unattended updating resumes afterwards. Attack detection and automatic blocking keep running throughout — only rule pack and threat address updates pause.
The site now has a contact address — every page footer carries it.

1.0.3 — 2026-09-04

Unattended updating works again on Synology — from 1.0.0 onward, a NAS treated every new version as “cannot compare” and refused to install it, which on screen looked like a deliberate safety check. This version fixes it. Affected NAS units need this version installed by hand once: the older versions carry the fault themselves, so they cannot update past it. Get the package from the download page and install it through Package Center; unattended updating resumes afterwards.

1.0.2 — 2026-09-04

The “Update program” button works on Synology packages — on a NAS it reported “update started” and then did nothing, with no way to tell from the screen. It now uses the proper Synology package install. Unattended updating was never affected; only pressing the button by hand was.
No more stale update warnings — the “unattended updating is not running” banner at the top of the console could stay up after the problem it named was gone. Restarting the service now clears it.

1.0.1 — 2026-09-04

Fixes on the bind-a-host page — added the link through to the approval page and a “Subscription expires” column; the transfer option no longer appears when there is no other host to hand the subscription to.
The version is on screen — the console sidebar and the version command both show the version and build number, so it can be quoted when reporting a problem.
This page is new — release notes start with this version.

1.0.0 — 2026-09-04

The first stable release.

New version numbers — Versions are now three numbers such as 1.0.0, replacing the earlier build-date identifiers. The agent, the Hub and the admin side are released separately, each with its own version.
Threat address database update fixed — Fixed a fault that stopped the threat address database from updating. You can see its state on the System Update page of the console.
Hosts on older builds need one manual upgrade — If a host still reports an old identifier (for example 6376.0.20260903), automatic updates will not cross this change — and will not install the wrong thing either. Fetch the package again from the download page and install it once. Automatic updates resume from then on.