Key takeaways
- Fox handles two specific jobs inside the Niagara Framework: a Workbench engineering client talking to a Station, and one Station talking to another.
- The clearest public demonstration of what that gap allows came from independent researchers Billy Rios and Terry McCorkle, whose findings CISA published as ICSA-12-228-01A on 15 August 2012 (last revised 6 March 2014).
- The exposure has not meaningfully declined in the decade since.
- For the connections configured to use it, yes, and Tridium's own guidance is explicit about making that the default.
Fox is Tridium's proprietary protocol for communication between Niagara Framework stations and engineering Workbench software — the platform behind a large share of the world's commercial building-automation systems, and a growing share of transportation and data-center OT as well — and its plaintext default has been the subject of a documented vulnerability disclosure, an FBI warning, and growing internet-exposure data spanning more than a decade. Tridium's own Niagara 4 adds an encrypted alternative, but neither the scale of exposure nor the pace of new findings has slowed down.
This guide draws on CISA's published ICS advisories, Tridium's own Niagara Forum and Hardening Guide PDFs, Honeywell's security bulletin, and independently reported exposure research from CyberScoop, Censys and Nozomi Networks Labs, cross-checked against each other. Confirm exact product-version and configuration details against Tridium's own current documentation before relying on this guide for a specific deployment.
What is the Fox protocol, and why does it matter for building security?
Fox handles two specific jobs inside the Niagara Framework: a Workbench engineering client talking to a Station, and one Station talking to another. By default, that traffic runs as plain, unencrypted "fox" on TCP port 1911 — a scheme Tridium's own current Niagara Station Security Guide now describes as "no longer recommended." An encrypted alternative, "foxs," wraps the same traffic in TLS on port 4911, and Niagara 4.15 added a third option, Fox-over-WebSocket ("foxwss"), running over standard HTTPS port 443. None of this is new infrastructure bolted onto an unrelated protocol — it is Tridium acknowledging, in its own current documentation, that the original plaintext scheme has no authentication or encryption of its own and needs a TLS-based replacement wherever it is genuinely exposed to risk.
What did the 2012 Niagara AX research actually find?
The clearest public demonstration of what that gap allows came from independent researchers Billy Rios and Terry McCorkle, whose findings CISA published as ICSA-12-228-01A on 15 August 2012 (last revised 6 March 2014).
| CVE | CVSS v2 | Weakness |
|---|---|---|
| CVE-2012-3024 | 7.1 | Predictable session identifiers |
| CVE-2012-3025 | 7.1 | Session cookies stored in plaintext/Base64 |
| CVE-2012-4027 | 5.0 | Unauthenticated directory traversal |
| CVE-2012-4028 | 6.5 | Weak credential storage in the station's config.bog file |
| CVE-2012-4701 (ICSA-13-045-01) | 8.5 | A further, separately disclosed directory-traversal flaw |
Rios went on to show what this meant at scale at Black Hat Asia 2014 ("Owning a Building"), using Shodan and cloud-based scanning to identify more than 50,000 internet-connected buildings running Niagara-managed systems worldwide — stadiums, hospitals, prisons and military facilities among them — and demonstrating live, unauthenticated access to building controls at a venue during the Sochi Winter Olympics. None of these findings required breaking a cryptographic scheme; they exploited the absence of one.
Is Niagara Fox still exposed on the internet today?
The exposure has not meaningfully declined in the decade since. CyberScoop reported in December 2018 that the FBI had identified roughly 700 US industrial control systems accepting unauthenticated connections on Fox's port 1911, with Shodan separately indexing about 20,000 exposed Fox endpoints across the US. Censys's own research found Tridium Niagara internet exposure growing from 39,371 to 43,167 instances — up 9.2% — between January and June 2025, concentrated in the US with more than 3,000 instances running on AWS. In July 2025, Nozomi Networks Labs disclosed 13 new vulnerabilities (10 of them assigned CVEs, CVE-2025-3936 through CVE-2025-3945) affecting Niagara Framework and Niagara Enterprise Security up to versions 4.10u10 / 4.14u1, including a chained exploit path from admin-privilege escalation to TLS private-key extraction. CISA's subsequent advisory ICSA-25-219-02, covering Johnson Controls' FX Server, FX80 and FX90 — which bundle that same vulnerable Niagara codebase under a different product name — confirms the exposure extends well beyond anything labeled "Tridium."
Does Niagara 4's encrypted FoxS actually close the gap?
For the connections configured to use it, yes, and Tridium's own guidance is explicit about making that the default. The Niagara 4 Hardening Guide instructs administrators to set a station's FoxS Enabled and FoxS Only properties to true, and states plainly that plaintext fox "should not be allowed" unless specifically required for a legacy integration that can't yet support TLS. Niagara 4.15 extended the security model further with PKI/mutual-TLS client-certificate authentication included at no extra license cost, SAML 2.0 single sign-on, and TOTP-based two-factor authentication. That said, the encrypted path is not immune to its own bugs: CVE-2020-14483, a TLS connection-handling timeout vulnerability in Niagara 4.6 through 4.8 and Niagara Enterprise Security 2.4/4.8, wasn't fixed until Niagara 4.9. Enabling FoxS is a necessary step, not a one-time guarantee — the station still needs to stay on a current, patched release.
A workable starting point
Confirm no Niagara station is reachable from the internetThe FBI's and Censys's findings describe exposed stations as the dominant real-world failure mode — not a cryptographic break of Fox or FoxS. Check `FoxS Enabled` / `FoxS Only` on every station, and disable plaintext fox on port 1911 unless a specific legacy device genuinely still needs it. Patch to a current Niagara or Niagara Enterprise Security releasethat includes the fixes for the 2025 Nozomi-disclosed CVEs (4.14.2u2, 4.15u1, 4.10u.11) and the 2020 TLS timeout bug (4.9 or later). Treat rebranded Niagara the same as Tridium's ownJohnson Controls' FX Server, FX80 and FX90 bundle the same Niagara codebase and are covered by the same CISA advisory. Segment the building-automation network regardless of FoxS status, the same compensating-control model NIST SP 800-82's OT security guidance applies to every field protocol that was never designed to be internet-facing, Niagara Fox included.
SoftWSP's OT Snapshot passively analyzes captured OT and building-automation traffic using Zeek and CISA's own ICSNPP protocol analyzers; today that analyzer set decodes Modbus, BACnet, S7comm, EtherNet/IP and DNP3 traffic in depth, flagging risky behavior — cleartext protocol use, or write and program-download commands from devices that aren't engineering stations — with the AI-assisted report citing the specific traffic behind each finding. Fox has no dedicated ICSNPP analyzer yet, so a capture from a segment running it today surfaces connection-level facts instead of a full protocol decode — for example, whether plaintext fox traffic on TCP 1911 is reaching the segment from somewhere it shouldn't. See OT Snapshot for what a passive building-network capture actually returns.
This guide is not a substitute for Tridium's own current Niagara documentation, CISA's or Honeywell's published advisories, or an integrator's assessment of a specific station's configuration.
Sources
- CISA ICS Advisory ICSA-12-228-01A: Tridium Niagara Vulnerabilities (Update A; CVE-2012-3024, -3025, -4027, -4028)
- CISA ICS Advisory ICSA-13-045-01: Tridium NiagaraAX Directory Traversal Vulnerability (CVE-2012-4701)
- CISA ICS Advisory ICSA-25-219-02: Johnson Controls FX Server, FX80 and FX90 (Update A)
- Tridium: "Demystifying Fox Connections in Niagara" (Niagara Forum 2025 developer session, PDF)
- Tridium: Niagara 4 Hardening Guide (January 2025 edition, PDF)
- Honeywell/Tridium Security Bulletin SB 2020-Tridium-2: Niagara TLS Connection Timeout Vulnerability (CVE-2020-14483, PDF)
- Nozomi Networks Labs: "Critical Vulnerabilities Found in Tridium Niagara Framework" (23 July 2025)
- Censys: internet exposure of Tridium Niagara instances, Jan-Jun 2025
- CyberScoop: "FBI warns industry about Fox protocol exposure on port 1911" (21 December 2018)
- Billy Rios: "Owning a Building: Exploiting Access Control and Facility Management Systems," Black Hat Asia 2014 (PDF)
Frequently asked questions
What is the Fox protocol, and what does it carry?
Fox is Tridium's proprietary protocol for Workbench-to-Station and Station-to-Station communication inside the Niagara Framework — the software platform (Niagara AX, then Niagara 4) that underlies a large share of commercial building-automation systems, and that is also used in transportation, data-center and other OT deployments. Per Tridium's own 2025 Niagara Forum developer session "Demystifying Fox Connections in Niagara," plain, unencrypted Fox traffic runs by default on TCP port 1911, with an encrypted variant called FoxS running on TCP port 4911 and a newer Fox-over-WebSocket variant (FoxWSS, added in Niagara 4.15) on port 443. The plain "fox" scheme carries no authentication or encryption of its own — Tridium's own Niagara Station Security Guide now describes it as "no longer recommended" for exactly that reason.
What did the 2012 Niagara AX vulnerability research actually find?
Independent researchers Billy Rios and Terry McCorkle found that Niagara AX stored credentials weakly, used predictable session identifiers, stored session cookies in plaintext/Base64, and exposed an unauthenticated directory-traversal flaw. CISA's advisory ICSA-12-228-01A ("Tridium Niagara Vulnerabilities," originally published 15 August 2012, last revised 6 March 2014) assigned CVE-2012-3024 (predictable session IDs, CVSS v2 7.1), CVE-2012-3025 (plaintext/Base64 cookie storage, CVSS v2 7.1), CVE-2012-4027 (directory traversal, CVSS v2 5.0) and CVE-2012-4028 (weak credential storage in the station's config.bog file, CVSS v2 6.5). A related follow-on advisory, ICSA-13-045-01, assigned a further directory-traversal CVE (CVE-2012-4701, CVSS v2 8.5). Rios later demonstrated the real-world stakes at Black Hat Asia 2014 ("Owning a Building"), using Shodan and cloud scanning to find more than 50,000 internet-exposed Niagara-managed buildings worldwide, including stadiums, hospitals and prisons, and live-demonstrating unauthenticated access to a building system at the Sochi Winter Olympics.
Is Niagara Fox still exposed on the internet today?
Yes, and the scale has grown rather than shrunk. CyberScoop reported in December 2018 that the FBI had found roughly 700 US industrial control systems accepting unauthenticated connections on Fox's port 1911, while Shodan separately indexed around 20,000 exposed Fox endpoints in the US alone. Censys's ARC blog recorded Tridium Niagara internet exposure growing from 39,371 to 43,167 instances — a 9.2% increase — between January and June 2025, with the largest concentration in the United States and over 3,000 instances hosted on AWS. Most recently, Nozomi Networks Labs disclosed 13 vulnerabilities (10 assigned CVEs, CVE-2025-3936 through CVE-2025-3945) in Niagara Framework and Niagara Enterprise Security versions up to 4.10u10 / 4.14u1 on 23 July 2025, including a chainable exploit combining admin-privilege escalation with TLS private-key extraction; CISA's later advisory ICSA-25-219-02 (covering Johnson Controls FX Server, FX80 and FX90, which bundle Niagara 4.10u10/4.14u1) references that same batch, confirming it reaches products beyond Tridium's own branding.
Does Niagara 4 actually fix the authentication and encryption gap?
For the connections that are configured to use it, yes. Tridium's Niagara 4 Hardening Guide (January 2025 edition) instructs administrators to set a station's FoxS Enabled and FoxS Only properties to true, explicitly stating that plain, unencrypted fox "should not be allowed" unless absolutely required — FoxS wraps Fox in TLS on port 4911 instead of the plaintext default on port 1911. Niagara 4.15 went further, adding PKI/mutual-TLS client-certificate authentication at no extra license cost, SAML 2.0 single sign-on, and Google Authenticator-compatible TOTP two-factor authentication. That encrypted path has had its own bugs, though: CVE-2020-14483, a TLS connection-handling timeout flaw in Niagara 4.6 through 4.8 and Niagara Enterprise Security 2.4/4.8, was fixed only in Niagara 4.9 (Honeywell/Tridium Security Bulletin SB 2020-Tridium-2) — a reminder that enabling FoxS is necessary, not sufficient, without also staying current on firmware.
What should a building owner or integrator check first?
In roughly the order that matches where real exposure has actually been found: first, confirm the Niagara/JACE station isn't directly reachable from the internet at all — the FBI's and Censys's findings above, not a cryptographic break, describe the most common real-world failure. Second, check each station's FoxS Enabled and FoxS Only settings and disable plaintext fox on port 1911 unless a specific legacy integration still requires it. Third, patch to a current Niagara or Niagara Enterprise Security release that closes the 2025 Nozomi-disclosed CVEs (fixed in 4.14.2u2, 4.15u1 and 4.10u.11) and the 2020 TLS timeout bug (fixed in 4.9). Fourth, treat Johnson Controls FX Server, FX80 and FX90 — which bundle the Niagara Framework under a different brand — as the same device class for patching purposes, per CISA's ICSA-25-219-02. None of this is a one-time fix: Niagara's own advisory history across more than a decade shows new findings continuing to surface in both the legacy plaintext path and, occasionally, the encrypted one.
In this cluster
Questions about this page?