Last updated: 29 October 2026. WatchGuard published its advisory on 27 October.
WatchGuard SIP proxy RCE needs a configuration check before a patch ticket can be scoped. CVE-2026-93857 lets an unauthenticated remote attacker run code through a policy that uses the Fireware SIP proxy. WatchGuard disclosed it on October 27, 2026, and rates it Critical at 9.2 under CVSS 4.0.
The exposure condition is specific: a SIP proxy must be configured on the Firebox. Start with the policy and the running build, then select the fixed release for that device. Our CVE-2026-93857 vulnerability profile keeps the affected ranges and advisory timeline together.
Start With the SIP Policy, Not the Asset Count
A list of WatchGuard appliances is a starting point, not an exposure finding. The advisory describes a crafted request passing through a policy that uses the SIP proxy. It does not say that every Firebox, every policy, or every Fireware feature has this attack path.
Review each device’s active policy configuration. Record whether a SIP proxy is configured, which policy uses it, and which traffic that policy permits. Keep an unclear configuration in the review queue until the firewall owner can check it. Do not turn a missing inventory field into a finding that the device is safe.
The consequence is remote code execution, rather than a login bypass alone. For patch priority, pair that potential impact with the policy’s actual reach. A device with the required SIP configuration deserves a clear owner and a prompt change plan, even without a confirmed attack report.
Match the Device to Its Own Fixed Release
WatchGuard lists three fixed releases, but they are not interchangeable targets. Its default product row separates the modern and 12.x trains. The T15 and T35 have a separate row. Use the model and current release together when reading this table.
The lower bounds are inclusive and the fixed versions are excluded from the affected ranges. These rows still require the SIP proxy configuration described above. A T15 or T35 should be checked against its own row, rather than the default 12.x threshold.
In WatchGuard’s upgrade guide, select the Firebox model in Software Downloads and open the release notes for the chosen build. Those notes carry release-specific upgrade steps. Do not select firmware solely because its version number looks higher than the number in another row.
Carry the Policy Evidence Through the Change
The order below is a proposed admin workflow, not a test performed on a Firebox. It joins the exposure check to the change record, so another operator can see why that device was patched. The result should be evidence of the running fix, not only evidence that an image was downloaded.
- 1Firewall Owner FireboxReview the active SIP proxy policy and running build.
- 2Firebox Firewall OwnerRecord the model, build and relevant policy.
- 3Firewall Owner Change RecordSelect the matching fixed track and change window.
- 4Firewall Owner FireboxApply the approved vendor upgrade procedure.
- 5Firebox Firewall OwnerCheck the running build and legitimate SIP service.
- 6Firewall Owner Change RecordAttach the post-change evidence and close the task.
Use these checks alongside the normal patch management process. They are a handover checklist; the device’s management method and vendor release notes determine the actual upgrade procedure.
- Save the baseline. Record the device model, running Fireware release, SIP policy and service owner. Confirm that a usable backup exists before the change.
- Prepare the correct route. Follow the release notes for that model and management method. If WatchGuard System Manager manages the device, check its version against the target Fireware release.
- Apply the update. Use the approved change window and WatchGuard’s documented upgrade method. Leave power on and let the process complete.
- Check the result. Read the running release again after the upgrade. Confirm the expected SIP service still works, and attach both checks to the ticket.
WatchGuard’s backup and restore documentation explains what a backup image contains. Check the backup procedure for the installed release instead of assuming that every model and version saves the same image. Keep the pre-change evidence with the record.
If a patch must wait, have the firewall owner review whether the SIP proxy policy is required and who must reach it. Changes to voice traffic need service-owner review. This is an exposure-reduction decision, not a vendor-certified workaround or a substitute for the fixed release.
Keep Technical Severity Separate From Attack Reports
WatchGuard says it is not aware of exploitation in the wild. That is the vendor’s assessment in the October 27 advisory, not a guarantee that attacks cannot happen. The CVSS score describes the potential impact under the stated conditions; it does not prove that a device has been attacked.
- Vendor assessmentUnknownWatchGuard says it is not aware of exploitation in the wild.2026-10-27
- CISA KEV listingNot seenAbsent from catalog version 2026.10.28, fetched October 29.2026-10-29
Keep that distinction in the vulnerability management record. For this advisory, closure means a matching fixed running build and a checked policy, not a low alert count. Assign the unresolved SIP-configured devices first, then record the installed result and the next review owner.