OPNsense released 26.7.5, a point release with security on the label: the announcement says it “fixes a few security related things” and pairs the fixes with OpenSSL 3.5.9, a package manager sync to 2.8.4 to match FreeBSD’s, and a Phalcon bump.
The advisory that got a number
The patch notes name one fix with an advisory behind it: a password-policy lock could be cleared without actually changing the password. When a local user’s password violates the configured policy, the GUI confines that session to the password portal until a successful change. An empty-password Save, of the kind used for language-only edits, cleared the “should change password” flag before the write path ran, so the weak credential stayed valid while the account regained normal privileges. The fix clears the flag only after a successful password change. It is rated low (CVSS 4.3) and is not a privilege escalation; the operator needs to already hold the password. Reported by Wenhao Wu. A second hardening line sits nearby in the notes: packet-capture downloads in the backend now go through a stricter archive command.
bcrypt to argon2id
The more visible change for anyone logging in day to day: the default password hash moves from bcrypt to argon2id, the memory-hard function that keeps showing up in current hardening guidance. This one is optional by design. Existing bcrypt hashes keep working as they are; to benefit from the change, a hashed password needs to be changed, which happens naturally whenever someone updates theirs. No forced resets, no lockouts, just a better default for the hashes written from here on.
The NAT page moves house
The firewall’s outbound NAT page moves to the os-firewall-legacy plugin. For anyone half-way through the Source NAT migration that started in 26.7, the important part is what does not change: outbound rules keep working even when that plugin is not installed, and the migration assistant still runs. The legacy plugin carries the old page, not a dependency for your running rules. The release also continues the interface-settings work with a way to debug the interface ordering sequence at boot, which the announcement says will feed more optimizations later.
My read
Nothing here forces a decision. The hashing change happens on its own schedule, the NAT move is a relocation, and the advisory needs a constrained instance to matter at all. Take the update when the console offers it, skim the two notes, and decide whether you care when your hash function modernizes. This is the kind of release a firewall project ships when the right defaults changed and nobody needed to be told loudly.
Source: the 26.7.5 announcement and the advisory.

