A staged rollout rests on one assumption: a release name says what you get. Approve 26.1.11 in the fast track, watch it for a few days, and the same 26.1.11 reaches regular and stable. In October 2026, OPNsense broke that assumption for a good reason.
On 2026-10-21, OPNsense published a fix for PHP2Shell (CVE-2026-109618 and CVE-2026-109619), a PHP flaw with unauthenticated remote code execution. It shipped no new version for either supported series. It rebuilt the packages and rewrote the existing 26.1.11 and 26.7.7 releases on its mirror. Devices already on 26.7.7 started showing pending package updates with no change in version. Same name, different content.
Firmware tracks now handle this. NetDefense records each in-place rewrite as a new revision of the release, shown as 26.1.11 rev 2, and rolls it out through your tracks like a release.
TL;DR
- OPNsense sometimes fixes a release in place, without a new version number. The PHP fix reached 26.1.11 and 26.7.7 that way.
- NetDefense records each rewrite as a revision of the release. A revision soaks through fast, regular and stable under the same rules as a release.
- You can promote, halt and clear failures for one revision, so an urgent hotfix can go to every track at once.
- With NDAgent 1.28.0 or later, a device checks right before installing that the release still matches the approved revision. If OPNsense rewrote it again, the device holds.
- Nothing is rolled back, and devices pinned to an older release don’t receive a hotfix made for a newer one.
Why an in-place fix is a problem for staging
A firmware track holds each device at an exact release through OPNsense’s own firmware setting, and a window moves it to the release the track has approved. That works because the release is a fixed thing: the folder on OPNsense’s mirror that the pin names.
An in-place fix breaks that in two ways.
- The version doesn’t change. After the rebuild, a device on 26.1.11 still reports 26.1.11. The firmware check lists package updates, among them PHP, but the OPNsense version is the same. Any tool that looks for a new version sees nothing new, and any tool that treats “updates pending” as drift gets it wrong in the other direction.
- The approval no longer says what it approved. A release can soak in fast for three days, and be rewritten while it sits there. What stable installs a week later is not what fast ran. Evidence from devices on the old content says little about the new one.
The second one is the real risk. A staged rollout exists so that the content that reaches the last devices has already been tested on the first ones. A silent rewrite removes that guarantee without any sign.
Revisions
NetDefense now watches the content of each release folder, not only its name. When OPNsense rewrites one, it is recorded as the next revision of that release.
- Revisions use your tracks. A revision goes from fast to regular to stable under the same soak and evidence rules as a release, and a device installs it at its track’s next window.
- Newer replaces older. If a revision is rewritten again before fast has approved the first one, the newer revision replaces it.
- You can steer one revision. Promote now, halt and clear failures can name a revision. For an urgent security hotfix like this one, promote it to all three tracks and skip the soak.
- The first revision is the baseline. The content a release had when this went live is its revision 1. Only later rewrites roll out as new revisions.
$ ndcli firmware version halt 26.1.11 --revision 2 --reason "regression in the rebuilt packages"
Without --revision, promote approves the newest revision, and halt covers every revision of the release.
The check on the device
Recording revisions fixes the approval, but there is a gap left: the time between approving a revision and installing it. OPNsense can rewrite the folder again in that time.
So the device checks. With NDAgent 1.28.0 or later, a firmware step compares the release folder with the revision the track approved, right before it installs anything. If they differ, the device changes nothing and holds, with the reason held_revision_mismatch. It stays held until the new revision is approved, and then the next window installs it.
Nothing unapproved gets installed
A device that finds the folder changed installs nothing and leaves itself as it was. Once the new revision is approved, the next window installs it.
Devices on an older agent can’t make that check. While a newer revision waits for approval, they show Agent upgrade required and get no firmware step. Otherwise they update as before.
What you see
- Pending package updates. Each device shows what its last check found. When installing them wouldn’t change the OPNsense version, the label reads
Hotfix: 17 package updates pending. - Pinned below a hotfix. A device pinned to an older release shows a warning such as
26.1.11 has a hotfix your pinned release doesn't get. This one is easy to miss: OPNsense didn’t patch the older releases, so a device held on 26.1.10 doesn’t get the PHP fix from its own pin. Promoting 26.1.11 moves it up. - Revisions on the Rollout card and in NDCLI. Targets, halts and failures show
rev 2, and every NDCLI output format and the MCP tools carry the new fields.
What it does not do
- It doesn’t roll anything back. A halt stops a revision from spreading. Devices already on it stay on it.
- The pin is a guardrail, not a lock. It holds back OPNsense’s own repositories only. The NetDefense repository, plugin repositories and any other repository you enabled aren’t pinned, and still update.
- It doesn’t judge the fix. NetDefense can tell that a release changed, not whether the change is good. That is still the job of the soak, the evidence and you.
Getting it
NDAgent 1.28.0 arrives with the next OPNsense update, under System > Firmware > Updates. To upgrade a device sooner, use Install plugin on the Run page of the web app, or ndcli run plugin-install --device <name>. The --revision flag needs NDCLI 1.43.0 or later. The web app already shows revision badges on the Rollout card, the Hotfix: N package updates pending count on each device, and the pinned-below-a-hotfix warning.
Read the details in Hotfix revisions, on the Firmware page and in the ndcli firmware reference.
