blueredix logo
SCAN On-demand vulnerability scans from €149
info vuln-class-auth-bypass

Authentication Bypass, in plain English

Authentication bypass is a category of bug where the attacker reaches a protected resource without the credentials that should have been required. The most embarrassing CVEs of the last decade live here.

What this is

Authentication bypass is the umbrella term for any bug that lets an attacker reach a resource that should require credentials, without actually providing them. It covers a wide range of distinct mistakes; what they share is the outcome — the attacker gets in.

The subtypes you’ll find in CVE descriptions:

  • Missing authentication on an endpoint. The login screen is protected, but the API endpoint that does the real work isn’t. Sneaking around the front door.
  • Logic mistakes in the authentication code. The check returns “true” for the wrong reason — a typed == instead of ===, an empty password treated as a match, an “admin override” header left in production by mistake.
  • IDOR — Insecure Direct Object Reference. Authentication works, but authorisation is missing. The user logs in as themselves and then accesses /orders/123456 belonging to a different customer.
  • Path-based bypass. The protected URL is /admin/..., the protection regex is ^/admin/, the attacker requests /admin/../admin/... or /admin;extra/... and slips through.
  • Default credentials. “admin” / “admin” still works. Vendor-shipped routers, MongoDB instances on default port with no auth, Jenkins installations where nobody finished the first-run setup wizard.
  • JWT signature bypass. A long list of failure modes — alg: none, key confusion between symmetric and asymmetric, kid-header path traversal — has resurfaced in JWT libraries every couple of years.
  • OAuth / OpenID misconfiguration. A weakly-validated redirect_uri, a state parameter not bound to the session, an implicit flow used where the auth-code flow is required.

Why it keeps happening

Authentication is a feature you ship at the start of a project. Authorisation — the per-endpoint, per-record checks — is woven into every feature added later, by every developer on the team. As soon as the team has more than two people and the codebase is a couple of years old, somebody adds an endpoint that forgets the “is-this-user-allowed-here” check.

The OWASP Top Ten has had broken access control in the #1 spot since 2021 specifically because the fix is “fix every endpoint, every time, forever”.

What an attacker gains

Outcomes range from “single record disclosed” (one IDOR, one record the attacker shouldn’t have read) to “full administrative control” (an unauthenticated admin endpoint on a CMS, a default-credential router, a JWT bypass in a SaaS API).

A few recent examples that show the pattern:

  • Confluence Data Center CVE-2023-22518. Unauthenticated admin reachable via a misrouted path. CVSS 10.0. Active exploitation within a week.
  • MOVEit Transfer CVE-2023-34362. SQL injection plus auth bypass. Used to exfiltrate data from Shell, BBC, BA, and dozens of others in 2023.
  • Citrix NetScaler CVE-2023-3519. Unauthenticated remote code execution via auth bypass. Listed as actively exploited within 24 hours of disclosure.

The price of one such CVE in a product you operate is typically a mandatory disclosure to your customers under GDPR Articles 33–34 plus an emergency patch.

How it gets fixed

For application code:

  1. Default-deny. Build your authorisation framework so that an endpoint with no explicit rule is rejected, not accepted. The opposite (default-allow) means every new endpoint is broken until somebody remembers to lock it down.
  2. Centralise the check. A single requireAuth() / requirePermission(role, resource) helper used by every endpoint is auditable. Hand-rolled checks per endpoint aren’t.
  3. Test the boundary. An integration test that calls every protected endpoint without a session and confirms it returns “unauthorised”. Run it in CI.
  4. For multi-tenant data, parameterise queries by tenant ID at the framework level (Rails acts_as_tenant, Django django-multitenant, a repository layer with WHERE tenant_id = ? baked in). This makes IDOR-prone queries structurally hard to write.

For deployed third-party software:

  1. Patch promptly. Auth-bypass CVEs draw exploit attention within hours.
  2. Don’t expose admin panels and management interfaces to the public internet. Keep them behind a VPN or an IP allowlist.
  3. Change default credentials at deployment time and document the change so the next operator doesn’t undo it.

How blueredix surfaces auth-bypass findings

The scanner flags:

  • CVEs in third-party software with auth-bypass / authentication-bypass / unauth-RCE in the description.
  • Default credentials and exposed admin panels via the curated templates we run.
  • Cookie-attribute findings (cookie-missing-secure, cookie-missing-httponly, cookie-missing-samesite) — cookie hygiene that makes session theft easier when something else slips.

We don’t actively try credentials against your application — that crosses the line into authorised testing.

Further reading