A single critical advisory against a mixed fleet is not a patch task. It is a sequencing problem, and the sequencing has to be defensible to people who will ask why their site went first or last.

The advisory in one paragraph

JSA112186 covers multiple issues in Junos OS on SRX Series. One of them, CVE-2026-33792, is CWE-121, a stack-based buffer overflow in the srxpfe forwarding process. A crafted packet on a configured GRE tunnel reaches it without credentials and yields code execution as root or denial of service. CVSS 3.1 is 9.8, CVSS 4.0 is 9.3, and no workaround is published.

Why "highest score first" is not a sequence

Severity describes the flaw. It says nothing about whether a given device presents the precondition. In a mixed estate there will be SRX platforms without GRE, SRX platforms with GRE, and devices that match the fingerprint but are not SRX at all.
A sequence built on score alone patches devices that could not be reached by the described path while leaving a reachable gateway waiting for a later window.

The two facts that order a fleet

The first is whether GRE is configured and reachable. This is a configuration query and it is binary.
The second is whether the installed build predates the fix for that train. This requires reading the exact build identifier, because the fixed list includes respins for 23.2, 23.4 and 24.2.
A device that answers yes to both is the priority. A device that answers no to the first can reasonably move to a later window without argument.

Where the trains matter

The fixed releases span 23.2R2-S7.7, 23.4R2-S8.13, 24.2R2-S5.5, 24.4R2-S5, 25.2R2-S2, 25.4R1-S3, 25.4R2, 26.2R1-S2, 26.2R2 and 26.4R1, with later releases holding the fix.
A fleet distributed across older trains needs more windows, not fewer, and the respin note adds a verification step to each. Sorting by train lets the change calendar absorb the load instead of discovering it mid-window.

Interim control while the sequence runs

Because no workaround exists, the interval is governed by reachability. For each not-yet-patched GRE-terminating device, restrict the peers that can send inner traffic to those the use case requires.
This is worth doing first for devices that sit late in the sequence, since they carry the exposure longest.

Verification that survives an audit

Record the exact build identifier, the tunnel peer list, and the date of both readings. Tie ticket closure to the build string.
Asset databases that store the version from the last audit will report a fixed fleet that is not fixed, and that failure is silent until the next advisory.

External context, used honestly

A ZoomEye query on the Junos fingerprint returned 1497 matching assets at the time of this analysis, and a broader Juniper query returned 343570. Those numbers describe internet-facing fingerprints. They do not identify SRX platforms, tunnel configuration, or build state, and they should not appear in a ticket as evidence of exposure.
They are useful for one thing: explaining to a change board why the perimeter devices in the sequence are not interchangeable.

The end state

When the sequence finishes, the estate should be able to answer three questions without investigation: which devices terminate GRE, which build each one runs, and when each reading was taken. Those three answers are the difference between closing an advisory and closing a class of them.

References

  • Juniper Networks security bulletin JSA112186: https://supportportal.juniper.net/JSA112186

  • CVE.org record for CVE-2026-33792: https://www.cve.org/CVERecord?id=CVE-2026-33792

  • CERT-BUND advisory WID-SEC-2026-3976: https://wid.cert-bund.de/content/public/content/b6a2aff7-6ffb-4195-8879-c9537ac004dd