Releasing more often doesn't mean more secure
-
I often see people treat "ships updates constantly" as basically the same thing as "actively maintained, so it's secure." Let's talk about this.
OPNsense and their fans lean into that messaging, two major releases a year and minor point releases roughly every two weeks according to their own docs (https://docs.opnsense.org/manual/updates.html).
But patch speed and how often critical bugs show up in the first place are two different things, and OPNsense's history is a pretty good example of why the first does not imply the second.
A quick rundown of what happened between April and May 2026:
April 9: an information disclosure bug (WID-SEC-2026-1044, CVSS 8.2) affecting anything before 26.1.6.
May 6: CVE-2026-44193, a 9.1 critical, authenticated command injection through XMLRPC's restore_config_section that gets you root RCE. Same day, CVE-2026-44195, a login lockout bypass caused by a regex ordering mistake, which basically lets someone brute force credentials without getting locked out.
May 12: two more. CVE-2026-44194, another 9.1 critical, command injection through sync_user.php because shell metacharacters in the email field weren't being sanitized. And CVE-2026-45158, an argument injection bug through DHCP hostname handling, also rated critical.
That's five disclosed issues in about five weeks, including two critical root RCEs six days apart, both of which had public proof of concept code floating around not long after disclosure. It took three point releases back to back (26.1.6 on April 9, then 26.1.7 on April 30, then 26.1.8 on May 12) to actually get it all patched. Nor are their release notes (already linked) clear about what happened.
This is not a one off. Go back a year and CVE-2025-50989 (CVSS 8.8) was basically the same category of bug, authenticated command injection from unsanitized input, just in the bridge interface editor that time instead of user management.
OK, how does this stack up against pfSense's own track record?
Everything here is pulled from public official sources you can check yourself: Netgate's own advisory index at docs.netgate.com/ advisories, and NVD for the CVSS scores, not somebody's blog summary of it.
Netgate has published 49 pfSense advisories total since 2023, which is actually more total disclosures than OPNsense's own GitHub advisory count. But only 12 of those 49 ever got a formal CVE assigned, and only 8 of those 12 have an actual scored CVSS on NVD right now, the other 4 are still sitting as RESERVED.
Averaging those eight, pfSense's mean CVSS comes out to 6.34, median 5.4. The worst pfSense has hit across that whole three-plus year stretch is 8.8, and only two advisories ever got there. OPNsense's 33 CVE'd vulnerabilities over the same period average 7.28 with a median of 7.2.
The high end is where it really shows: CVE-2026-57155 against OPNsense hit a 9.9 in June, root RCE from an arbitrary file write in the GeoIP alias importer, about as close to the maximum (10.0) score as CVSS goes. A true "drop everything, patch NOW" moment.
Back in August 2023 there was a batch of three separate 9.8s against OPNsense in the same disclosure, CVE-2023-39001 (command injection in diag_backup.php), CVE-2023-39004 (insecure permissions on /conf/), and CVE-2023-39008 (command injection through the cron API), plus CVE-2023-27152 at 9.8 for missing rate limiting on auth that let you brute force logins.
And that's before counting the three 9.1 criticals against OPNsense from the April and May 2026 cluster above.
Meanwhile: pfSense never once cracks 9.0 anywhere in its own advisory history. So it's not just that OPNsense had a rough five weeks in April and May, the severity ceiling on what actually gets found tends to run meaningfully higher on OPNsense than anything that's shown up in pfSense in the same window.
A couple caveats so nobody has to point them out for me in the comments. This is comparing CVE-scored vulnerabilities specifically,and pfSense discloses a lot more total advisories than it gets formal CVEs for, so if you count raw advisory volume instead of scored CVEs the picture looks different.
But back to the subject at hand: What this actually shows is that release cadence measures time to patch, not defect rate, and those aren't the same thing even though it's easy to give a project credit for both just because the version number keeps climbing. The bug class that keeps showing up here (unsanitized input reaching a shell call, in different parts of the codebase, a year apart) is exactly what a slower and more paranoid review process is supposed to catch before release, not after.
It's also part of why pfSense's UI is getting rewritten in Go. A good chunk of the bug class we're talking about here, on both platforms honestly, comes down to PHP config forms passing user input into a shell call and relying on someone remembering to sanitize every single path by hand. Go's standard exec.Command doesn't shell out the way PHP's exec/shell_exec/backticks do, so a lot of this category stops being a "did the developer catch it?" problem and becomes something the language itself makes harder to get wrong. This is not a silver bullet by itself, but it's one of the concrete things driving the rewrite.
Also relevant since 2.9.0 just shipped: the System Patches package is now installed by default (redmine #16695). The package itself isn't new, it's been around for years and Netgate has a solid track record of using it to ship fixes between releases. Back in May 2025 Netgate patched seven separate issues (an OpenVPN command injection, several stored XSS bugs in Firewall Schedules, IPsec tunnels and Wake on LAN, plus an AutoConfigBackup key disclosure) through it, weeks ahead of the 25.03/2.8.0 point release those fixes eventually landed in. What changed in 26.03 and 2.9.0 is that the package ships pre-installed instead of requiring people to go find and install it themselves first. This matters because a security mechanism only helps the people who actually have it. There's an auto-apply option for the recommended patches too, but that part is opt-in, you have to turn it on yourself under System > Patches.
Practical takeaways: Don't expose your firewall's management interface to the WAN, and "the vendor patches fast" is a mitigation, after-the-fact response.
Curious what other people here think. Does a fast release cycle change how you judge a product's security track record, or do you weigh total severity and how often the same bug class recurs more heavily regardless of patch speed?
Sources: OPNsense update docs (https://docs.opnsense.org/manual/updates.html), SentinelOne write ups on CVE-2026-44193, CVE-2026-44194, and CVE-2026-44195, TheHackerWire on CVE-2026-45158, the wz-it.com timeline breakdown, the GitHub advisory for CVE-2025-50989 (GHSA-qf7f-cgq3-xfvh), OPNsense's own published security advisories (github.com/opnsense/core/security/advisories), Netgate's official pfSense advisory index (docs.netgate.com/advisories), and NVD for CVSS scores for both.
-
Curious what other people here think. Does a fast release cycle change how you judge a product's security track record, or do you weigh total severity and how often the same bug class recurs more heavily regardless of patch speed?
Objection! Compound and leading!
-
@jwt This is perimeter security, not a general purpose OS trying to keep up with changing HW. Others may disagree, but 1 or 2 releases a year for features is great. This gives plenty of time to test the new features before putting them in the wild.
Judgement comes with how often defects need to be fixed. I really do not like restarting my firewall, it is a pain. Fewer defects equals fewer restarts which also indicates a better product.
-
Lawyers cannot ask leading questions when questioning their own witness. But leading is permitted if the witness is uncooperative, adverse, or tied to the opposing party. And I’m not a lawyer.
-
@jwt said in Releasing more often doesn't mean more secure:
And I’m not a lawyer.
That means we can still like you.
-
@jwt said in Releasing more often doesn't mean more secure:
System Patches package is now installed by default
It is, but it still needs updating. I've already seen questions about "how do I know when that package is updated?" Perhaps a dashboard widget to show if an update for that one is available, like the existing update check...? Or somehow, only if it adds security patches...
-
Everything here is perfectly wonderful and true. I just wish we weren't needlessly fanning the flames of silliness against a single competing vendor.
The last several years pfsense and netgate have been significantly more respectable than any other boundary product. The number of vendors that had a perfectly respectable product back in 2010 and then simply allowed decay to creep in is astounding. Many reached a 'mature' product and then stopped technical work and simply sold license and hardware off their prior good reputation.
Almost nobody has a good reputation anymore. It has actually become a joke at work about a few vendors that seem to be in the news in a bad way every few weeks. We never joke about pfsense.
Privacy Policy · Cookie Policy