Tridium’s Niagara Framework® is a leading software framework designed to connect, manage, and control diverse devices in building management, industrial automation, and smart infrastructure environments. It acts as a middleware platform that enables different systems — such as HVAC, lighting, energy management, and security — to interoperate seamlessly, making it a critical backbone for many internet of things (IoT) technologies across industries worldwide.
Recently, researchers at Nozomi Networks uncovered 13 vulnerabilities affecting the Tridium Niagara Framework®. Recently, researchers at Nozomi Networks uncovered 13 vulnerabilities affecting the Tridium Niagara framework. These vulnerabilities are fully exploitable if a Niagara system is misconfigured, thereby disabling encryption on a specific network device (which produces a warning on the security dashboard.) If chained together, they could allow an attacker with access to the same network — such as through a Man-in-the-Middle (MiTM) position — to compromise the Niagara system. However, this would depend on a specific network service being configured without encryption, allowing the attacker to collect sensitive data from the network.
In response, Tridium worked swiftly to issue a security advisory and released patches to address these vulnerabilities.
This blog post discusses the findings discovered in Tridium Niagara Framework®, their potential impacts, and the recommended mitigations.
Research Scope
The Niagara Framework® (“Niagara”), developed by Tridium (a Honeywell company), is a widely adopted platform used to integrate, manage, and control diverse operational systems and devices within a single environment.
Niagara provides a vendor-neutral solution that connects sensors, controllers, and equipment from different manufacturers, translating their communication protocols into a unified data model.
From a technical point of view, Niagara is made up of two main software components installed and both running on a single hardware device:
- The Platform is the underlying software environment that provides the core services required to create, deploy, run, and supervise Niagara stations.
- The Station represents the operational component that communicates with devices, processes data, and provides user interfaces for monitoring and control.
These two components can be managed through Niagara Workbench, the integrated development and configuration tool, which serves as the primary graphical user interface for engineers, developers, and integrators.
Because Niagara often connects critical systems and sometimes bridges IoT technology and information technology (IT) networks, it could represent a high-value target. A vulnerability in Niagara has the potential to not only threaten digital assets; it can also lead to other real-world consequences, impacting safety, productivity, and service continuity across sectors like commercial real estate, healthcare, transportation, manufacturing, and energy.
Potential Impact of the Vulnerabilities
These vulnerabilities are fully exploitable if a Niagara system is misconfigured, thereby disabling encryption on a specific network device (which produces a warning on the security dashboard.) If chained together, they could allow an attacker with access to the same network — such as through a Man-in-the-Middle (MiTM) position — to compromise the Niagara system. This could enable:
- Lateral Movement (T1210 – Exploitation of Remote Services): An attacker could use a compromised device as a beachhead to pivot across an organization's network, targeting other IoT or IT systems.
- Operational Disruptions (T1499 – Endpoint Denial of Service): Malicious actors could alter building automation processes, disable critical systems, or cause broader outages, leading to safety risks, service interruptions, and financial losses.
Given the critical functions that can be controlled by Niagara-powered systems, these vulnerabilities may pose a high risk to operational resilience and security provided the instance has not been configured per Tridium’s hardening guidelines and best practices.
Vulnerability List and Affected Versions
Nozomi Networks discovered these vulnerabilities in Niagara Framework version 4.13. Furthermore, the vendor confirmed that the following versions also remain affected:
- Niagara Framework and Niagara Enterprise Security version 4.10u10 and earlier
- Niagara Framework and Niagara Enterprise Security version 4.14u1 and earlier
The table below lists the vulnerabilities confirmed by Tridium. It is important to note that five of the 13 identified issues were consolidated into two CVEs, resulting in a total of ten distinct CVEs. Results are sorted by CVSS 3.1 score from most to least severe.
Vulnerability Spotlight
After carefully analyzing the vulnerabilities described above, we identified a compelling attack chain that could enable an attacker, starting with having access inside the network (adjacent attacker), to compromise a Niagara-based target device within a network. This includes compromising both the Station and the Platform, and ultimately achieving root-level remote code execution (RCE) on the device itself.
Two vulnerabilities are involved in the attack chain.
CVE-2025-3943
The Niagara Framework employs a CSRF token to validate every state-changing HTTP request and prevent cross-site request forgery attacks. However, analysis revealed that the CSRF refresh token is transmitted by the Niagara Workbench software through the /ord endpoint, specifically via the spy functionality, using the GET method. Because data sent through GET requests can often be logged, and the CSRF token remains unchanged for the entire session, attackers may be able to retrieve it from logs and exploit it to craft malicious CSRF attacks. Below is an example of a request to the /ord endpoint passing the CSRF refresh token through the GET method.
It is important to highlight that interacting with the Niagara Workbench administration panel frequently triggers CSP violation reports through various HTTP requests. As a result, requests containing the refresh anti-CSRF token are logged. Furthermore, if Syslog is enabled, these logs may also be transmitted across the network — potentially over an unencrypted channel — increasing the risk of token exposure.
Here an example of generated CSP report sent to a specific /csp-reports endpoint:
The CSP violation report furthermore generates the following logs sent over the network through Syslog.
As a result, if the Syslog service is configured to send data using an unencrypted channel, an adjacent attacker with the capability to sniff the network traffic (e.g: through a MiTM attack) would be able to intercept the anti-CSRF refresh token.
CVE-2025-3944
The Niagara Framework® offers a secure file transfer feature that restricts administrators from accessing or modifying sensitive files; however, it does not properly safeguard the /etc/dhcpd/dhcpd.conf file on devices running the QNX-based Niagara operating system. An authenticated attacker with administrative privileges can overwrite this file and leverage specific dhcpd.conf hooks — such as on commit, on release, and on expiry — to execute arbitrary code with root privileges on the Niagara QNX-based operating system.
Here is an example of an on-commit hook which, when inserted into a legitimate dhcpd.conf file, can trigger the exfiltration of the contents of root-readable files such as /etc/passwd and /etc/shadow saving the data inside the /tmp/out file.
Preconditions for the Attack
To successfully carry out this attack chain, two conditions must be met:
- The attacker must be able to sniff or perform a Man-in-the-Middle (MitM) attack on the traffic to and from the Tridium Niagara device.
- Syslog functionality must be enabled and must be configured to forward logs to a Syslog server without encryption, a setting which produces a warning on the security dashboard.
Figure 3 shows a possible attack scenario where a Niagara-based Tridium Jace 8000 is deployed on a local network.
If these preconditions are satisfied, the attacker can execute the following steps:
1. Intercept the anti-CSRF refresh token sent over the network (CVE-2025-3943): As said, by exploiting CVE-2025-3943, an adjacent attacker sniffing the network is able to analyze the Syslog network traffic in order to intercept the anti-CSRF token that is sent over the network due to the CSP violation report generated by the Niagara Workbench software (Figure 4).
2. Escalate Log Collection: After obtaining the anti-CSRF refresh token, the attacker forges a CSRF attack and tricks the administrator into visiting a crafted link, such as /ord?spy:/logSetup/ALL- web.jetty$3ftoken$…, which changes the logging level of the web.jetty component to ALL. This setting causes the content of all incoming HTTP requests and responses to be fully logged (Figure 5 – step 1 and 2).
3. Session Hijacking: By analyzing the Syslog data sent over the network, the attacker extracts the administrator's JSESSIONID session token. Using this session ID, the attacker connects to the Station with full administrative privileges and creates a new backdoor administrator user for persistent access (Figure 5 – step 3 and 4).
4. Platform Compromise via Certificate Theft: Leveraging the administrative access, the attacker abuses a dedicated functionality to download the private key associated with the device's TLS certificate. Since both the Station and Platform share the same certificate and key infrastructure, this enables the attacker to MitM all future sessions to the device, even if they are TLS- encrypted. Full access to the Platform is now obtained (Figure 6).
5. Root Remote Code Execution (RCE): With control of the Platform, the attacker immediately exploits CVE-2025-3944, vulnerability that provides root-level RCE on the device, achieving complete takeover.
Even if the final RCE step is not pursued, this technique allows full compromise of both Station and Platform environments, including installations running on Windows systems.
Mitigation and Recommendations
Tridium has addressed these vulnerabilities through security patches for the Niagara Framework. A security report has been published by the Tridium product security team. Asset owners and operators are strongly urged to:
- Review Tridium’s security advisory for detailed guidance.
- Update affected Niagara installations to the latest patched version as soon as possible.
- Implement network segmentation to limit exposure of systems.
- Monitor network traffic for the presence of vulnerable assets and suspicious activity related to Niagara devices—for example, using the vulnerability and threat detection capabilities of Nozomi Networks Guardian. To learn more or see it in action, request a demo today.
Taking prompt action is vital to protect critical infrastructure and maintain operational integrity.
