How Fuzzing a Government Website Led Me to Executives' Contact Details

Introduction

Sometimes a vulnerability doesn't start with an obvious critical endpoint.

It starts with a directory.

While assessing a government event website, I began with basic endpoint discovery and fuzzing. During the process, I came across an administrative area that exposed JavaScript files.

One of those files revealed a backend endpoint responsible for retrieving attendee data.

The interesting part?

The endpoint didn't require authentication.

It returned attendee records containing information such as:

• Full names
• Organizations
• Job titles
• Email addresses
• Phone numbers
• Delegate/attendance status
• Registration timestamps

This included information belonging to senior delegates and executives.

What started as simple endpoint discovery eventually led to an unauthenticated PII disclosure.

1. Starting With Endpoint Discovery

The first step was straightforward: enumerate the application's accessible endpoints.

I fuzzed the target for interesting directories and files:

ffuf -u https://[REDACTED-TARGET]/FUZZ \
     -w [REDACTED-WORDLIST] \
     -mc 200,301,302

During the enumeration, two interesting paths stood out:

/kiosk/
/admin/

Neither path immediately looked like a conventional public-facing feature.

That made them worth investigating further.

2. Discovering app.js

Further enumeration of the discovered directories revealed JavaScript resources.

One of the interesting files was:

/kiosk/app.js

and the application also exposed resources under the administrative area.

I opened the JavaScript file and started reviewing it for references to backend APIs and data-fetching functions.

This is something I generally like doing after discovering JavaScript files during a web assessment.

Frontend JavaScript often contains clues about:

• API endpoints
• Internal routes
• Backend functionality
• Parameters
• Authentication assumptions
• Data-fetching mechanisms

In this case, the JavaScript revealed something particularly interesting.

3. Finding fetch_data.php

While reviewing app.js, I found a reference to:

fetch_data.php

That immediately became the next endpoint to investigate.

The application appeared to be using this PHP endpoint to retrieve data for the frontend.

I navigated to the endpoint:

https://[REDACTED-TARGET]/[REDACTED-PATH]/fetch_data.php

There was no authentication challenge.

Instead, the endpoint returned a JSON response.

4. The JSON Response

The response contained an array of attendee records.

The structure included fields similar to:

{
  "name": "[REDACTED]",
  "organization": "[REDACTED]",
  "designation": "[REDACTED]",
  "email": "[REDACTED]",
  "phone": "[REDACTED]",
  "status": "[REDACTED]",
  "registered_at": "[REDACTED]"
}

The important part wasn't simply that the endpoint returned JSON.

It was what the JSON contained.

The records exposed personally identifiable information belonging to event participants.

The dataset included professional information such as organization and designation alongside direct contact information such as email addresses and phone numbers.

5. The Interesting Part: Senior Delegates

While examining the returned records, I noticed that the dataset wasn't limited to generic attendee information.

Some records belonged to high-profile delegates and senior professionals, including people with executive-level designations.

That meant the exposure could potentially provide an attacker with a ready-made list of targets for highly convincing social-engineering attacks.

For example, an attacker could potentially combine:

Name
+
Organization
+
Job Title
+
Official-looking Event Context
+
Email / Phone Number

to construct much more convincing phishing or impersonation attempts.

The vulnerability therefore wasn't simply:

It was:

6. No Authentication Required

The core security issue was the lack of access control.

The backend endpoint was accessible without authentication and returned data that should have been restricted to authorized users or the application's internal functionality.

The expected flow should have looked something like:

Client
  ↓
Authentication
  ↓
Authorization
  ↓
Backend endpoint
  ↓
Permitted attendee data

Instead, the actual flow was effectively:

Anyone on the Internet
        ↓
fetch_data.php
        ↓
Attendee JSON
        ↓
PII

There was no meaningful authorization barrier between an unauthenticated visitor and the underlying attendee dataset.

7. What Made This More Serious?

The vulnerability combined several factors.

That combination significantly increases the value of the exposed information to an attacker.

8. Attack Chain

The discovery can be summarized as:

Public Government Website
          ↓
      Endpoint Fuzzing
          ↓
      /kiosk/ & /admin/
          ↓
        app.js
          ↓
    fetch_data.php
          ↓
  No Authentication
          ↓
     JSON Response
          ↓
   Attendee PII
          ↓
Potential Phishing / Social Engineering

The initial fuzzing itself wasn't the vulnerability.

It simply helped uncover functionality that was not appropriately protected.

The actual vulnerability was the unauthenticated exposure of sensitive attendee information.

9. Business Impact

The exposed information could have several security and privacy implications.

• Privacy exposure — Unauthorized users could access attendee PII without the participants' authorization.
• Targeted phishing — An attacker could use the combination of names, organizations, designations, and contact information to craft highly targeted phishing messages.
• Social engineering — Knowing someone's professional role and organization makes impersonation attempts considerably more convincing.
• Executive targeting — Information belonging to senior delegates and executives could make the dataset particularly valuable for targeted attacks.
• Regulatory concerns — Depending on the nature of the information and applicable requirements, unauthorized exposure of personal information could create privacy and compliance concerns.

The original assessment specifically identified the risk of targeted phishing, social engineering, and executive impersonation arising from the exposed contact information.

10. Remediation

The primary fix is to enforce proper authentication and authorization on the backend endpoint.

The endpoint should not be publicly accessible simply because it is consumed by frontend JavaScript.

A proper access-control model should ensure that:

Unauthenticated user
        ↓
       DENY

while authorized application users receive only the information they are permitted to access.

The backend should also avoid returning unnecessary PII.

For example, if a frontend only requires:

{
  "name": "[REDACTED]",
  "organization": "[REDACTED]"
}

there is no reason for the API to return:

{
  "email": "[REDACTED]",
  "phone": "[REDACTED]",
  "registration_timestamp": "[REDACTED]"
}

This follows the principle of data minimization.

The endpoint should also be tested independently of the frontend. Hiding a link or removing a UI element does not secure an API if the backend endpoint remains directly accessible.

Conclusion

This assessment started with something fairly routine: fuzzing a public-facing website for interesting endpoints.

That led to /kiosk/ and /admin/.

Those directories exposed JavaScript.

The JavaScript revealed a backend data-fetching endpoint.

And that endpoint exposed attendee information without authentication.

The final chain looked like this:

Fuzzing
  ↓
Hidden Endpoint
  ↓
JavaScript Discovery
  ↓
Backend API Discovery
  ↓
Missing Authentication
  ↓
Attendee PII
  ↓
Potential Targeted Social Engineering

What made the finding particularly interesting was the type of information exposed.

It wasn't just usernames or generic application data.

It included real-world identities, organizations, job titles, email addresses, phone numbers, and attendance information — data that could potentially be used to target specific individuals.

A backend endpoint should never rely on the assumption that users will only reach it through the intended frontend.

If an API returns sensitive information, the API itself needs to enforce authentication, authorization, and data minimization.