CISA Alerts on Dingtian DT R002 Credential Flaws with CVSS 8.7

CISA’s latest ICS bulletin republishes a focused alert: an advisory for the Dingtian DT‑R002 relay board (ICSA‑25‑268‑01), which CISA published on September 25, 2025 — not October 14 — and which documents two insufficiently protected credentials vulnerabilities that allow unauthenticated retrieval of account information and a proprietary protocol password.

Background / Overview​

Industrial Control Systems (ICS) advisories from the Cybersecurity and Infrastructure Security Agency (CISA) are short, operationally focused notices designed to give asset owners and defenders the who, what, and how needed to reduce exposure quickly. This particular advisory centers on the Dingtian DT‑R002, a small relay I/O board used in process and manufacturing environments, and assigns two CVE identifiers for credential disclosure issues: CVE‑2025‑10879 and CVE‑2025‑10880. CISA calculates a CVSS v4 base score of 8.7 for each finding and classifies the flaws as exploitable remotely with low attack complexity.
That technical summary is corroborated outside of CISA’s advisory: independent reporting and OT‑security news outlets republished the same CVE details and severity scoring, and noted that the vendor has not responded to coordination requests — a practical problem for defenders that raises the bar for mitigations and containment.
Why Windows administrators should pay attention: modern IT‑OT convergence means many ICS ecosystems are managed or monitored by Windows servers and engineering workstations. Vulnerabilities in field devices — even those with small embedded OS footprints — can become enterprise incidents when device management, historians, HMIs, or remote access tools run on Windows hosts that bridge to control networks. Community analysis and earlier CISA rollups demonstrate the recurring theme: ICS bugs frequently require enterprise‑level compensations (segmentation, hardened Windows endpoints, and strict remote access controls).

---

What CISA says about the Dingtian DT‑R002 advisory​

Executive technical facts (verified)​

• Advisory: ICSA‑25‑268‑01 (Dingtian DT‑R002).
• Release date: September 25, 2025 (initial publication).
• Vulnerabilities: Two Insufficiently Protected Credentials issues (CWE‑522).
• CVEs: CVE‑2025‑10879 and CVE‑2025‑10880.
• Severity: CVSS v4 base score 8.7 for each CVE; CISA characterizes the issues as remote, low complexity, high confidentiality impact.
• Impact summary: An unauthenticated attacker can enumerate a current user’s username and can extract the proprietary “Dingtian Binary” protocol password via unauthenticated GET requests.

Research and disclosure​

CISA lists the researchers who reported the issues: Nicolas Cano and Reid Wightman of Dragos. The advisory also notes no known public exploitation at the time of publication, and it documents the vendor’s lack of response to coordination requests. That vendor non‑response is explicitly stated in the advisory and has been independently reported by OT‑security outlets.

---

Why this matters: attack surface and real‑world risk​

For defenders, the two core problems here are simple and severe:

• Credentials exposed without authentication: Retrieving a username or a protocol password without authentication is a direct elevation of an attacker’s situational awareness and their ability to pivot. With a protocol password in hand, an attacker can impersonate legitimate management or telemetry traffic, manipulate device behavior, or craft replay/command sequences against other devices that trust the same secret.
• Low exploitation complexity + network exposure: CISA’s scoring and vector show these are network‑accessible weaknesses that do not require complex chaining — the kind of vulnerabilities adversaries can scan for and exploit at scale if devices are exposed to less‑restricted networks. That risk increases dramatically in environments where OT networks are reachable from corporate networks or remote maintenance channels.

Operational consequences range from localized process disruption to integrity compromises that could alter setpoints, disable safety interlocks, or enable persistent footholds — outcomes that are especially concerning when the affected equipment is deployed in critical manufacturing contexts. The advisory lists the sector and indicates worldwide deployment, but precise device counts are not published and therefore remain unverified. Treat the “worldwide” tag as an indicator of distribution—not as a quantified metric.

---

Practical, prioritized actions for IT and OT teams​

The following is a concise action plan you can use immediately. Actions are ranked by speed-to-protection and operational impact.

• Inventory: Identify any on‑prem Dingtian DT‑R002 devices and the networks they live on.
• Query asset inventories, procurement records, network device lists, and existing OT discovery tools.
• If device model strings are not recorded, inspect switch MAC‑tables and ARP logs for unusual UDP/TCP endpoints (see detection below).
• Contain (fast, low‑impact): Block remote access to affected ports from untrusted networks.
• Block TCP/80 (HTTP) to DT‑R002 devices at the plant firewall or edge ACLs.
• Block UDP/60000 and UDP/60001 (the Dingtian protocol) from any network segment that does not require device management. These are the explicit ports CISA and the Dragos researchers recommend restricting.
• Isolate high‑value assets: Enforce network segmentation so that engineering workstations, corporate IT, and vendor remote‑maintenance paths do not have unfettered access to the OT control plane.
• Harden Windows hosts that mediate OT access:
• Remove unnecessary admin accounts from engineering workstations.
• Enforce MFA for vendor VPNs and remote access portals that allow control network bridging.
• Apply application allowlisting and endpoint EDR with process auditing for any HMI, historian, or engineering tool. The intersection between Windows endpoints and OT assets is a common escalation path in ICS incidents.
• Detection: Add monitoring for suspicious activity and indicators:
• Alert on unauthenticated HTTP GET requests to DT‑R002 management endpoints.
• Capture and inspect UDP traffic on ports 60000/60001 for unusual session establishment or credential harvest attempts.
• Record and retain network captures for forensic analysis if anomalies are observed.
• Vendor coordination & support:
• Contact Dingtian support and log all interactions; if the vendor remains unresponsive, document compensating controls and escalate to risk acceptance channels.
• If devices are in U.S. federal environments, follow CISA reporting guidance per the advisory.
• Longer term: Replace or segregate devices that cannot be safely mitigated or updated. Insist on secure procurement terms for future purchases (signed firmware, vulnerability disclosure commitments, and secure update mechanisms).

These steps prioritize immediate exposure reduction (network blocks and segmentation) before higher‑impact measures such as device replacement or in‑place code changes.

---

Detection guidance and indicators of compromise (practical details)​

• Network indicators:
• Unexpected inbound TCP/80 requests hitting management IPs on control subnets.
• UDP packets sourced from external or unexpected hosts to UDP/60000 or UDP/60001.
• Repeated GET requests with unusual query parameters against device HTTP endpoints.
• Host indicators:
• New or unknown processes on engineering Windows workstations that are communicating with DT‑R002 IPs.
• Suspicious vendor support connections or remote sessions originating outside maintenance windows.
• Response checklist:
• If you observe unauthenticated GETs that return credential material, perform immediate containment: isolate the device, take a forensic snapshot, and preserve logs for vendor/CISA coordination.
• Do not perform invasive remediation on production devices without an approved maintenance window and rollback plan.

These detection rules are practical starting points; refine them to your environment and test them in a lab prior to deploying broad network restrictions.

---

Strengths and limitations of CISA’s advisory and the broader disclosure​

Strengths — what CISA did well​

• Clear technical summary: CISA provides concise vulnerability descriptions, CVE IDs, CVSS v4 scoring, and explicit affected ports. That makes it fast for defenders to implement focused mitigations.
• Researcher attribution: Naming the reporting researchers (Dragos personnel) adds confidence to the triage chain and helps defenders lookup further research or tooling tied to the discovery.
• Actionable mitigations: The advisory includes immediate mitigations — restricting HTTP and the Dingtian UDP ports — and reiterates general ICS best practices (segmentation, isolation, VPN caution). That operational framing is appropriate for time‑sensitive responses.

Limitations and unresolved risks​

• Vendor non‑response: Dingtian’s lack of engagement leaves defenders without vendor‑supplied patches or firmware updates. That forces operators into long‑term compensating control strategies rather than an assured fix. This is explicitly noted in CISA’s advisory and echoed in independent reporting.
• No exploit telemetry: CISA says there is no known public exploitation at publication time — useful, but not a substitute for active hunting. Lack of public exploitation data can be comforting, yet it does not preclude undiscovered targeted misuse.
• Asset‑count opacity: The advisory identifies the sector (“Critical Manufacturing”) and says the product is deployed worldwide, but it does not provide distribution metrics or a published affected population. That lack of quantitative exposure assessment means organizations must assume the worst and prioritize discovery and containment.

---

Systemic takeaways for Windows admins and enterprise security teams​

• Treat ICS advisories as enterprise advisories. Even if a vulnerability targets a small relay board, the risk footprint includes Windows HMIs, historians, and remote maintenance clients. The historical pattern of ICS advisories shows repeated classes of issues: poor authentication, insecure default services, and exposed maintenance interfaces — all of which can be abused via adjacent Windows hosts.
• Maintain an asset‑aware vulnerability program that includes OT. Inventory gaps are the single biggest operational hazard. If you cannot find the device, you cannot protect it.
• Enforce strict remote‑vendor access controls. Vendor connectivity often provides the easiest path to operational impact. Require MFA, just‑in‑time access, logging, and vendor accountability clauses in procurement.
• Invest in OT‑aware monitoring. Network detection that understands ICS protocols and unusual UDP flows (and that integrates with Windows EDR telemetry) materially improves the time to detect and respond.

---

Critical analysis and judgment call​

CISA’s advisory is technically sound, timely, and operationally useful. By publishing CVE identifiers, explicit port numbers, and severity scoring, the advisory enables defenders to adopt immediate measures. It is also appropriate for CISA to note the vendor’s non‑participation — that is relevant operational intelligence and should motivate asset owners to assume ongoing risk until the vendor provides a coordinated fix.
However, the advisory also underlines a recurring structural problem in the ICS ecosystem: many low‑cost or niche device vendors do not maintain mature vulnerability response programs or secure default configurations. That systemic deficit shifts the burden of safety onto asset owners and enterprise security teams, who must implement compensations that range from trivial (firewall ACLs) to expensive or operationally disruptive (device replacement or network redesign). Relying solely on vendor fixes is not a robust long‑term strategy; procurement, contract language, and supply‑chain considerations need to evolve to require secure product lifecycles.

---

What we verified and what remains uncertain​

Verified facts:

• CISA published ICSA‑25‑268‑01 (Dingtian DT‑R002) on September 25, 2025; the advisory includes CVE‑2025‑10879 and CVE‑2025‑10880 and the technical details summarized above.
• The vulnerabilities are credential exposure issues (CWE‑522) and are rated at CVSS v4 8.7.
• The researchers credited are Nicolas Cano and Reid Wightman (Dragos).
• Several independent OT‑security outlets corroborated the advisory text and reported the vendor non‑response.

Unverified or unquantified claims:

• The precise number and geographic distribution of affected DT‑R002 devices are not published; any assertion about device counts or market penetration should be treated as speculative without vendor or market‑survey data.
• There is no public evidence (per CISA at time of publication) of exploitation in the wild; absence of evidence is not evidence of absence, so defenders must still actively hunt and monitor.

---

Checklist: immediate actions for the next 24–72 hours​

• 24 hours:
• Block TCP/80 and UDP/60000–60001 from untrusted networks to OT subnets.
• Identify any DT‑R002 devices on your networks and tag them in asset management.
• Enable logging and capture traffic to/from identified devices.
• 48 hours:
• Harden engineering workstations (Windows) that can reach DT‑R002 devices: revoke unnecessary admin rights, enable EDR logging, and enforce MFA for remote access.
• Apply network micro‑segmentation to separate OT from IT.
• 72 hours:
• Conduct targeted threat hunting for signs of credential enumeration or unexpected protocol usage.
• Open a vendor support ticket with Dingtian; document all communications for audit and risk reporting.

---

Final assessment and strategic recommendations​

The Dingtian DT‑R002 advisory is a classic ICS operational problem: high severity, easy discovery, and limited immediate vendor remediation. The correct immediate posture is defensive: assume network‑accessible devices are at risk, reduce exposure through ACLs and segmentation, monitor aggressively, and treat any confirmed data disclosure as a high‑impact incident requiring isolation and forensic capture.
Longer term, organizations that rely on ICS equipment must reexamine procurement and lifecycle management: require vendors to support coordinated disclosure, sign firmware, and provide secure update mechanisms. Windows administrators and enterprise security teams must be part of OT vulnerability programs — these are enterprise problems, not OT‑only problems. Community analysis and prior CISA rollups reinforce this point: proactive cross‑domain coordination, asset hygiene, and a defense‑in‑depth posture remain the best practical defense against these recurring ICS threats.
CISA’s advisory gives the community what it can in the absence of a vendor fix: specific CVEs, explicit ports to restrict, and operational guidance. Put those tokens to work now — inventory, block, monitor, and document. The rest is an organizational choice: accept residual operational risk or invest to remove that risk permanently.

---

(Technical readers should consult the full advisory for device‑level details, CVE descriptors, and the official CISA mitigation language.)

---

Source: CISA CISA Releases One Industrial Control Systems Advisory | CISA