Summary
DHIS2 contains an unsafe Java deserialization vulnerability that can allow attackers to execute arbitrary code remotely. The issue becomes risky when attacker-controlled serialized data reaches a deserialization path without adequate type restrictions or integrity checks.
Affected context
The vulnerability affects DHIS2 deployments using impacted 2.42.x and 2.43.x releases, before the corresponding patched maintenance versions. It occurs in functionality that processes serialized Java objects across a remotely reachable application interface, where untrusted or insufficiently constrained data may be deserialized.
Exploit preconditions
- Attack surface: A remotely reachable DHIS2 application or service endpoint that processes serialized data
- Required access: The ability to send or cause delivery of attacker-controlled serialized input; the exact access level may depend on deployment configuration
- Trigger point: Java deserialization of the received or stored object data
- Why exploitation is possible: Deserialization may reconstruct attacker-influenced object graphs without sufficiently restricting allowable classes or validating object integrity
Why this happens
The underlying flaw is unsafe Java object deserialization, which maps to CWE-502: Deserialization of Untrusted Data. The application treats serialized input as sufficiently trustworthy and reconstructs objects before establishing that the data and its referenced classes are safe. In Java, this insecure pattern can allow specially crafted object graphs to trigger unintended behavior during or after deserialization, including execution of attacker-controlled code.
Potential impact
- An attacker may execute arbitrary code within the DHIS2 process context
- The application and its underlying host could be compromised
- Sensitive health and administrative data could be accessed or altered
- Attackers could use the compromised service to move laterally within connected environments
- Availability could be disrupted through unauthorized process or resource activity
General mitigation guidance
Mitigation generally focuses on eliminating unsafe native deserialization and reducing trust in serialized input.
Common defensive patterns include:
- Prefer data formats and parsers that do not support arbitrary object construction
- Apply strict allowlists for permitted classes when object deserialization is unavoidable
- Validate message structure, type, integrity, and authorization before processing
- Restrict exposure of deserialization endpoints to trusted networks and necessary clients
- Run the application with least-privilege service accounts and isolated runtime permissions
- Apply consistent security controls across all supported deployment interfaces and integration paths
How teams detect issues like this
Organizations can look for unsafe deserialization through:
- Static analysis rules identifying Java native deserialization APIs, object input streams, and broad class resolution
- Code review checks for deserialization of request, queue, cache, or database content without integrity validation
- Dependency and framework analysis for endpoints that accept serialized Java objects
- Runtime monitoring for unusual serialized-object traffic, unexpected process creation, or abnormal child-process activity
- Policy enforcement that prohibits native deserialization of untrusted data unless approved allowlists and safeguards are present
Automated code review and software composition analysis tools may help identify relevant APIs and vulnerable processing paths.
