Octopus Deploy’s advisory says the 2026.3 line is fixed in build 15816; the CVE record it published the next day says the affected range stops at build 11816, a number that clears every 2026.3 release shipped this month.
What happened
Octopus Deploy published Security Advisory 2026-08 on September 14, 2026, covering CVE-2026-91778, an incorrect-authorization flaw in Octopus Server. The CVE record followed on September 15, 2026 at 7:05 a.m. UTC and was updated the same day at 2:40 p.m. UTC. Octopus Deploy is the CNA for its own products, so both documents come from the same organization.
The flaw itself is straightforward. In the advisory’s words, “users with certain scoped permission sets could execute arbitrary scripts on a worker (including the Octopus Server built-in worker),” because “incorrect permission validation during script execution would allow the script to execute without the user possessing the required authorisation.” The CVSS v4.0 base score is 7.2 High, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N — network-reachable, low attack complexity, low privileges required, with high integrity and availability impact and no confidentiality impact. The weakness class is CWE-863. Octopus credits Nathan Willoughby at Octopus Deploy, who found it during internal testing, and states there is no known mitigation: “There is no known mitigation for CVE-2026-91778, it is important to upgrade to a fixed version as soon possible.” Octopus Cloud customers were patched automatically.
The advisory lists the affected versions as all 2019.x through 2025.x releases, all 2026.1.x before 2026.1.11725, all 2026.2.x before 2026.2.13344, and all 2026.3.x before 2026.3.15816. The fixed builds are 2026.1.11725, 2026.2.13344, and 2026.3.15816.
The CVE record does not say that. Its CNA-supplied affected array, read from the CVE Program’s own API, carries three ranges:
{"version":"2019.0.0", "lessThan":"2026.1.11725", "status":"affected"}
{"version":"2026.2.0", "lessThan":"2026.2.13344", "status":"affected"}
{"version":"2026.3.0", "lessThan":"2026.3.11816", "status":"affected"}The first two match the advisory exactly. The third does not. The advisory’s cutoff for the 2026.3 line is build 15816; the CVE record’s is build 11816. Everything else about the entry is correct — the vendor, the product, both platforms, and a defaultStatus of unaffected, which is the right way to write it.
Why the digit matters
Octopus build numbers are sequential within a feature line, and the 2026.3 line is nowhere near 11816. Octopus’s own downloads page lists 2026.3 build 15816 as the current Recommended release, dated Monday, September 14, 2026, with build 15505 before it on September 2 and build 15041 on August 31. The 2026.3 line has been in the 15,000s for at least two weeks.
Build 11816 is not a 2026.3 build at all. It is a number from the 2026.1 line’s range — that line’s fixed build is 11725 and its current release is 11781. The 2026.3 entry appears to have inherited a build number from the wrong feature line, or to have had its leading digit transposed from 15816. We are describing the shape of the error, not asserting how it was made.
The effect is not cosmetic. A range of 2026.3.0 up to but excluding 2026.3.11816 declares every 2026.3 build from 11816 upward to be unaffected. That includes build 15041, shipped on August 31, and build 15505, shipped on September 2 — two releases the vendor’s own advisory places inside the affected range. Anything consuming the CVE record rather than the advisory will report a server running either of those builds as patched.
That is the population most likely to be wrong here, and it is not a small one. Vulnerability scanners, SBOM tooling, software composition analysis, and internal dashboards ingest the structured affected array because it is the machine-readable field; the advisory is prose on a vendor’s website. A shop that was current on 2026.3 two weeks ago, running build 15505, is exactly the shop that a version check will wave through — and it is running a build the vendor says is vulnerable.
Note the direction of the error, because it is the bad one. An affected range that is too wide produces false positives: somebody patches a server that did not need it, grumbles, and moves on. An affected range that is too narrow produces silence. There is no ticket, no dashboard row, no alert. The only way to find out is to read the advisory prose, which is the step automated version checking exists to avoid.
There is a second pattern worth naming. The two ranges that are correct are the ones with the smaller build numbers, and the one that is wrong is the newest line. A CNA transcribing three fixed builds into a record by hand gets two right and one wrong, and the one it gets wrong is the one nobody can sanity-check by eye, because a reader has no reason to know that 2026.3 builds live in the 15,000s while 2026.1 builds live in the 11,000s. Version schemes that encode a build counter per feature line are readable by machines and opaque to reviewers. The advisory and the record disagreed for more than a day, through at least one record update, and the disagreement is invisible unless you hold both documents open at once.
NVD, for its part, had not analyzed the record at the time of writing — its vulnStatus is Received, and there is no configurations block yet. That means NVD has not produced its own CPE ranges and is serving the CNA’s data through. When NVD does enrich the record, it will build its CPE match rules from what the CNA supplied unless someone catches the mismatch first. The error propagates rather than getting corrected in transit.
What to do
Go by the advisory, not by the CVE record. For Octopus Server, the fixed builds are 2026.1.11725, 2026.2.13344, and 2026.3.15816. On the 2026.3 line specifically, any build below 15816 is vulnerable regardless of what a scanner says, and that includes the builds most 2026.3 installations were running as of last week.
Check the running build directly rather than trusting an inventory record. If your scanner reports a 2026.3 Octopus Server as clean, confirm the build number by hand before you close the finding — the number to compare against is 15816, and anything from 11816 to 15815 is the window the CVE record gets wrong.
There is no mitigation. Octopus says so plainly, and an authorization defect in script execution is not something an access-control change at the perimeter addresses, because the users who can reach it are already authenticated. The exposure is worth taking seriously on its own terms: the built-in worker runs on the Octopus Server host, and a deployment server that executes arbitrary scripts for under-privileged users is a pivot into everything it deploys to. The VI:H/VA:H in the vector is the right reading — this is an integrity and availability problem across the deployment estate, not a data-disclosure one.
If you run Octopus Cloud, the advisory says you were patched automatically and no action is required. Self-hosted installations are the ones that need attention.
Sourcing note
Checked: Security Advisory 2026-08 on advisories.octopus.com, read twice to confirm the version numbers; the CVE Program record for CVE-2026-91778 read from the CVE Services API, which returns the CNA container verbatim including the affected array quoted above; NVD’s record for the same CVE read from the NVD REST API, which shows vulnStatus of Received and no configurations block; and Octopus’s public downloads page for the 2026.1, 2026.2 and 2026.3 build history, which is what establishes that the 2026.3 line is in the 15,000s.
Unresolved: we have not contacted Octopus Deploy, and we do not know whether the discrepancy is a transcription error or an intentional distinction we are misreading — though we can find no reading under which a 2026.3 build numbered 11816 exists. The record was updated on September 15, 2026 at 2:40 p.m. UTC, after publication, and the 2026.3 range was still 11816 after that update; we do not know what the update changed. There is no reported exploitation of CVE-2026-91778 from the vendor or any other source we checked, and the advisory describes the finding as internal. We have not verified the exact scoped permission sets that reach the flaw, because the advisory does not name them.