Responsible Disclosure:- Election Commission Nepal

Reported: Nov 14, 2025

Summary: During routine testing of the Election Commission's public APIs I discovered that certain API responses included verification codes and internal-only fields in the response body. In other words, values intended to be delivered through a secure channel (one-time verification codes) were being returned in JSON responses accessible without authentication. I reported the issue through the responsible disclosure contact and the fields were removed after coordination with the team.

Impact

Exposing verification codes or other authentication material in API responses increases the risk of automated account enumeration, replay, or abuse. While I did not observe any direct database access or sensitive PII leakage, the presence of authentication material in public responses is considered a high-risk configuration that should be corrected quickly.

What I observed (high level)

  • Some endpoints returned internal or verification values in their JSON responses that were not required by external clients.
  • Verification codes (one-time values) were present in the response payload rather than being delivered only via the intended out-of-band channel.
  • Behavior was reproducible across multiple endpoints and environments I could access.

Tools & scope

Tools used: Burp Suite (interception and inspection of HTTP traffic) and standard browser developer tools. I did not proceed beyond information gathering and validation, no database access or sensitive-data exfiltration was performed. The testing was limited to publicly-accessible endpoints and did not involve privileged access or exploitation of downstream systems.

Recommended remediation

  1. Remove any OTPs, verification codes, or internal-only fields from public API responses; these values should never be returned to unauthenticated callers.
  2. Validate verification codes server-side from a secure store; deliver codes only over the intended channel (SMS, email) and never echo them in responses.
  3. Introduce strict rate-limiting and brute-force protections on verification and authentication endpoints.
  4. Adopt API response schemas (OpenAPI/JSON Schema) that explicitly define public contract fields and prevent accidental exposure of internal attributes.
  5. Review logging and monitoring to ensure sensitive fields are redacted.

Timeline

  • Discovery: November 2025 — initial observation during API testing.
  • Report: Submitted a concise, non-sensitive disclosure with reproduction steps and recommended fixes.
  • Follow-up: The team acknowledged the report and applied fixes; I verified that the problematic fields were removed from the public responses.

Final notes

Responsible disclosure is about improving security — I aimed to provide a clear, actionable report and to avoid releasing sensitive reproduction details publicly. If you are part of a development team and want a template for redaction-safe reproduction steps or a checklist for API hardening, I can provide one.

If you'd like a redacted copy of the report or to discuss the findings privately,
contact me at

Back to Blog