From 401 to BAC: How a Refresh Broke Workspace Authorization

The Setup

I was participating in a public vulnerability disclosure program. I wanted to test a specific feature — workspace creation — but it was invite-only. The team said they'd get back to me "in a couple of days."

Normally, I'd wait. Maybe they'd accept. Maybe not.

But instead of waiting, I decided to poke around using some endpoint crawling techniques I'd recently learned.

The Discovery

I ran a crawler against the main domain (target.com) to map out old, potentially unlinked endpoints.

The output was mostly noise:

• Thousands of 404s
• Redirects to the homepage
• Normal assets (images, CSS, etc.)

But after manually filtering the noise, a few endpoints stood out:

target.com/workspace/{MyID}?pwd=

target.com/workspace/{MyID}?pwd=

({MyID} = workspace ID)

The pwd parameter caught my eye. That often signals a magic link or passwordless entry mechanism.

Navigating directly to the link returned what any unauthenticated visitor would expect:

HTTP 401 Unauthorized_ —_ You are not allowed to enter workspace X.

I almost moved on.

But I had a small hunch:

What happens if I just… refresh?

So I hit refresh.

Boom.

The 401 screen vanished. I was looking at the full, interactive dashboard of workspace X.

Once inside, the severity hit immediately. I had user-level privileges within that workspace, including:

1. Internal tools — Embedded apps used by the target team
2. Meeting links — Active video conference URLs
3. PII leakage — A directory listing with email addresses of all workspace members

No password. No brute force. Just a refresh.

Testing Other Workspaces

I grabbed other workspace IDs I had found earlier and tested them:

| MYIDLOL1 | 401 → Access granted | | MYIDLOL2 | 401 → Access granted | | MYIDLOL3 | 401 → Access granted | | … up to 12th ID | 401 → Access granted |

All of them. Every single one.

All the attacker needs is the workspace ID.

Root Cause (My Theory)

This is a classic Broken Access Control (BAC) vulnerability, but with a twist: state confusion on refresh.

My guess:

• First request → server checks auth → fails → returns 401
• Second (refresh) request → server reuses a partially initialized session or incorrectly assumes a prior check passed → grants access

The legacy ?pwd= parameter likely short-circuits normal auth flows when combined with certain browser behaviors (like If-Modified-Since or cached session hints).

Timeline

• Sept 2025 → Reported to the program
• 1 week after → Confirmed as valid ( & shortly marked as triaged & then resolved )

Key Takeaways

1. Never trust a 401 blindly. Just because you're denied the first time doesn't mean you'll be denied the second time.
2. Legacy parameters are gold. Parameters like ?pwd=, ?debug=, ?bypass= often survive modern auth refactors — and break things beautifully.
3. Refresh is a test case. Add "refresh after 401" to your manual testing checklist. You'd be surprised how many apps fail here.

Final Thoughts

This is my first public writeup. I hope it helps someone else look twice at a "dead end."

Happy hacking ;}