Private keys and biometric data on a public eKYC server

The server

In early May 2025, I found an eKYC service exposed on port 5001. It belonged to an Indian identity verification provider and returned a raw directory listing with no authentication in front of it.

This was not an empty deployment folder. The listing exposed the layout of the backend and several files that should never have been reachable from the public internet.

What was visible

The filenames fell into three groups.

Key material and configuration

• private.key
• TLS certificate files
• configuration files containing internal paths and likely secret-bearing settings

Identity and biometric data

• aadharimages
• faceimages
• videoekyc.db

Backend source

• ekycserver.py
• ocrprocessor.py
• supporting Python modules and internal scripts

The file tree connected the public service to its data storage, certificate material, and application code in one place. The risk was apparent from the listing alone.

Impact

The exposed database and image directories appeared to relate to real identity verification sessions. If those files were readable, they could contain Aadhaar-related images, faces, and other personally identifiable information.

The key material created a separate problem. If private.key was active and matched a deployed certificate, its exposure could allow service impersonation in some configurations. The source code would also make it easier to map the provider's eKYC flow, OCR handling, and backend assumptions.

The combination mattered more than any single filename. One public directory appeared to place identity data, application logic, and cryptographic material within reach of an unauthenticated visitor.

Disclosure timeline

• 2 May: sent the first report to the company's available support and security addresses
• 4 May: a staff member acknowledged the report and escalated it internally
• 6 May: checked again and found the server offline
• 7 May: received a formal reply from a security manager confirming an investigation
• 12 to 16 May: followed up about remediation and acknowledgment
• 19 May: received confirmation that the issue was resolved, along with an appreciation letter

There was no public bug bounty program. The company still responded, removed the exposed service, and provided written acknowledgment under my handle.

What should change

Directory indexing should be disabled, but that is only the first step. A service handling identity data needs stronger separation between public application code, stored customer material, and private keys.

The practical fixes are straightforward:

• keep biometric files outside any web-accessible directory
• rotate any exposed certificate or application keys
• move secrets into a managed secret store
• restrict non-public services at the network layer
• separate development, staging, and production data
• publish a clear security contact for future reports

The server went offline quickly after the report. Given the kind of data involved, that was the right first move.