Comprehensive Authentication Guide#
🆕 Updated September 12, 2026 — added the NetScaler SAML canonicalization overflow (CVE-2026-8452) and why pre-signature-verification parsing is every SAML SP’s unauthenticated attack surface.
A practitioner’s reference for authentication security — protocols, mechanisms, vulnerabilities, exploitation techniques, and defense strategies. Covers traditional and modern authentication methods from enterprise to web applications.
Table of Contents#
- Fundamentals
- Password-Based Authentication
- Multi-Factor Authentication (MFA)
- OAuth 2.0 & OpenID Connect
- SAML & Enterprise SSO
- Modern Authentication (FIDO, WebAuthn, Passkeys)
- JWT Security
- Session Management
- Authentication Bypasses & Attacks
- Implementation Security
- Testing & Verification
1. Fundamentals#
Core Concepts#
| Term | Definition | Security Impact |
|---|
| Authentication (AuthN) | Process of verifying identity claims | Foundation of access control |
| Digital Identity | Unique representation in online context | Basis for authorization decisions |
| Identity Proofing | Binding digital identity to real person | KYC/compliance requirement |
| Session Management | Maintaining state across requests | Critical for web application security |
| Non-Human Identity (NHI) | API keys, OAuth tokens, service accounts | Path of least resistance for attackers — not bound by MFA or IP restrictions |
Authentication Factors#
| Factor Type | Examples | Vulnerability Classes |
|---|
| Something You Know | Passwords, PINs, security questions | Brute force, credential stuffing, social engineering |
| Something You Have | Hardware tokens, mobile apps, SMS | SIM swapping, device theft, malware |
| Something You Are | Biometrics (fingerprint, face, voice) | Spoofing, template theft, privacy concerns |
2. Password-Based Authentication#
Password Strength Requirements#
| Requirement | NIST SP800-63B Standard | Security Rationale |
|---|
| Minimum Length | 8 chars (with MFA), 14+ (without MFA) | Increases brute force difficulty |
| Maximum Length | At least 64 characters | Prevents artificial length limits |
| Character Composition | No mandatory complexity rules | Avoid predictable patterns |
| Dictionary Checking | Block common passwords | Prevent credential stuffing |
Common Password Vulnerabilities#
ATTACK VECTORS:
├── Credential Stuffing
│ ├── Breach databases (HaveIBeenPwned)
│ ├── Password reuse across sites
│ └── Automated login attempts
├── Brute Force Attacks
│ ├── Dictionary attacks
│ ├── Rule-based mutations
│ └── Hybrid attacks
└── Password Reset Flows
├── Weak reset tokens
├── Token reuse vulnerabilities
├── Account enumeration
└── Email interception for ATO (Post SMTP CVE-2025-24000 — Subscriber+ reads reset emails via broken REST API permissions)
Secure Implementation Patterns#
| Security Control | Implementation | Bypass Techniques |
|---|
| Rate Limiting | Progressive delays, account lockouts | IP rotation, distributed attacks |
| CAPTCHA | Human verification challenges | OCR bypass, solving services |
| Password Hashing | bcrypt, scrypt, Argon2 | Rainbow tables (if salts weak) |
| Breach Detection | Monitor for credential exposure | Private/corporate breaches |
| REST API Auth | Role-based permission callbacks (not just is_user_logged_in()) | Subscriber-level access to admin endpoints |
3. Multi-Factor Authentication (MFA)#
MFA Implementation Types#
| Method | Security Level | User Experience | Attack Vectors |
|---|
| SMS OTP | Low | High friction | SIM swapping, SS7 attacks |
| TOTP Apps | Medium | Medium friction | Device compromise, social engineering |
| Push Notifications | Medium-High | Low friction | MFA fatigue, device takeover |
| Hardware Tokens | High | Medium friction | Physical theft, supply chain |
| Biometrics | High | Low friction | Spoofing, template extraction |
| Passwordless (FastPass/FIDO2) | Very High | Low friction | Device compromise (Okta Terrify), endpoint proxy |
MFA Bypass Techniques#
BYPASS METHODS:
├── Social Engineering
│ ├── MFA fatigue (push spam)
│ ├── Vishing (voice phishing)
│ └── SIM swapping
├── Technical Bypasses
│ ├── Session fixation
│ ├── MFA enrollment abuse
│ ├── Backup code exploitation
│ └── Race conditions
├── Adversary-in-the-Middle (AiTM)
│ ├── Real-time phishing (Evilginx, Tycoon 2FA, Evilproxy, Mamba 2FA)
│ ├── Session cookie interception and replay
│ ├── Token replay
│ └── Cloudflare Workers as transparent proxy (IOActive research)
├── Authentication Downgrade Attacks
│ ├── JSON config manipulation — flip FIDO2 isDefault:false, push isDefault:true
│ ├── CSS injection to hide passkey/FIDO2 UI options
│ ├── Browser User-Agent spoofing (e.g., Safari on Windows) to trigger Entra ID fallback
│ └── WebAuthn immediate mediation abuse for non-WebAuthn fallback steering
├── Conditional Access Policy (CAP) Bypasses
│ ├── IP whitelisting bypass (VPN, Zscaler pivoting)
│ ├── Geo-whitelisting bypass (VPN/location spoofing)
│ ├── User-agent whitelisting bypass (custom UA strings)
│ ├── Cloud tooling bypasses (ROADtools, BloodHound, AADInternals)
│ └── Non-MFA hosts (legacy protocols, password reset portals)
└── Machine-Based Attacks
├── Session token theft from memory (Cobalt Strike BOFs)
├── OTP keylogging / seed QR code theft
├── Okta Terrify — extract passwordless keys from compromised endpoint
└── Stolen/unlocked devices
Phishing-as-a-Service (PhaaS) Kits#
| Kit | Technique | Detection Evasion |
|---|
| Evilginx | Open-source reverse proxy AiTM | Default LetsEncrypt certs, 8-char URL paths, TLS fingerprint differs from target |
| Tycoon 2FA | PhaaS MFA bypass | Dynamically obfuscated JS, phishing URL gating, IP/UA filtering |
| Evilproxy | PhaaS MFA bypass | Templates for popular targets, bot detection |
| Mamba 2FA | PhaaS MFA bypass | Anti-crawler delays, redirect to benign pages |
| Cloudflare Workers | Serverless transparent proxy (IOActive PoC) | Zero forensic footprint, trusted CDN IPs, ephemeral execution |
Implementation Security Checklist#
| Control | Verification | Common Mistakes |
|---|
| Enrollment Security | Verify primary auth before MFA setup | Allow MFA changes without re-auth |
| Backup Mechanisms | Secure recovery codes | Weak backup code generation |
| Device Trust | Risk-based authentication | Unlimited device trust |
| Rate Limiting | Throttle MFA attempts | No limits on failed attempts |
| Eliminate Fallbacks | No SMS/TOTP/push if FIDO2 deployed | Mixed-mode policies allow downgrade |
| Audit MFA Logs | Detect new MFA device registration post-compromise | Missing persistence detection |
4. OAuth 2.0 & OpenID Connect#
OAuth 2.0 Flow Types#
| Grant Type | Use Case | Security Considerations |
|---|
| Authorization Code | Server-side web apps | Most secure, requires PKCE for SPAs |
| Authorization Code + PKCE | Public clients, SPAs | Prevents authorization code injection |
| Implicit | Legacy SPAs | Deprecated, token in URL fragment |
| Client Credentials | Service-to-service | No user context, secure storage critical |
| Device Code | IoT/limited input devices | Phishing risk during user approval |
Common OAuth Vulnerabilities#
| Vulnerability | Attack Vector | Mitigation |
|---|
| Authorization Code Interception | Redirect URI manipulation | Strict redirect validation |
| State Parameter Missing | CSRF attacks | Cryptographically strong state |
| Scope Escalation | Privilege elevation | Minimal scope principle |
| Client Impersonation | Stolen client credentials | Client authentication |
| OAuth Parameter Injection | Inject arbitrary params (redirect_uri, scope) into auth flow | Input sanitization (Okta auth0/nextjs-auth0 vuln) |
| Implicit Flow Token Theft | Access token in URL fragment, referer leakage | Migrate to Authorization Code + PKCE |
| CSRF via Missing State | Attacker injects own authorization code into victim session | State parameter enforcement |
| Redirect URI Bypass | Pattern-matching bypass (%2f%2f, %5c%5c, %3F, %23, port injection) | Exact string match, no wildcards |
| Credential Leakage via Referer | Authorization code or token in Referer header to third-party content | No third-party resources on callback pages |
| Non-Human Identity Abuse | Compromised OAuth tokens with overly broad scopes, null expiry refresh tokens | Scope minimization, token rotation, vendor vetting |
Dynamic Client Registration SSRF (PortSwigger Research)#
SSRF ATTACK SURFACE VIA DYNAMIC REGISTRATION:
├── logo_uri — Server fetches logo image → SSRF on /authorize
├── jwks_uri — Server fetches JWK set for client_assertion validation → Blind SSRF
├── sector_identifier_uri — Server fetches redirect_uri list → SSRF on registration or authorization
├── request_uris — Whitelisted request_uri values → SSRF on /authorize via request_uri param
│ (Even without dynamic registration, test request_uri on /authorize directly)
└── Discovery: GET /.well-known/openid-configuration
├── registration_endpoint
├── request_uri_parameter_supported
└── require_request_uri_registration
CVE-2021-26715: SSRF via logo_uri in MITREid Connect
ForgeRock OpenAM: SSRF via request_uri + redirect_uri Session Poisoning
OAuth Security Implementation#
SECURITY CONTROLS:
├── Authorization Server
│ ├── Strict redirect URI validation (exact match, no wildcards)
│ ├── State parameter enforcement
│ ├── PKCE for public clients
│ ├── Short-lived authorization codes (single use)
│ └── Disable Dynamic Client Registration if not needed
├── Resource Server
│ ├── Token introspection
│ ├── Scope validation
│ ├── Audience verification
│ └── Rate limiting
├── Client Application
│ ├── Secure token storage (never in browser history/URL)
│ ├── Token refresh handling with expiry
│ ├── CSRF protection via state parameter
│ ├── PKCE code_verifier/code_challenge
│ └── TLS everywhere
└── Non-Human Identity Governance
├── Monitor OAuth app registrations and consent grants
├── Audit token scopes vs actual usage
├── Enforce refresh token expiry (no null expiry)
└── Vendor breach monitoring for third-party OAuth apps
OAuth Pentesting Checklist (Authorization Code Grant)#
| Test Case | What to Check | Impact |
|---|
| Redirect URI Validation | Change redirect_uri to attacker domain, test pattern bypasses | Token/code theft |
| State Parameter | Remove or reuse state, test CSRF | Account hijacking |
| Code Reuse | Replay authorization code | Session hijacking |
| Client Secret Exposure | Check JS source, mobile app binaries | Full OAuth flow compromise |
| Scope Manipulation | Request elevated scopes | Privilege escalation |
| Token in URL/History | Check if access_token appears in URL fragment or browser history | Token theft |
| Referer Leakage | Check callback pages for third-party resource loads | Code/token leakage |
| request_uri SSRF | Supply attacker URL in request_uri param on /authorize | Server-side request forgery |
5. SAML & Enterprise SSO#
SAML Attack Surface#
| Component | Attack Vectors | Security Controls |
|---|
| Identity Provider (IdP) | XML signature bypass, SAML injection | Strong XML validation, signature verification |
| Service Provider (SP) | Assertion replay, audience restriction bypass, parser differential exploitation | Strict temporal/audience checks, single XML parser |
| SAML Assertions | XXE, signature wrapping (XSW), attribute pollution | Secure XML parsing, validation |
| Metadata | Metadata spoofing, certificate substitution | Out-of-band verification |
| FortiCloud SSO | Crafted SAMLResponse to /remote/saml/login (CVE-2025-59718) | Disable FortiCloud SSO until patched |
Citrix NetScaler SAML canonicalization overflow (CVE-2026-8452)#
Citrix published CTX696604 on 30 June 2026. CVSS 8.8, unauthenticated, and it belongs in a SAML guide rather than a memory-safety one because of where in the SAML flow it sits.
Before NetScaler validates a SAML message’s signature, it canonicalizes part of the message — rewrites it into standard form so the signature can be computed over something stable. One attacker-supplied field used in that step, the PrefixList, gets copied into a fixed-size buffer with no length check. Heap overflow in the packet engine — the process carrying all traffic through the appliance — from a single unauthenticated HTTP request.
Canonicalization runs before signature verification. It has to. You can’t verify a signature until you’ve normalized the thing you’re verifying, so every SAML implementation has a stretch of parsing that executes on fully attacker-controlled XML with zero trust established. That’s the pre-auth attack surface in every SAML SP you’ll ever test, and it’s why “we validate the signature” is not an answer to “what happens if I send you garbage.”
Practical notes if you’re on the defending side:
- Minimum fixed builds are 13.1-63.18 and 14.1-72.61. Go past them — Citrix has shipped further advisories since.
- 12.1 and 13.0 get no fix. Migrate.
- FIPS and NDcPP fleets run their own build cadence. Easy to miss in an inventory.
- Citrix’s advisory names Gateway and AAA virtual servers without mentioning SAML, but SAML is the way in — the vulnerable endpoints only exist where SAML is configured. Scope by virtual server, then check which have SAML on.
- Bishop Fox showed patch state is measurable from outside with one or two ordinary SAML requests, no crash and no disruption, by comparing responses to different
PrefixList lengths. Credit for the original report goes to Michael Tucker of the JPMorgan Chase XOR team; watchTowr published the root cause and the path to code execution.
XML Signature Wrapping (XSW) Attacks — Deep Dive#
XSW ATTACK TAXONOMY:
├── Classic XSW
│ ├── Move signed element, inject forged element in original location
│ ├── Application processes forged data, signature validates against hidden original
│ └── 8+ documented XSW variants in USENIX "On Breaking SAML" research
├── Parser Differential Exploits
│ ├── ruby-saml: REXML + Nokogiri dual parser → different XPath results
│ │ ├── CVE-2025-25291 / CVE-2025-25292 (ruby-saml < 1.18.0)
│ │ ├── CVE-2024-45409 (ruby-saml signature bypass by ahacker1)
│ │ └── Exploited in GitLab — sign in as any user with single valid signature
│ ├── Attribute pollution — parser-specific attribute handling differences
│ ├── REXML namespace confusion — without DTDs
│ └── Void Canonicalization — novel technique (PortSwigger "The Fragile Lock")
├── Signature Exclusion / Comment Injection
│ ├── Removing Signature element entirely
│ ├── XML comment injection between signature elements
│ └── Bypassing signature validation in libraries that don't enforce presence
├── Encrypted Assertion Bypass
│ ├── GitHub Enterprise: signature extracted pre-decryption, inner assertion signature never validated
│ │ ├── CVE-2024-4985 / CVE-2024-9487
│ │ └── Forge assertion inside encrypted envelope, only outer response signature checked
│ └── samlify (Node.js): CVE-2025-47949 — Signature Wrapping with unsigned assertion extraction
└── Improper Cryptographic Signature Verification
├── FortiGate FortiCloud SSO: CVE-2025-59718 / CVE-2025-59719 (CVSS 9.8)
│ ├── SAML response signature not validated → forged SAMLResponse grants super_admin
│ ├── Endpoint: POST /remote/saml/login
│ ├── Actively exploited in the wild (Arctic Wolf, CISA KEV)
│ └── Affects FortiOS, FortiProxy, FortiSwitchManager, FortiWeb
└── CWE-347 pattern: system checks temporal claims but skips signature verification
Real-World SAML CVEs#
| CVE | Product | Vulnerability | Impact |
|---|
| CVE-2025-59718 | FortiGate FortiCloud SSO | Missing SAML signature validation | Unauthenticated admin access |
| CVE-2025-59719 | FortiGate FortiCloud SSO | Related bypass variant | Unauthenticated admin access |
| CVE-2025-25291 | ruby-saml | Parser differential (REXML/Nokogiri) | Sign in as any user |
| CVE-2025-25292 | ruby-saml | Parser differential (REXML/Nokogiri) | Sign in as any user |
| CVE-2024-45409 | ruby-saml | Signature bypass | Authentication bypass |
| CVE-2024-4985 | GitHub Enterprise | Encrypted assertion signature skip | SAML SSO bypass |
| CVE-2024-9487 | GitHub Enterprise | Follow-up encrypted assertion fix | SAML SSO bypass |
| CVE-2025-47949 | samlify (Node.js) | Signature Wrapping — unsigned assertion consumed | Authentication bypass, user impersonation |
SAML Bug Hunting Methodology#
SAML TESTING WORKFLOW (using SAML Raider):
├── Setup
│ ├── Install SAML Raider Burp extension
│ ├── Import/clone X.509 certificates
│ └── Capture SAML Response in proxy
├── Signature Wrapping Tests
│ ├── Apply all 8 XSW variants from SAML Raider
│ ├── Test with both signed Response and signed Assertion
│ └── Test with cloned/self-signed certificates
├── Signature Removal
│ ├── Remove Signature element entirely
│ ├── Remove SignatureValue content
│ └── Test if SP accepts unsigned assertions
├── Assertion Manipulation
│ ├── Modify NameID to target user
│ ├── Modify role/group attributes
│ ├── Change audience restriction
│ └── Alter temporal conditions (NotBefore/NotOnOrAfter)
├── XML-Level Attacks
│ ├── XXE injection in SAML Response
│ ├── XML comment injection in NameID
│ ├── DTD-based attacks (if not blocked)
│ └── Namespace confusion / attribute pollution
└── Certificate Tests
├── Clone IdP certificate, self-sign assertion
├── Test if SP validates certificate chain
└── Test if SP accepts any valid signature (not just from trusted IdP)
6. Modern Authentication (FIDO, WebAuthn, Passkeys)#
FIDO2/WebAuthn Architecture#
| Component | Function | Security Properties |
|---|
| Authenticator | Private key storage, user verification | Hardware-backed, phishing-resistant |
| Client (Browser) | Protocol handling, user interaction | Sandboxed execution, origin binding |
| Relying Party | Credential management, verification | Challenge-response validation |
| FIDO Server | Registration/authentication logic | Cryptographic verification |
Passkey Types and Security Properties#
| Type | Storage | Security Level | Enterprise Suitability |
|---|
| Device-Bound (Hardware Key) | YubiKey, security key hardware | Highest — non-exportable, hardware-backed | Recommended for enterprise |
| Synced (Multi-Device) | iCloud Keychain, Google Password Manager | Medium — inherits cloud account risk | Consumer use only; not recommended for enterprise |
Synced Passkey Risks#
SYNCED PASSKEY ATTACK SURFACE:
├── Cloud Account Compromise
│ ├── iCloud/Google account takeover → all synced passkeys compromised
│ ├── Recovery workflow abuse → authorize new device with stolen credentials
│ └── Personal cloud account on corporate device → passkeys leak to personal devices
├── Authentication Downgrade
│ ├── AiTM proxy spoofs unsupported browser → Entra ID disables passkey option
│ ├── User steered to SMS/OTP/push → captured by proxy
│ └── WebAuthn immediate mediation abused to offer weak fallback
├── Browser Extension Attacks
│ ├── webAuthenticationProxy API — intercept navigator.credentials.create()/get()
│ ├── Content script DOM injection — manipulate passkey UI elements
│ ├── DOM-based extension clickjacking — trigger autofill and exfiltration
│ └── Malicious extension forces password fallback or re-registration
└── Help Desk Social Engineering
└── Recovery process = real control point attackers target
WebAuthn Security Benefits#
| Protection | Traditional Auth | WebAuthn |
|---|
| Phishing Resistance | Credentials reusable | Origin binding prevents cross-site use |
| Credential Theft | Server breaches expose passwords | Public key only stored server-side |
| Replay Attacks | Static credentials | Cryptographic challenges with freshness |
| Man-in-the-Middle | Credentials interceptable | Origin verification blocks proxy attacks |
Enterprise Passkey Deployment Guidance#
| Area | Recommendation | Rationale |
|---|
| Credential Type | Device-bound only (hardware security keys) | Non-exportable, hardware-backed, inventoriable |
| Fallback Methods | Eliminate all (SMS, TOTP, push, email) | Weakest method = real security level |
| Browser Extensions | Allowlist only; block webAuthenticationProxy permission | Prevent WebAuthn API interception |
| Attestation | Capture device model and assurance at registration | Reject unrecognized authenticators |
| Recovery | Hardware key-based reproofing only | No help desk/email-based recovery |
| Session Binding | Tie sessions to device context, not just initial auth | Prevent portable session cookie theft |
Cloudflare FIDO2 Deployment Case Study#
CLOUDFLARE ROLLOUT TIMELINE:
├── 2018: Distributed YubiKey 5 Nano + YubiKey 5 NFC to all employees
├── 2020: Selective enforcement via Cloudflare Access (Zero Trust proxy)
│ ├── OAuth2 integration with IdP, enforce "swk" (security key) AMR value
│ └── Incremental rollout — one service at a time
├── Feb 2021: Full enforcement — disabled all TOTP/SMS
│ ├── Triggered by social engineering phone calls to employees
│ └── Offline recovery process for lost keys (distribute 2 keys per employee)
├── SSH via Cloudflare Tunnel: cloudflared + Access policies enforce FIDO2 for SSH
└── Result: Zero successful phishing attacks post-deployment
7. JWT Security#
JWT Attack Vectors#
| Vulnerability | Technique | Real-World Example |
|---|
| Algorithm Confusion (alg=none) | Set JWT header alg to “none”, remove signature | Classic JWT bypass |
| Missing Signature Verification | Server decodes JWT but never checks signature | Convoy KVM CVE-2026-33746 (CVSS 9.8) — JWTService::decode() missing SignedWith constraint |
| JWE Encryption Mix-Up | Encrypt unsigned PlainJWT with server’s RSA public key; server decrypts and accepts without signature check | pac4j-jwt CVE-2026-29000 — forge admin tokens with public key only |
| Hardcoded JWT Secrets | Static/weak signing secrets | Zendesk Android SDK — hardcoded secret “987sdasdlkjlakdjf” + sequential IDs → mass ATO |
| Weak Cookie Auth Tags | Brute-forceable authentication tags on session cookies | Auth0-PHP SDK CVE-2025-47275 (CVSS 9.1) — brute force CookieStore auth tags |
| Default Signing Keys | Predictable or default JWT signing keys | Apache StreamPipes CVE-2025-47411 |
JWT Security Checklist#
| Control | Implementation | Common Mistakes |
|---|
| Algorithm Enforcement | Whitelist allowed algorithms server-side | Accept alg from JWT header without validation |
| Signature Verification | Always verify before trusting claims | Check only expiration (Convoy pattern) |
| Key Management | Rotate secrets, use asymmetric keys | Hardcoded secrets, public key in source |
| Claim Validation | Verify iss, aud, exp, nbf, iat | Trust user-controlled claims |
| JWE Handling | Enforce inner JWT must be signed, not PlainJWT | Accept PlainJWT inside JWE (pac4j-jwt pattern) |
8. Session Management#
Session Security Requirements#
| Property | Implementation | Attack Prevention |
|---|
| Uniqueness | Cryptographically random IDs | Session prediction |
| Unpredictability | High entropy (128+ bits) | Brute force guessing |
| Secure Transmission | HTTPS only, Secure flag | Network interception |
| Proper Expiration | Absolute/idle timeouts | Session hijacking |
| Device Binding | Tie session to device context/posture | Portable cookie theft via AiTM |
Session Attack Vectors#
SESSION ATTACKS:
├── Session Hijacking
│ ├── Network sniffing
│ ├── Cross-site scripting (XSS)
│ ├── Malware/browser compromise
│ └── AiTM reverse proxy cookie interception (Evilginx, Tycoon 2FA)
├── Session Fixation
│ ├── Pre-authentication session reuse
│ ├── URL-based session ID
│ └── Missing session regeneration
├── Session Timing
│ ├── Concurrent sessions
│ ├── Logout handling
│ └── Session timeout bypass
└── Session Token Portability
├── Stolen session cookies replayed from different device/IP
├── Impossible travel detection evasion
└── Post-compromise MFA device registration for persistence
9. Authentication Bypasses & Attacks#
Business Logic Bypasses#
| Bypass Type | Technique | Testing Approach |
|---|
| Direct Access | URL manipulation | Forced browsing, parameter tampering |
| State Manipulation | Session/workflow bypass | Multi-step process analysis |
| Role Confusion | Privilege escalation | Horizontal/vertical privesc testing |
| Reset Abuse | Account takeover | Password reset flow analysis |
| Middleware-Only Auth | Next.js CVE-2025-29927 — x-middleware-subrequest header bypass | Verify auth in page routes/API routes, not just middleware |
Critical Authentication CVEs (2026)#
Recent authentication vulnerabilities demonstrate evolving attack patterns across enterprise systems and cloud services:
CVE-2026-3965 & CVE-2026-4047 - Qinglong Authentication Bypass
Critical authentication bypass vulnerabilities in Qinglong task scheduler enabling remote code execution. Demonstrates how authentication flaws can escalate to complete system compromise in task automation platforms.
CVE-2026-42208 - LiteLLM Authentication Security Flaw
Critical SQL injection vulnerability in LiteLLM proxy service that affects authentication and authorization mechanisms, exploited within 36 hours of disclosure for credential theft and unauthorized access.
CVE-2025-6514 - MCP OAuth Proxy Authentication Bypass
OS command injection vulnerability in MCP (Model Context Protocol) OAuth proxy service affecting authentication flows in AI development environments, leading to full system compromise.
Modern Authentication Attack Trends:
AI/ML Platform Authentication:
- OAuth proxy vulnerabilities in AI development platforms
- MCP server authentication bypass leading to credential theft
- LiteLLM service authentication flaws enabling data exfiltration
Task Automation Platform Bypass:
- Scheduler service authentication bypass enabling RCE
- Container orchestration authentication flaws
- CI/CD platform authentication vulnerabilities
Enterprise SSO Exploitation:
- Multi-tenant authentication bypass patterns
- Cross-organization privilege escalation
- Identity federation security gaps
These vulnerabilities highlight the importance of comprehensive authentication security across modern technology stacks, particularly in AI/ML and automation platforms where authentication failures can lead to rapid exploitation and significant impact.
Technical Bypasses#
COMMON BYPASS PATTERNS:
├── Authentication Logic Flaws
│ ├── Boolean bypass (admin=true)
│ ├── SQL injection in auth queries
│ ├── LDAP injection
│ └── Authentication timing attacks
├── Protocol-Specific Issues
│ ├── JWT manipulation (alg=none, missing signature verification, JWE mix-up)
│ ├── OAuth state bypass / parameter injection
│ ├── SAML signature bypass (XSW, parser differential, encrypted assertion)
│ └── Kerberos attacks (Golden/Silver tickets)
├── Framework-Specific Bypasses
│ ├── Next.js middleware bypass (CVE-2025-29927) — set x-middleware-subrequest header
│ ├── WordPress REST API permission flaws (Post SMTP CVE-2025-24000)
│ └── Grafana open redirect + CSPT → XSS → account takeover (CVE-2025-6023)
├── Predictable Token Generation
│ ├── Zendesk Android SDK — SHA-1(REDACTED-{AccountID}-{HardcodedSecret}) → zero-click mass ATO
│ ├── Sequential ID enumeration + static secrets
│ └── No rate limiting on token validation endpoints
└── Implementation Weaknesses
├── Default credentials
├── Weak password policies
├── Missing rate limiting
├── Insecure session handling
└── AI-generated code with insufficient input sanitization (Okta nextjs-auth0 OAuth injection)
Real-World Authentication CVEs#
| CVE | Product | Type | CVSS | Impact |
|---|
| CVE-2025-59718 | FortiGate | SAML signature bypass | 9.8 | Unauthenticated admin access (actively exploited, CISA KEV) |
| CVE-2026-33746 | Convoy KVM | JWT signature skip | 9.8 | Full account takeover including admin |
| CVE-2026-29000 | pac4j-jwt | JWE encryption mix-up | Critical | Forge admin tokens with RSA public key |
| CVE-2025-47275 | Auth0-PHP SDK | Cookie auth tag brute force | 9.1 | Unauthorized account access |
| CVE-2025-47949 | samlify | SAML Signature Wrapping | Critical | Authentication bypass, user impersonation |
| CVE-2025-29927 | Next.js | Middleware auth bypass | Critical | Authorization bypass via internal header |
| CVE-2025-25291/92 | ruby-saml | Parser differential | Critical | Sign in as any user (GitLab exploitable) |
| CVE-2024-4985 | GitHub Enterprise | Encrypted assertion bypass | Critical | SAML SSO bypass |
| CVE-2025-24000 | Post SMTP (WordPress) | Broken access control | High | Subscriber reads admin emails → ATO |
| CVE-2025-6023 | Grafana | Open redirect + CSPT → XSS | High | Full account takeover |
| CVE-2025-47411 | Apache StreamPipes | JWT default key | High | Admin privilege escalation |
10. Implementation Security#
Secure Coding Practices#
| Security Control | Implementation Pattern | Common Mistakes |
|---|
| Input Validation | Whitelist validation | Blacklist approaches |
| Cryptography | Industry-standard algorithms | Custom/weak crypto |
| Error Handling | Generic error messages | Information disclosure |
| Logging | Security event logging | Sensitive data in logs |
| AI Code Review | Manual security audit of AI-generated auth code | AI “slop” — functional but insecure patterns (Okta nextjs-auth0 case) |
Framework-Specific Guidance#
FRAMEWORK SECURITY:
├── Spring Security
│ ├── Method-level security
│ ├── CSRF protection
│ └── Session management
├── ASP.NET Identity
│ ├── Identity configuration
│ ├── Cookie authentication
│ └── External providers
├── Express.js/Passport
│ ├── Strategy configuration
│ ├── Session security
│ └── Middleware order
├── Next.js
│ ├── Never rely solely on middleware for auth (CVE-2025-29927)
│ ├── Verify auth in Server Components, Page Routes, and API Routes
│ └── Block x-middleware-subrequest header from external requests
├── WordPress
│ ├── REST API permission callbacks must check capabilities, not just login status
│ ├── Audit plugins exposing sensitive data via REST endpoints
│ └── Post SMTP pattern: get_logs_permission() → is_user_logged_in() is insufficient
└── Node.js SAML (samlify)
├── Upgrade to >= 2.10.0 to fix Signature Wrapping (CVE-2025-47949)
└── Use single XML parser for validation + processing
Defensive Architecture Principles#
| Principle | Implementation | Why It Matters |
|---|
| Eliminate Weak Fallbacks | Remove SMS/TOTP/push when FIDO2 is available | Weakest method = real security posture |
| Single XML Parser | Use one parser for signature validation and data extraction | Parser differentials enable XSW bypasses |
| Defense in Depth for Auth | Auth check at middleware AND route/controller level | Single-layer bypass (Next.js pattern) |
| Hardware-Rooted Trust | Device-bound credentials with attestation | Prevents credential export and synced passkey risks |
| Continuous Auth | Re-evaluate posture on device/location/behavior changes | A login is not a permanent hall pass |
11. Testing & Verification#
Authentication Testing Methodology#
| Phase | Focus Areas | Tools/Techniques |
|---|
| Reconnaissance | Authentication mechanisms, IdP discovery | Manual analysis, Burp Suite, /.well-known/openid-configuration |
| Enumeration | User accounts, endpoints, registration endpoints | Username enumeration, timing attacks, /connect/register |
| Attack Execution | Credential attacks, bypasses, AiTM | Hydra, Evilginx, custom scripts |
| Post-Exploitation | Session security, privilege escalation, persistence | Manual testing, token analysis, MFA device registration |
TESTING ARSENAL:
├── Credential Attacks
│ ├── Hydra (brute force)
│ ├── Medusa (parallel login)
│ ├── Patator (modular brute forcer)
│ └── MFASweep (CAP misconfiguration discovery)
├── OAuth/JWT Testing
│ ├── jwt_tool (JWT manipulation)
│ ├── Burp JWT Editor
│ ├── request_uri SSRF testing via /authorize
│ └── Dynamic Client Registration fuzzing
├── SAML Testing
│ ├── SAML Raider (Burp extension) — 8 XSW variants, cert cloning, assertion editing
│ ├── SAMLReq (CLI tool)
│ ├── Manual XML manipulation
│ └── Parser differential toolkit (PortSwigger "The Fragile Lock")
├── MFA Bypass Testing
│ ├── Evilginx (AiTM reverse proxy)
│ ├── Cloudflare Workers PoC (IOActive auth downgrade)
│ └── ROADtools / AADInternals (Azure AD CAP bypass)
└── Passkey / WebAuthn Testing
├── Browser extension permission auditing (webAuthenticationProxy)
├── Downgrade scenario simulation (UA spoofing, CSS injection)
└── Device-bound vs synced credential policy verification
Security Assessment Checklist#
| Category | Verification Points | Risk Level |
|---|
| Password Security | Strength requirements, storage, reset flows | High |
| Multi-Factor Auth | Implementation, bypass resistance, fallback elimination | Critical |
| Session Management | Generation, transmission, expiration, device binding | High |
| OAuth Protocol Security | Redirect validation, state, PKCE, dynamic registration | Critical |
| SAML Protocol Security | Signature validation, single parser, XSW resistance | Critical |
| JWT Security | Algorithm enforcement, signature verification, key management | Critical |
| WebAuthn/Passkeys | Device-bound enforcement, no fallback, attestation | High |
| Framework Auth | Auth at every layer, not just middleware | High |
| Business Logic | Authentication flows, error handling, race conditions | Medium |
Key Takeaways#
- Defense in Depth: Combine multiple authentication factors and security controls — but eliminate weak fallbacks that attackers will force
- Protocol Compliance: Follow established standards (NIST, OWASP, OAuth specs, FIDO2) and keep libraries updated
- Single Parser Principle: Never use dual XML parsers for SAML signature validation and data extraction
- Phishing-Resistant MFA: Deploy device-bound FIDO2/WebAuthn; synced passkeys are insufficient for enterprise
- JWT Rigor: Always enforce algorithm whitelists, verify signatures before trusting claims, and reject PlainJWT inside JWE
- Implementation Quality: Secure coding practices prevent logic bypasses — audit AI-generated auth code carefully
- Continuous Monitoring: Log authentication events, audit MFA device registrations, detect impossible travel and session anomalies
- Test Real Attack Paths: Use AiTM tools, XSW variants, and downgrade scenarios in security assessments — not just credential brute force
References#
Authentication moves fast — keep an eye on emerging authentication technologies and attack techniques.