Armatura One: five CVEs and steps operators can take now.

Executive summary

I was helping an organization secure a recently deployed Armatura One system. As part of that work, I ensured the server running Armatura One was covered by endpoint detection and response (EDR) software with vulnerability scanning. The scan flagged outdated third-party libraries embedded in the Armatura package. During triage, Apache ActiveMQ stood out: the bundled version was affected by CVE-2023-46604, a remote-code-execution flaw disclosed in 2023. The scan established that the library was present. With the organization's authorization, I checked whether Armatura One actually exposed the vulnerable service.

In the Armatura One 4.3.0 installation I tested, the OpenWire listener was reachable over the network. A benign test confirmed unauthenticated code execution with the broker service's privileges. That result led me to examine what someone with access to the server could do next, and I identified four Armatura-specific credential vulnerabilities. I reported the findings through ZKTeco PSIRT and CERT/CC; on October 1, 2026, CISA published ICSA-26-274-01 covering all five and credited Andrew Capobianco of RewCon.co.

CVE-2023-46604 is the highest-severity issue (CVSS 9.8). The CVE was already public; this research established its exposure in the Armatura One configuration I tested and reported the additional product-specific issues.

The other four CVEs concern a fixed encryption key, a vendor-defined database password, and credentials written to logs. CISA says exploitation could allow unauthorized database access or control of the physical access-control system. I did not operate doors or extract data from the live installation. As of its October 1, 2026 advisory, CISA was not aware of exploitation specifically targeting Armatura One; CVE-2023-46604 has been exploited against other ActiveMQ deployments.

Armatura has published a security bulletin and released updates. Restrict access to the OpenWire service now and keep that restriction in place after upgrading. Plan the upgrade with Armatura or your installer, then verify the version, service configuration, and network reachability on the running system.

What should Armatura One operators do?

1. Restrict network access now. Keep the server off the public internet and separate it from ordinary business networks. Block inbound TCP 61616 at both the network and Windows host firewalls. Test reachability from every relevant segment, including user networks and VPN-connected hosts. A server need not be internet-facing to be exposed. Keep the firewall rules after upgrading. If 61616 was reachable from an untrusted network, review EDR alerts and host and broker logs for suspicious activity, following your incident-response process if warranted. Exposure alone does not establish compromise.

2. Disable the OpenWire listener with vendor guidance. ZKTeco PSIRT confirmed to me that TCP 61616 could be closed while the required MQTT service remained available. On the 4.3.0 installation I examined, ...\ArmaturaOne\Pubs\activemq\conf\activemq.xml contained a <transportConnector name="openwire" ... 61616 .../> entry. For a matching configuration, back up that file, comment out the OpenWire connector, and restart the broker service. Leave required MQTT connectors in place. Have Armatura or your installer confirm the exact change for your release before editing a production server. Then verify that 61616 is neither listening nor reachable, and test door operation and device events.

3. Plan the upgrade. Identify the installed release line and version. Ask Armatura or your installer for the corresponding package, its checksum, and the supported procedure. Back up the system before upgrading, as the vendor bulletin instructs. Schedule a maintenance window and agree on checks for door operation, device events, and rollback.

4. Verify the upgraded installation. Check the installed version and compare the running OpenWire listener state with Armatura's guidance for that release. Verify that TCP 61616 cannot be reached from untrusted networks and that network and host firewall rules are still active. Test door operation and device events before closing the maintenance window.

5. Address credentials already stored or logged. Ask Armatura whether the upgrade changes fixed credential values on existing installations, which database, application, and broker credentials need rotation, and how to rotate them safely after upgrading. Identify historical logs, backups, and support bundles that may hold old passwords; protect or remove them through your normal retention process. Coordinate rotation with the installer to avoid disrupting the application or devices.

What did the research establish?

The tested 4.3.0 installation bundled Apache ActiveMQ 5.15.10. I established the credential findings through analysis of the installed software and its logs, then assessed the possible path from host access to application control without operating doors on the live system.

The five published findings are:

The affected-service and credential findings require different checks: verify the running listener and network reachability, then obtain Armatura's supported credential-rotation guidance.

What remains for Armatura and ZKTeco to address?

ZKTeco PSIRT was responsive to the disclosure, confirmed the interim port mitigation, and participated in the coordination with CERT/CC and CISA. Armatura released a bulletin and updated software. The next step is to make remediation clear and verifiable for every customer:

1. Tell customers how to restrict exposure immediately. Notify installed customers directly and publish version-specific instructions for blocking TCP 61616 and verifying the OpenWire listener is disabled, while preserving required MQTT traffic. These controls should remain in place after an upgrade.
2. Make security updates part of the product. On September 24, 2026, the authenticated ZKTeco USA download center I checked still linked to 4.3.0 without a visible security warning. Armatura's bulletin separately directed customers to request the patch by email. The customer I was helping was told by ZKTeco USA support to expect 4.6.1 the following week; on September 29, I received the package and saw it available in the download center. Armatura One should alert administrators when a security update applies to their release and notify registered customers and installers directly. Online update checks should be optional; installation should be administrator-initiated and scheduled. Provide signed, verifiable packages and an offline path for isolated sites, with door and device checks after upgrading. Keep old downloads clearly marked when they remain available.
3. Publish verification and credential guidance. Explain how customers confirm that 61616 is closed after an upgrade and which credentials need rotation. Provide historical-log and backup-handling guidance; old support bundles may still contain passwords.
4. Explain the ActiveMQ maintenance plan. Identify the ActiveMQ version in each fixed release and publish a path to a supported version. The tested 4.3.0 installation bundled 5.15.10, and Apache lists the 5.15 branch as inactive; customers need to know how Armatura tracks updates to bundled components.
5. Clarify the scope of the “Safe to Host” assessment. Armatura's May 2026 announcement says V4.5.1 passed an assessment with no reported vulnerabilities across the listed severity levels. CISA's advisory identifies affected mainstream releases before 4.7.2. State which release line V4.5.1 belongs to and which build, configuration, and embedded components the assessment covered so customers can reconcile the two notices.

Disclosure and references

I reported the OpenWire finding to ZKTeco PSIRT on August 12, 2026, and the additional credential findings on August 21. CERT/CC coordinated the disclosure. Armatura's bulletin carries a September 14 date; CISA published ICSA-26-274-01 on October 1 and credited the report to Andrew Capobianco of RewCon.co.

Primary references: CISA advisory, Armatura security bulletin, Apache ActiveMQ CVE-2023-46604 guidance, and Apache release status.