Invisible logins: a 50,000-character string breaks Azure's audit trail
Imagine your security dashboard shows zero suspicious activity all week. Your logs are clean. Your SIEM is happy. Everything looks secure.
Then you find out someone logged in to your Azure environment 47 times. You have no record of any of it.
That's what happened to Azure Entra ID customers on March 19, 2026, when TrustedSec researcher Nyxgeek published the full story of four separate bypasses he'd found since 2023. Four different ways to authenticate against Azure Entra ID without leaving a trace in the sign-in logs — the audit trail every organization depends on.
The simplest bypass? Send a 50,000-character user-agent string. The authentication succeeds. The token is issued. But the logging pipeline crashes silently. You're logged in. The logs don't know it.
None of these received a CVE. Microsoft is their own CVE Numbering Authority.
Four bypasses, same blind spot
All four bypasses target the same authentication flow: OAuth2 Resource Owner Password Credentials (ROPC) via login.microsoftonline.com, hitting the Microsoft Graph API. This is a standard password-based auth flow that applications use to authenticate users programmatically.
The bypasses share a common mechanism. The authentication itself succeeds — credentials are validated, tokens are (sometimes) issued. But the system that logs the event fails silently. The login happens. The log entry doesn't.
Here's what Nyxgeek found, in chronological order.
GraphNinja (August 2023)
The first bypass. By specifying a foreign tenant ID as the authentication endpoint — a tenant the user doesn't belong to — the password validation still occurred against the correct tenant. The credentials were checked. The password was confirmed valid or invalid. But the sign-in log entry landed in the foreign tenant's logs, not the victim's.
No token was returned. But an attacker could validate passwords across an entire organization without a single entry appearing in that organization's logs. Password spraying, completely invisible.
Reported: August 2023. Fixed: May 2024. Nine months.
GraphGhost (December 2024)
The second bypass. This time, the trick was supplying an invalid Client ID in the OAuth request. The authentication flow proceeded far enough to validate the password, then failed on the bad Client ID. The result: a "failed" login event that gave no indication the password had actually been confirmed as correct.
An attacker watching the error responses could distinguish between "wrong password" and "right password, bad client ID." The logs showed a failure, not a success. No token returned, but password validation achieved — invisibly.
Reported: December 2024. Fixed: April 2025. Four months.
GraphGoblin (September 2025)
This is the one that matters most. Nyxgeek discovered that by repeating a valid OAuth scope parameter thousands of times — for example, the string openid repeated 10,000+ times in the scope field — the authentication would succeed and return a fully functional bearer token, but the log entry would never be written.
curl -X POST "https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token" \
--data-urlencode "client_id=$CLIENT_ID" \
--data-urlencode "username=$USERNAME" \
--data-urlencode "password=$PASSWORD" \
--data-urlencode "grant_type=password" \
--data-urlencode "scope=$(for num in {1..10000}; do echo -n 'openid '; done)"
That's it. A bash one-liner generates the payload. The scope field balloons to tens of thousands of characters. The authentication service processes it, validates credentials, issues a token. But when the logging system tries to INSERT the event into its database, the oversized scope value likely exceeds a column length limit, and the entire INSERT fails silently. Token issued. Log entry dropped.
A fully authenticated session, invisible to every SIEM, every security team, every detection rule built on sign-in logs.
Discovered: September 20, 2025. Reported: September 26, 2025. Fixed: November 21, 2025. Microsoft rated it "Moderate." No CVE. No bounty.
The fourth bypass (September 2025)
Eight days after finding GraphGoblin, Nyxgeek found a fourth bypass using the same principle: a 50,000-character user-agent string. Same SQL column overflow. Same silent logging failure. Same result — a valid token with no log entry.
Microsoft fixed this one on October 8, 2025, before Nyxgeek even submitted the report. They'd likely started looking at column length issues across the logging pipeline after GraphGoblin was reported.
A SQL column overflow in the gatehouse
Step back and look at the root cause. Two of the four bypasses — the two that returned actual tokens — worked because a string was too long for a database column.
This is not an exotic attack. This is not a sophisticated zero-day. This is a logging system that crashes on long input and fails open instead of failing closed. The authentication pipeline and the logging pipeline are decoupled enough that one can succeed while the other silently drops the record.
As Nyxgeek put it: "None of the bypasses I've submitted these last few years were complicated. Yet Microsoft's security review of Entra ID missed all of them."
The irony is hard to miss. SQL column length overflow is exactly the kind of bug that shows up in AI-generated code — and in production systems maintained by the largest software company on earth.
Why Microsoft won't call it a CVE
None of the four bypasses received a CVE. Microsoft rated GraphGoblin — the bypass that returned full bearer tokens with zero logging — as "Moderate" severity. Not "Important." Not "Critical." Moderate.
Nyxgeek scored it differently: CVSS 7.5 (v3.1) and 8.7 (v4.0). His reasoning: the bypass enables undetectable credential theft against any Azure Entra ID tenant, defeating the primary detection mechanism organizations rely on.
Here's the conflict. Microsoft is their own CVE Numbering Authority (CNA). They decide what gets a CVE and what doesn't. When the vendor, the security reviewer, and the CVE issuer are all the same entity, the incentive to minimize findings is structural.
The community noticed. On Hacker News, commenters pointed to a pattern: Microsoft previously lost weeks of cloud security logs in a separate incident, the CISA Cyber Safety Review Board found Microsoft's security culture inadequate, and there's a recurring theme of downplaying cloud security issues that affect the entire Azure ecosystem.
Despite calling it "Moderate," Microsoft fixed GraphGoblin in about two months — fast compared to the nine months GraphNinja took. When a vendor fixes a "Moderate" bug faster than a previously reported one, it tells you something about how they actually prioritize it internally.
What this means for builders
You might be thinking: this is an Azure infrastructure problem, not my problem. And you're partially right — you can't fix Azure's logging pipeline. But the lesson here is far bigger than Microsoft.
If your only audit trail is your platform's, you're audit-blind
Every builder trusts some platform's logs. Supabase logs. Vercel logs. Firebase logs. AWS CloudTrail. When something goes wrong, you check them. You assume they're complete. You assume they're the single source of truth.
Azure Entra ID sign-in logs are one of the most security-critical logging systems on the planet, trusted by hundreds of thousands of organizations, and they had four separate bypasses over three years. Four ways to authenticate without leaving a trace.
Here's the terrifying part: you found out about this from a researcher. Microsoft didn't tell you your logs had blind spots. An external security team did. If Microsoft's logging can fail silently, so can anyone's. You'll never know unless someone like Nyxgeek digs into it.
A field that was too long; a token that still worked
The GraphGoblin bypass was elegant in its simplicity: repeat a valid OAuth scope 10,000 times so the value balloons to tens of thousands of characters. The authentication service processes it, validates credentials, issues a valid bearer token. But when the logging system tries to INSERT the event, the oversized scope value exceeds the column length. The INSERT fails. The token was issued. The log entry was not.
This is the same class of bug that shows up in AI-generated code constantly — missing input validation, no length limits, assumptions about data size. The difference is that this one was in Microsoft's production auth infrastructure. If Microsoft misses this in their own code, what are the odds it's not also in yours?
You can't see what you're not logging
The scariest part is that logging gaps are invisible. There's no alert for "a login happened but wasn't logged." If an attacker uses one of these bypasses to spray passwords or steal a bearer token, your logs look clean. Your SIEM shows nothing. Your security dashboard is green. The absence of a log entry is not evidence that nothing happened.
Every app has logging gaps. You just don't know where they are until after something goes wrong. By then it's too late.
What you should do right now
-
Never trust a blank log as proof of absence. If your authentication logs show zero suspicious activity all week, you learned two things: nothing happened, or something happened that didn't get logged. Build your security posture around both possibilities. A clean log is not the same as a secure app.
-
Cross-reference your audit sources. Don't rely on one log stream. Compare API access logs against auth logs. Check your application logs against your platform's logs. Nyxgeek's detection query looked for session IDs in Microsoft Graph activity that didn't appear in sign-in logs. You can do the same: any action that created a session but has no corresponding auth entry is a red flag.
-
Validate every input length — everywhere. The GraphGoblin bypass worked because a field had no length limit. In your own app, set maximum lengths on every field that hits your logging — not just user-facing fields, but headers, query parameters, OAuth scopes, cookie values. If you're using AI to generate your backend, verify this first. Send a 50,000-character string and trace where it goes.
-
Log before you trust the platform. Don't rely solely on your cloud provider's logging. Log authentication events at the moment of token issuance, before handing control to the platform. Log at the application layer. If your platform's logging fails silently, yours still has the record. On Supabase? Log in a server action. On Firebase? Log to your own backend. On Lambda? Log to CloudWatch and S3.
-
Verify your auth surface is actually visible. Flowpatrol scans what's exposed — auth endpoints, API surface, access controls, missing defenses. It tells you what an attacker sees, not what your logs claim. Paste your URL and get a report in five minutes. You'll see what's actually exposed before an attacker does.
The invisible attack is the hardest to stop
Nearly every organization in America runs on Azure in some form. Nearly every builder trusts their platform's security features without question. That trust isn't unreasonable — but it shouldn't be a substitute for checking.
Four bypasses. Three years. Zero public warnings. The bugs weren't sophisticated — a string too long, a field that exceeded a column limit, a logging system that failed silently instead of failing safe. The logging infrastructure that hundreds of thousands of organizations depend on had blind spots nobody knew about.
Microsoft knew eventually, because Nyxgeek told them. You found out because a researcher published the details. Your competitors might not know at all.
Your app inherits your platform's security — including its gaps. Your logs might have blind spots you've never tested. The only thing you actually control is whether you've looked.
The Azure Entra ID sign-in log bypasses are documented in Nyxgeek's full disclosure on the TrustedSec blog (March 19, 2026). The bypasses were discussed extensively on Hacker News.
