Potential User Enumeration via Organisation Unit API (DHIS2 2.42.4)

Support - Assistance technique
, ,
1

Dear DHIS2 Community,

I would like to report and seek clarification regarding a potential information disclosure issue observed in DHIS2 version 2.42.4.

Summary

When querying an Organisation Unit (OU) through the Web API, the response includes a full list of users assigned to that OU — even when the authenticated user has only minimal permissions (Dashboard view access only).

Test Environment

  • DHIS2 Version: 2.42.4
  • Deployment: Production-style setup behind GCP HTTPS Load Balancer
  • Single Org Unit (Level 1)
  • Test User Role: Dashboard view only (no user management/superuser permissions)
  • Test User: “Pankaj”

Direct access to /api/users correctly returns 403 Forbidden, confirming that user metadata permissions are restricted.

Reproduction

Authenticated as a normal user with only dashboard view rights:

GET https://domain-name/api/organisationUnits/t8f5HkN4BPS

The response includes the full "users" array:

"users": [
  {
    "id": "sSqucREb312",
    "name": "Pankaj Kumar",
    "username": "Pankaj"
  },
  {
    "id": "y9xtGXCJbL0",
    "name": "Pen Test",
    "username": "Pentest"
  },
  {
    "id": "rGMHVd7SMTD",
    "name": "Test User",
    "username": "test"
  },
  {
    "id": "M5zQapPyTZI",
    "name": "admin admin",
    "username": "admin"
  }
]

Security Concern

This allows:

  • Enumeration of valid usernames
  • Identification of administrative accounts
  • Harvesting of internal UIDs
  • Target selection for brute-force or credential stuffing attacks

While /api/users is properly protected (403), the nested users property within Organisation Unit metadata bypasses that restriction.

Risk Amplification

The impact becomes significant when combined with:

  • Weak password policies
  • Lack of login rate limiting
  • Disabled account lockout
  • Automated credential stuffing attempts

An attacker with basic read access to a top-level Organisation Unit can effectively enumerate all system users.

Key Observation

The test user does not have:

  • User read permissions
  • User management authorities
  • User group access

Yet assigned users are exposed through OU metadata.

Questions for the Community

  1. Is this exposure of the users array within Organisation Units intended behavior?
  2. Is there a recommended configuration to suppress user details from OU metadata?
  3. Would it be appropriate to restrict nested user information unless explicit user-read authority exists?
  4. Is there an official hardening guideline addressing this scenario?
1 Like
2

Hi @pankajky

Thank you for reporting this issue. I’ve triaged this to @dhis2-security team!