Summary
OpenRemote's KNX protocol handler may process an authenticated user's uploaded ETS project XML with parsers that allow external entity resolution. A regular realm user who can upload a crafted project may cause the server to read files accessible to the JVM process or make server-side requests.
OpenRemote's KNX protocol handler may process an authenticated user's uploaded ETS project XML with parsers that allow external entity resolution. A regular realm user who can upload a crafted project may cause the server to read files accessible to the JVM process or make server-side requests.
Affected context
The issue may occur in OpenRemote deployments that:
- Enable the KNX protocol handler and ETS project import functionality
- Allow authenticated realm users to upload ETS project ZIP archives
- Process the archive's
0.xmlfile through XML transformers or input factories - Use parser configurations that permit external entity resolution
The affected processing path is the KNX asset import method, while other protocol handlers may apply different parser protections.
The issue may occur in OpenRemote deployments that:
- Enable the KNX protocol handler and ETS project import functionality
- Allow authenticated realm users to upload ETS project ZIP archives
- Process the archive's
0.xmlfile through XML transformers or input factories - Use parser configurations that permit external entity resolution
The affected processing path is the KNX asset import method, while other protocol handlers may apply different parser protections.
Exploit preconditions
- Attack surface: Authenticated ETS project upload and KNX asset import
- Required access: A regular realm user account with permission to upload or import an ETS project
- Trigger point: Parsing of
0.xmlduringKNXProtocol.startAssetImport - Why exploitation is possible: XML parser and transformer configurations may resolve external entities supplied through attacker-controlled project content
- Attack surface: Authenticated ETS project upload and KNX asset import
- Required access: A regular realm user account with permission to upload or import an ETS project
- Trigger point: Parsing of
0.xmlduringKNXProtocol.startAssetImport - Why exploitation is possible: XML parser and transformer configurations may resolve external entities supplied through attacker-controlled project content
Why this happens
The underlying flaw is incomplete protection of XML processing components against external entity resolution. When untrusted XML is passed to a transformer or input factory without consistently disabling external entities, external DTDs, and related URI access, parser behavior can access resources beyond the uploaded document. This maps to CWE-611: Improper Restriction of XML External Entity Reference, commonly known as XML External Entity injection.
The underlying flaw is incomplete protection of XML processing components against external entity resolution. When untrusted XML is passed to a transformer or input factory without consistently disabling external entities, external DTDs, and related URI access, parser behavior can access resources beyond the uploaded document. This maps to CWE-611: Improper Restriction of XML External Entity Reference, commonly known as XML External Entity injection.
Potential impact
- An attacker may read local files accessible to the JVM process
- The server may make requests to internal or external network resources
- Cloud metadata or internal service information could be exposed
- Authentication material or application configuration may be disclosed
- The vulnerable service could be used as a pivot point for further attacks
- An attacker may read local files accessible to the JVM process
- The server may make requests to internal or external network resources
- Cloud metadata or internal service information could be exposed
- Authentication material or application configuration may be disclosed
- The vulnerable service could be used as a pivot point for further attacks
General mitigation guidance
Mitigation typically focuses on making XML parsing deny external resource access by default and applying those controls consistently across every parser and transformation layer.
Common defensive patterns include:
- Disable external general entities, external parameter entities, and external DTD loading
- Restrict document and stylesheet access to the minimum required local resources
- Prefer hardened, namespace-aware XML APIs with secure processing enabled
- Validate uploaded archive structure and XML content against an explicit schema
- Treat uploaded project files as untrusted regardless of the user's realm role
- Run the service with least-privilege filesystem and network permissions
- Isolate import processing from sensitive internal networks where practical
Mitigation typically focuses on making XML parsing deny external resource access by default and applying those controls consistently across every parser and transformation layer.
Common defensive patterns include:
- Disable external general entities, external parameter entities, and external DTD loading
- Restrict document and stylesheet access to the minimum required local resources
- Prefer hardened, namespace-aware XML APIs with secure processing enabled
- Validate uploaded archive structure and XML content against an explicit schema
- Treat uploaded project files as untrusted regardless of the user's realm role
- Run the service with least-privilege filesystem and network permissions
- Isolate import processing from sensitive internal networks where practical
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis rules identifying XML factories, transformers, and SAX-based parsers created without secure feature settings
- Code review checks for external entity, DTD, URI, and stylesheet access controls
- Tests that submit XML containing external entity references and verify that no local or network resource is accessed
- Dependency and policy scanning for parser configurations that permit external resolution
- Runtime monitoring of import processes making unexpected filesystem or outbound network requests
Automated code review and secure-configuration tooling can help identify inconsistent hardening across parallel protocol handlers.
Organizations can detect this class of issue through:
- Static analysis rules identifying XML factories, transformers, and SAX-based parsers created without secure feature settings
- Code review checks for external entity, DTD, URI, and stylesheet access controls
- Tests that submit XML containing external entity references and verify that no local or network resource is accessed
- Dependency and policy scanning for parser configurations that permit external resolution
- Runtime monitoring of import processes making unexpected filesystem or outbound network requests
Automated code review and secure-configuration tooling can help identify inconsistent hardening across parallel protocol handlers.
