Weak Middleware + SaaS Demo Page = Unauthenticated ATO

Recently, during a pentest engagement for a messaging chatbox solution (website integrated), I found a simple broken access control vulnerability inside a middleware that was required to be developped by the customers for proper integration.

So the vulnerability itself is outside the scope of this product, however we all know the use of middlewares is always a great idea.. cough, cough.. CVE-2025-29927..

Obviously, due to NDA, this product shall remain nameless.

The setup

To start let’s showcase a simple diagram to understand the overall workflow.

This diagram includes 3 simple important parts:

• redacted.com Internally developped app
• redacted.com/api/* Internally developped middleware
• saas.com Messenging product SaaS

Sessions Workflow + JWT

Let’s see how the users are actually accessing their chatbox and this was pretty simple:

1. The middelware generates a JWT token for the user
2. An API key is set by the SaaS, and according the docs this API Key is supposed to be public (found in JS files)
3. API Key + JWT sent to SaaS to get a session ID
4. Session ID is set in the cookie to retrieve and access chatbox conversations

From this we can conclude a few things:

• If an attacker has access to this JWT token, then they can easily create a session ID to access conversations
• If session ID is leaked somehow, attacker can simply add this session to their cookie, however they do need to be authenticated.
• The connection to the SaaS might reveal something ?

Middleware Broken Access Control to ATO

During testing, I found out that the JWT token generated via a simple POST Request to something like /api/GenerateJWT didn’t require any authentication and we can generate infinite JWTs with custom usernames, emails etc…

So, we can simply just request a session ID with this JWT + API Key and set it in our cookie and we have access to all conversations and files of any other user etc..

But this DOES require the attacker to be logged in, so I started looking somewhere else to escalate this vulnerability..

SaaS Demo leading to unauthenticated ATO

So it was clear, the vulnerability exists and we can get a valid session ID and access any conversation if we know the username of the victim, however this was restricted, we can only do this when logged in and from the domains redacted.com and saas.com

So, I checked the docs, and turns out, this product’s SaaS provided an unauthenticated testing endpoint such as saas.com/testing/demo.html which was totally static, made for developpers to quickly test the integration’s keys (api key, jwt, username etc..)

So the escalation now looks pretty clear

1. Generate a JWT with a valid username
2. Inject JWT + API key in the demo page
3. Access to all conversations and files

Now we have escalated a simple authenticated ATO to full unauthenticated ATO

Conclusion

Although this vulnerability does not affect the actual product itself, but we can see from this finding that despite how secure a product can be, you can still allow for a bigger attack surface when you let external parties, such as customers, develop a big part of it’s integration such as middlewares.

From this finding we can learn 2 things:

• Never give the responsiblity to secure your product to external parties.
• Always dig deep in documentation and external assets to escalate findings.

Hope you enjoyed this simple small blog post, hopefully making many more in the future 👋