The Login Page That Logged Me In Without Logging In

Session-based authentication bypass allowing unauthorized access to protected medical records without valid credentials.

The Login Panel

During routine reconnaissance, I came across a login panel belonging to a large hospital network. The kind of organisation that runs multiple hospitals, employs thousands of staff, and handles millions of patient records.

There was no signup or registration functionality, which usually means this is an internal portal for staff, doctors, or administrators.

I ran through the usual checklist:

• SQL injection
• Common credentials
• Credential fuzzing
• Guessing patterns

Nothing landed. Most researchers move on here. I kept going — because login pages always have JavaScript, and JavaScript always has endpoints.

The Endpoint Hidden in Plain Sight

While reviewing the JS files, one endpoint caught my attention:

/api/patient/records

Patient prescriptions. Medical records. Behind a login that wasn't working.

But while testing the login earlier, I noticed something unusual — even when I submitted wrong credentials, the server was still issuing valid session cookies.

Session behavior is everything.

One Request. Full Access.

So I tried something simple:

1. Submit wrong credentials
2. Capture the session cookie from the failed response
3. Navigate directly to the endpoint

The dashboard loaded.

No valid credentials. No authentication. Just a session cookie created after a failed login.

What Was Inside

Inside that section, there was a search functionality where you could search patients using filters like:

• Medication
• Diagnosis
• Procedure
• Other medical filters

So I queried some data.

And the results loaded.

Real names. Real diagnoses. Real prescriptions. Real procedures. Personally identifiable health information — completely accessible without a valid login.

The Root Cause

The authentication logic was fundamentally broken. The server was asking the wrong question.

What it was checking: Does this request have a session?

What it should have been checking: Is this session associated with a successfully authenticated user?

The sequence looked something like this:

1. User submits login form
2. Server creates session ← session exists here
3. Server validates credentials
4. Credentials fail
5. Login rejected
6. Session remains valid ← this is the problem
7. Backend endpoints check session existence only
8. Access granted

One small logic mistake. Millions of patient records exposed.

No SQL injection. No zero-day. No advanced tooling. Just broken authentication logic sitting behind a login page.

Responsible Disclosure

When you find real patient records, testing stops immediately.

I documented everything — login behavior, session creation on failed auth, the accessible endpoint, dashboard access, and redacted samples of what was exposed — then reported to the organisation.

They responded professionally. The issue was fixed. A bounty was paid. The panel was moved behind a VPN.

This is how responsible disclosure should work.

Lessons for Engineers

If you are building applications that handle sensitive data — especially in healthcare:

1. Never issue a valid session before authentication is complete
2. Validate authentication state, not just session existence
3. Internal portals should never be directly internet-facing
4. Healthcare data requires the strictest access controls
5. Test authentication logic explicitly — it breaks in non-obvious ways
6. Run regular penetration tests on internal tooling, not just public surfaces

Most major breaches are not caused by sophisticated attackers. They are caused by simple logic mistakes that nobody thought to test.

Lessons for Researchers

• Login panels are always worth digging into
• JavaScript files consistently reveal hidden endpoints
• Always observe session behavior on failed authentication — not just successful flows
• Broken auth does not always look like broken auth
• When you find sensitive data, stop and report — reputation matters more than any single finding

Final Thoughts

This vulnerability required no exploit. No tool. No technique beyond basic curiosity and careful observation.

It only required:

• Noticing that a failed login still returned a cookie
• Finding one endpoint in a JS file
• Making one direct request

Sometimes the most serious security issues are the simplest ones — a small logic mistake, sitting quietly behind a login page, protecting millions of records. Until someone notices.