Broken Access Control & Authentication Misconfiguration Led to Internal Employee Account Takeover…

Intro

During one of my regular reconnaissance processes against a large enterprise's public attack surface, I came across a development subdomain that initially looked completely unremarkable. Visiting its root path returned nothing more than a generic Cannot GET / response.

At first glance, there didn't seem to be much worth investigating. However, a Cannot GET / response doesn't necessarily mean an application isn't there—it usually just means that no route is mapped to the root path. This is fairly common in modern web applications, particularly those built with frameworks like Express.js, where functionality is often exposed through specific routes rather than the root endpoint itself.

Instead of dismissing the subdomain, I continued exploring it to see whether any accessible routes existed.

For the purpose of this write-up, I'll refer to the target as:

https://dev.[REDACTED].[REDACTED].net

Since this issue was reported through a private bug bounty program and has already been remediated, all company names, domains, employee information, and other identifying details have been anonymized in accordance with responsible disclosure practices.

Discovery

The subdomain caught my attention enough that I decided to explore its exposed endpoints instead of dismissing it after receiving the generic Cannot GET / response.

There are many different ways to discover accessible endpoints during reconnaissance, ranging from content discovery and historical sources to search engine indexing. For this assessment, I decided to begin with Google dorking to see whether any endpoints associated with the subdomain had already been indexed.

While reviewing the search results, one indexed endpoint immediately caught my attention:

/garage/experience/

At first glance, the endpoint didn't appear to be anything unusual. It simply looked like an internal application endpoint that had been indexed by search engines. Since it was publicly reachable, I decided to visit it directly to understand what it actually exposed.

The Bug

I navigated to:

https://dev.[REDACTED].[REDACTED].net/garage/experience/

Instead of being redirected to an identity provider, presented with a login page, or receiving an authorization error, the application loaded a fully functional internal project management dashboard.

What immediately stood out was that I was already authenticated. I hadn't provided any credentials, completed any authentication flow, or interacted with the application in any way beyond requesting the endpoint.

The session was associated with a privileged internal employee account holding administrative roles within the application, authenticated under the email address employee@cn.corp.com (redacted).

Role: Squad Leader / Garage Leader

From that single unauthenticated request, I had complete access to the application's primary modules, including:

• Project Management

• AI Insights
• Change Management
• Business Opportunities
• Workspaces

These weren't static pages or limited previews. Every module was fully interactive, allowing the authenticated account to browse projects, manage workspaces, and perform administrative actions throughout the application.

Escalating the Impact

After confirming that I had administrative access, I continued validating the impact in a controlled manner to understand the actual security implications of the issue without performing unnecessary modifications to production data.

It quickly became clear that the authenticated account wasn't operating under a restricted or read-only role. The available functionality included administrative capabilities across multiple areas of the application, including project administration, workspace management, and user management.

The application also exposed numerous internal employee accounts and organizational information, demonstrating that this wasn't an isolated access control issue affecting a single page — it was unrestricted access to an internal enterprise platform operating with privileged permissions.

At that point, I had gathered sufficient evidence to demonstrate the severity of the vulnerability, so I documented the findings, captured the necessary proof of concept, and submitted the report through the bug bounty program.

Root Cause

This is the part I want to be the most precise and transparent about. At the time of writing this report, I no longer have access to the original requests from my Burp Suite history, as this write-up was prepared several months after I had already submitted the vulnerability report. As a result, I can't reference the original request flow with complete certainty.

What is observable and fully reproducible, however, is the application's behavior.

Accessing the root endpoint (/) returned a generic framework-level Cannot GET / response, indicating that the application exposed functionality through explicitly defined routes rather than the root path.

However, directly requesting /garage/experience/ resulted in immediate access to a fully authenticated administrative session. The application neither redirected me to an identity provider nor required any authentication, token exchange, or credentials. Instead, it treated the request as already authenticated and associated it with a privileged internal employee account.

From an external perspective, this behavior is consistent with a combination of Broken Access Control and an Authentication Misconfiguration. The authentication and authorization mechanisms that should have protected the application either were not enforced for this route or otherwise failed to treat the request as unauthenticated.

Without access to the application's source code, deployment pipeline, or server-side logs, I can't conclusively determine the exact implementation flaw responsible for this behavior. Possible explanations include:

• A missing authentication middleware protecting the affected route.
• A session-handling flaw that incorrectly associated unauthenticated requests with an existing privileged session or authentication context.
• A testing or deployment oversight, where code or configuration intended for an internal testing environment was inadvertently deployed to the publicly accessible instance. For example, a development-only authentication mechanism or preconfigured authenticated session may have remained enabled, causing requests to be automatically associated with an internal employee account instead of requiring a normal authentication flow.

This vulnerability was reported through a private bug bounty program at the time of discovery, was triaged and accepted as Critical severity, and has since been resolved. All company-identifying information has been redacted in accordance with responsible disclosure practices.