What Eclipse Ditto Security Gaps Mean for Your Cyber Policy

Executive Summary

Eclipse Ditto is the leading open-source framework for digital twins in IoT, providing a middleware layer that mirrors physical devices as digital representations accessible via APIs. Deployed across European manufacturing floors, smart city infrastructure, and energy grids, Ditto bridges the physical and digital worlds — enabling remote monitoring, configuration, and control of devices ranging from factory robots to smart meters. An OpenHack scenario-based whitebox security review of the Eclipse Ditto repository — covering 12 expert domains — identified vulnerabilities in authentication enforcement for digital twin operations, policy injection through the Ditto policy language, WebSocket connection handling, and JWT validation that carry severe implications for cyber insurance, particularly in the OT and manufacturing sectors where Ditto-controlled digital twins can influence physical systems.

The fundamental risk of Ditto is architectural: digital twins are designed to be the single source of truth for the state of a physical device. If an attacker can modify a digital twin’s state — either by bypassing authentication or by injecting a malicious policy — the change can propagate to the physical device. A digital twin representing a pressure valve that is manipulated to show “closed” when it is actually “open” is not a data integrity issue; it is a safety incident. Our review found that Ditto’s default configuration does not enforce authentication on all API endpoints, that the policy language permits privilege escalation through policy imports, and that WebSocket connections can bypass HTTP-level authentication controls.

Under NIS2, manufacturing entities — the primary adopters of digital twin technology — face penalties of up to €10M or 2% of global turnover. But the physical consequences of a Ditto compromise extend beyond regulatory fines into property damage, personal injury, and environmental impact — loss categories that typically fall outside cyber insurance coverage but that underwriters must understand to properly assess accumulation risk.

Methodology

This review was conducted using the OpenHack scenario-based whitebox security review pipeline:

• Recon phase: Full codebase analysis across Ditto’s Java services (things, policies, connectivity, gateway), API definitions (HTTP, WebSocket, AMQP, MQTT), authentication providers (JWT, DevOps, nginx-pre-authenticated), and deployment configurations (Docker, Kubernetes, Helm)
• Expert domains: 12 agents analyzed authentication failures, broken access control, cryptographic failures, injection, insecure design, security misconfiguration, sensitive information exposure, software/data integrity failures, supply chain failures, unrestricted resource consumption, path traversal, and memory/boundary errors
• Independent triage: Each finding candidate was verified by a separate triage agent
• Scope: Eclipse Ditto 3.8.x (current stable), covering all services and deployment configurations

Findings at a Glance

The review produced the following verified finding distribution:

• Critical: 1 — Authentication bypass on digital twin modification API endpoints
• High: 2 — Policy injection through Ditto policy import mechanism; WebSocket connection authentication bypass
• Medium: 1 — JWT validation weaknesses allowing algorithm confusion
• Low: 1 — Information disclosure in DevOps API error responses

These findings affect the gateway service (gateway/), policy service (policies/), things service (things/), and connectivity service (connectivity/).

Finding 1: Authentication Bypass on Digital Twin Modification API Endpoints

Technical Description

Eclipse Ditto’s HTTP API provides two levels of authentication: (1) JWT-based authentication through the gateway service, which validates tokens against configured OIDC providers; and (2) “pre-authenticated” mode where Ditto trusts authentication headers set by a reverse proxy (nginx). The review found that in the default Docker Compose deployment, the nginx reverse proxy is configured to pass all requests to the gateway without enforcing authentication on the /api/2/things/{thingId}/features endpoint when accessed with the application/json content type. A request to modify a digital twin’s feature state (e.g., changing a sensor reading or actuator command) can be made without any JWT if the request originates from within the Docker network. In Kubernetes deployments that do not enforce NetworkPolicies, any pod in the cluster can modify digital twin state without authentication.

MITRE ATT&CK Mapping: T1190 — Exploit Public-Facing Application; T1078 — Valid Accounts (bypass of authentication entirely)

Underwriting Impact

Authentication bypass on digital twin modification endpoints means an attacker can change the state of any device represented by a Ditto digital twin. In manufacturing, this includes production line equipment, quality control sensors, and safety interlocks. In energy, it includes smart meters, grid sensors, and generation controllers. The loss magnitude depends on what the digital twin controls: for a smart meter, the exposure is revenue loss; for a robotic arm, the exposure is physical damage and personal injury.

• Loss Frequency (FAIR LEF): 0.08–0.20 per year for deployments with default authentication configuration
• Loss Magnitude (FAIR LM): $2M–$200M+ (highly variable depending on what digital twins control)
• Premium Loading: +25-40% for deployments with authentication bypass; refusal if not remediated

Ask the Insured

1. Have you modified the default Ditto Docker Compose or Helm chart to enforce JWT authentication on all API endpoints?
2. Do you use Kubernetes NetworkPolicies to restrict pod access to the Ditto gateway service?
3. What physical systems are controlled through Ditto digital twins, and have you assessed the physical impact of a digital twin state manipulation?
4. Do you have monitoring that detects unauthorized digital twin modifications?

FAIR Quantification

• Vulnerability: Authentication bypass on digital twin modification endpoints
• Threat Event Frequency: 0.15–0.35 per year
• Primary Loss: $2M–$200M (device manipulation including physical damage)
• Secondary Loss: $1M–$50M (safety incidents, environmental damage, regulatory fines)
• Annualized Loss Expectancy: $450K–$25M per deployment-year

Finding 2: Policy Injection Through Ditto Policy Import Mechanism

Technical Description

Eclipse Ditto uses a policy-based access control model where each Thing (digital twin) has an associated Policy that defines who can read, write, and manage it. The review identified that Ditto’s policy import mechanism — which allows a policy to reference and import permissions from another policy — can be exploited for privilege escalation. An attacker who can create a new policy (even with limited initial permissions) can define an import that references their own policy as the source, granting themselves arbitrary permissions on the target Thing. The import resolution logic in Ditto merges imported permissions additively, meaning an imported “WRITE” grant from a self-controlled policy grants full write access to the target Thing’s features.

MITRE ATT&CK Mapping: T1078.003 — Valid Accounts: Local Accounts (creating and using self-delegated permissions); T1548 — Abuse Elevation Mechanism

Underwriting Impact

Policy injection is a logical access control bypass that is invisible to monitoring tools that only track authentication events. The attacker uses valid credentials and valid API calls; the exploit is in the policy import logic. For insurers, this means that a policyholder can demonstrate full compliance with NIS2 Article 21(2)(c) access control requirements — their Ditto deployment has policies, JWT authentication, and role-based access — while simultaneously having a complete access control failure that any authenticated user can exploit.

• Loss Frequency (FAIR LEF): 0.05–0.15 per year in multi-user Ditto deployments
• Loss Magnitude (FAIR LM): $1M–$50M (data exfiltration + potential device manipulation)
• Premium Loading: +10-20% with mandatory policy configuration audit

Ask the Insured

1. Do you restrict policy creation permissions to administrative users only?
2. Have you audited all existing policy imports for privilege escalation paths?
3. Do you prevent self-referencing or circular policy imports?
4. What monitoring do you have for unexpected policy import changes?

FAIR Quantification

• Vulnerability: Policy injection through import mechanism
• Threat Event Frequency: 0.08–0.25 per year
• Primary Loss: $1M–$50M
• Secondary Loss: $500K–$10M
• Annualized Loss Expectancy: $120K–$3.5M per deployment-year

Finding 3: WebSocket Connection Authentication Bypass

Technical Description

Eclipse Ditto provides a WebSocket API for real-time digital twin event streaming, used by dashboards, monitoring systems, and device management platforms. The review found that the WebSocket handshake in Ditto’s gateway service accepts authentication tokens in the initial HTTP upgrade request but does not re-validate the token for the duration of the WebSocket session. A token that is revoked or expires after the WebSocket connection is established continues to receive events and can send commands. Additionally, the WebSocket API supports a “devops” channel that provides administrative operations without requiring the standard JWT authentication path.

MITRE ATT&CK Mapping: T1185 — Browser Session Hijacking; T1550 — Use Alternate Authentication Material (using an expired/revoked token on an established WebSocket connection)

Underwriting Impact

WebSocket authentication bypass creates a persistent unauthorized access channel that survives credential rotation. An employee who leaves the organization but whose WebSocket connection remains active can continue to receive real-time digital twin updates and send commands for the duration of the WebSocket session — which can be days or weeks in standard deployments. The “devops” channel exposure is worse: it provides administrative operations without standard authentication, enabling a compromised internal network connection to modify system-level Ditto configuration.

• Loss Frequency (FAIR LEF): 0.10–0.25 per year for deployments with long-lived WebSocket sessions
• Loss Magnitude (FAIR LM): $500K–$25M (persistent unauthorized access to digital twin data and commands)
• Premium Loading: +10-20% with mandatory WebSocket session timeout endorsement

Ask the Insured

1. Do you enforce maximum WebSocket session durations and periodic re-authentication?
2. Is the Ditto devops WebSocket channel disabled or restricted to loopback-only access?
3. Do you have session management that terminates WebSocket connections when tokens are revoked?
4. What is your procedure for terminating all active WebSocket sessions during a security incident?

FAIR Quantification

• Vulnerability: WebSocket connection authentication bypass
• Threat Event Frequency: 0.15–0.35 per year
• Primary Loss: $500K–$25M
• Secondary Loss: $200K–$5M
• Annualized Loss Expectancy: $105K–$2.5M per deployment-year

Finding 4: JWT Validation Weaknesses Allowing Algorithm Confusion

Technical Description

Ditto’s JWT authentication supports multiple signing algorithms (RS256, ES256, HS256). The review identified that the JWT validation logic does not enforce the expected algorithm, allowing an “algorithm confusion” attack where an attacker who knows the public key (widely available from the OIDC provider’s .well-known/jwks.json endpoint) can sign a token using HS256 with the public key as the HMAC secret. If the Ditto validation code accepts the algorithm specified in the JWT header rather than enforcing the expected algorithm, this bypasses the RSA signature verification entirely.

MITRE ATT&CK Mapping: T1550.002 — Use Alternate Authentication Material: Pass the Token; T1556.001 — Modify Authentication Process

Underwriting Impact

Algorithm confusion attacks on JWT validation are well-documented but remain common due to the complexity of correctly implementing JWT validation. A successful attack allows any party with knowledge of the public key (which is, by definition, public) to forge valid JWT tokens. In Ditto’s case, a forged JWT with algorithm confusion grants access to all digital twin operations that the forged token claims to authorize.

• Loss Frequency (FAIR LEF): 0.02–0.08 per year (requires specific JWT library configuration)
• Loss Magnitude (FAIR LM): $2M–$100M (full digital twin access through forged tokens)
• Premium Loading: +5-15% with mandatory JWT algorithm enforcement verification

Ask the Insured

1. Does your Ditto JWT validation enforce the expected signing algorithm (RS256 or ES256) and reject HS256 tokens?
2. Have you tested your Ditto authentication against the known algorithm confusion attack pattern?
3. Do you use a dedicated JWT validation library that enforces algorithm allowlists?

FAIR Quantification

• Vulnerability: JWT algorithm confusion
• Threat Event Frequency: 0.03–0.10 per year
• Primary Loss: $2M–$100M
• Secondary Loss: $1M–$20M
• Annualized Loss Expectancy: $90K–$6M per deployment-year

Finding 5: Information Disclosure in DevOps API Error Responses

Technical Description

Eclipse Ditto’s DevOps API provides administrative operations including policy import management, connection configuration, and cluster status. The review found that the DevOps API error responses include detailed stack traces, internal service names, and configuration values that can be used for reconnaissance. While the DevOps API requires separate authentication (DevOps credentials), the error response patterns differ between valid and invalid credentials, enabling credential enumeration. Additionally, the error responses expose the Ditto version and internal service topology.

MITRE ATT&CK Mapping: T1087 — Account Discovery; T1592.002 — Gather Victim Host Information: Software

Underwriting Impact

Information disclosure from the DevOps API is primarily an enabler for other attack paths. The credential enumeration capability reduces the effective strength of DevOps credentials. The version and topology disclosure enables targeted exploitation of known Ditto vulnerabilities. For insurance, this finding amplifies the probability of all other attack paths succeeding.

• Loss Frequency (FAIR LEF): Amplifier — increases probability of targeted attacks by 20-35%
• Loss Magnitude (FAIR LM): $100K–$2M direct (credential compromise of DevOps API)
• Premium Loading: +3-5% as control deficit multiplier

Ask the Insured

1. Is the DevOps API restricted to loopback-only access or a management network?
2. Do you suppress detailed error messages in production, returning only generic error codes?
3. Have you implemented rate limiting on DevOps API authentication attempts?
4. Do you rotate DevOps credentials on a regular schedule?

FAIR Quantification

• Vulnerability: Information disclosure enabling subsequent attacks
• Threat Event Frequency: 0.25–0.50 per year
• Primary Loss: $100K–$2M
• Secondary Loss: $50K–$500K
• Amplifier Effect: 1.2–1.35x on all other Ditto attack path probabilities

Sector Impact Analysis

Manufacturing: Primary exposure. Eclipse Ditto is designed for IoT digital twins in manufacturing — representing production equipment, environmental sensors, and quality control systems. A Ditto compromise in manufacturing can cause physical equipment damage, production shutdowns, and safety incidents. Under NIS2, manufacturing is an essential entity.

Energy & Utilities: High exposure. Smart grid operators use Ditto for meter and sensor digital twins. A state manipulation attack on grid sensors could cause grid instability or cascade failures.

Smart Cities & Transportation: Emerging exposure. Smart city platforms are adopting Ditto for traffic management, waste management, and environmental monitoring digital twins. A compromise could disrupt public services.

Healthcare: Emerging exposure. Hospital IoT platforms are beginning to use Ditto for medical device digital twins. A compromise could affect device calibration and safety monitoring.

Agriculture: Emerging exposure. Precision agriculture uses Ditto for farm equipment and environmental monitoring. Compromise could affect crop management and food safety.

Regulatory Mapping

NIS2 (Directive 2022/2555):

• Article 21(2)(a): Risk analysis — Ditto as critical IoT middleware requires specific risk assessment
• Article 21(2)(c): Access control — authentication bypass and policy injection findings directly violate access control requirements
• Article 21(2)(d): Incident handling — digital twin manipulation qualifies as a significant incident
• Article 21(2)(g): Cyber threat intelligence — the attack patterns identified must inform threat monitoring

IEC 62443 (Industrial Cybersecurity):

• SR 1.1: Human user identification — authentication bypass findings violate this requirement
• SR 2.1: Authorization enforcement — policy injection findings violate authorization enforcement
• SR 4.1: Information confidentiality — WebSocket bypass enables unauthorized data access
• SR 6.1: Audit log accessibility — information disclosure findings undermine audit integrity

Machinery Directive 2006/42/EC:

• Article 1(2): Safety components — digital twin manipulation affecting safety interlocks may invoke product liability

EU AI Act (Regulation 2024/1689): Where Ditto digital twins are used as part of AI system sensing/control loops, the AI Act’s safety requirements may apply to Ditto security.

Remediation Status

1. Authentication Bypass: Eclipse Ditto 3.6+ provides configurable authentication enforcement, but default Docker Compose does not enforce it. Status: Framework provides enforcement; deployment-level configuration required.

2. Policy Injection: Ditto 3.8+ includes documentation warning about import privilege escalation. Status: Documented risk; no automatic enforcement. Requires policy architecture review.

3. WebSocket Authentication Bypass: Ditto supports session timeout configuration and devops channel restriction. Status: Available but not default. Requires explicit configuration.

4. JWT Algorithm Confusion: Ditto’s JWT validation depends on the underlying Java JWT library. Status: Library-dependent; explicit algorithm enforcement recommended.

5. DevOps API Information Disclosure: Error response customization available. Status: Configurable; production hardening guide recommends suppression.

How Resiliently Can Help

Domain Exposure Scanner: Detect exposed Ditto API endpoints and DevOps channels in your insured’s infrastructure. Map the digital twin dependency chain from Ditto to physical devices to understand the physical blast radius of a compromise.

Cyber Risk Calculator: Quantify the impact of a Ditto compromise across both digital and physical dimensions. Input the type and criticality of digital twins, the physical systems they control, and regulatory obligations to generate loss estimates that bridge cyber and physical risk.

AI-SBOM Scanner: Verify that your insured’s Ditto deployment matches their security declarations. Compare self-declared authentication enforcement, policy controls, and WebSocket security against OpenHack-verified findings. Produce an adjusted risk score that reflects the gap between the insured’s security claims and the actual configuration.

---

This review was conducted using the OpenHack scenario-based whitebox security review methodology. Findings were independently triaged before publication. Eclipse Ditto follows the Eclipse Foundation security process via security@eclipse.org. The Ditto project was notified through their security disclosure process prior to publication.