Authentication Bypass Successfully Impersonated 95 Users Without Passwords or MFA

A critical authentication bypass that enabled the impersonation of 95 employee accounts, including privileged users, without passwords, multi-factor authentication (MFA), or valid Microsoft Entra ID tokens.

The issue stemmed from two flaws in the application’s custom session-cookie implementation: a predictable hard-coded signing secret and the use of public database identifiers as authenticated session payloads.

Although the application relied on Azure Entra ID single sign-on (SSO), its application-side session mechanism created a separate trust boundary that undermined the protections delivered by the identity provider.

The platform used a modern stack comprising Node.js/Express, Next.js, Prisma/PostgreSQL, MSAL-based Entra ID authentication, and express-openapi-validator.

It also exposed Swagger documentation at /api-docs/, revealing a 251-route API surface.

Entra ID access tokens used RS256 signatures, while parameterized database queries and request-schema validation reduced exposure to common injection and input-validation flaws.

However, authenticated requests also depended on a second cookie named session_secret_example.

Rather than using a random server-side session identifier, the cookie contained a signed representation of the user’s CUID, or database identifier.

That value was returned by endpoints such as /api/v1/auth/me, user-directory APIs, and object metadata fields including createdBy and updatedBy.

The signed-cookie structure followed the familiar format s:<payload>.<signature>, where the signature was derived from an HMAC-SHA256 operation.

In a secure deployment, the signing key must be a high-entropy secret stored outside the source code or deployment configuration, while the payload should reference an unpredictable session ID. Neither condition was met.

Resecurity identified, the weakness during authorized testing of a YMS platform used to coordinate supply-chain and yard operations.

Passwordless Impersonation

The review found that the HMAC secret was the literal string session_secret_example identical to the cookie’s name.

Researchers recovered it through an offline candidate search of roughly 110 likely values using a known cookie payload and signature pair.

Once the key was identified, any exposed user CUID could be transformed into a valid signed session value.

The application verified that a signature was syntactically correct, but did not independently confirm that the signed value was tied to a legitimate server-side session or a recent Entra ID authentication event.

As a result, a correctly signed public user ID was treated as proof of identity.

During testing, researchers successfully forged sessions for 95 of 241 tested user IDs. The affected accounts included operational users, technicians, yard personnel, and administrators.

The forged cookies granted read/write access aligned with each victim’s role, and testing confirmed that an administrator-level forged session could perform a state-changing API request.

The assessment also found that /api/v1/auth/me exposed the authenticated user’s Entra refresh token, increasing the potential impact of a successful compromise.

The findings demonstrate why MFA and federated identity protections cannot compensate for weaknesses in downstream application session handling.

Entra ID authenticated users correctly, but the YMS application accepted a separately implemented cookie as authoritative authentication material.

In practical terms, the custom session layer bypassed upstream SSO, MFA, role-based access control, and password protections.

The issue maps conceptually to MITRE ATT&CK’s T1550.004: Use Alternate Authentication Material: Web Session Cookie, although this case involved cookie forgery rather than theft or replay.

MITRE notes that session cookies can allow adversaries to authenticate as users and bypass MFA because the session itself represents an already authenticated state.

Affected organizations should immediately rotate session-signing secrets, invalidate all active sessions and refresh tokens, remove refresh tokens from API responses, and investigate access logs for anomalous session use.

Defenders should also replace self-contained identity cookies with cryptographically random, server-side session identifiers, enforce short session lifetimes, bind sensitive actions to step-up authentication, and ensure that authorization decisions are backed by validated server-side session state.

The incident is a reminder that application teams must treat session architecture as part of the authentication perimeter. Strong SSO is only as effective as the application layer that consumes its output.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC