A security researcher has dropped CVE-2026-0265, an authentication bypass vulnerability in Palo Alto Networks PAN-OS GlobalProtect that allows attackers to forge valid JWT tokens and hijack VPN login flows. The catch? This wasn't months of painstaking reverse engineering—it took a weekend with Claude Opus 4.6 doing the heavy lifting on stripped binaries that traditionally require serious infrastructure to crack.

Setting Up Shop With an LLM Co-Pilot

The researcher, documenting their process at Hacktron AI, started by tackling one of enterprise security's biggest annoyances: getting root access to PAN-OS VMs for analysis. Instead of weeks of frustrating setup work, Claude generated scripts to bypass AWS marketplace product code restrictions and mount the filesystem directly—complete with later achieving live root on a running instance. The researcher notes this kind of tedious prep work "bores" them, and having an LLM handle it freed them up for actual vulnerability research.

Finding Attack Surface in GlobalProtect's CAS Integration

With root access secured, attention turned to GlobalProtect's authentication mechanisms. SAML and CAS (Palo Alto's cloud-hosted SSO broker) emerged as prime targets. The researcher chose to focus on CAS because the verification logic lives client-side in PAN-OS—meaning it could be reversed and analyzed directly. After hours of poking around with Claude's help mapping running processes, configs, and binary relationships, a high-priority finding materialized almost immediately via Ghidra MCP: a textbook JWT algorithm confusion vulnerability where HS256 could replace RS256, using the signing certificate itself as the HMAC key.

Breaking Down CVE-2026-0265

The bug lives in two functions: pan_jwt_verify extracts the algorithm directly from the parsed JWT header and passes it to pan_auth_verify, which dispatches entirely on that untrusted value. If the attacker specifies HS256/HS384/HS512, the implementation uses the certificate bytes as the HMAC secret—meaning anyone with access to the CAS signing cert can forge tokens for any user. Exploitation required chaining three separate information leaks: extracting device mTLS certificates via crypto function hooks, using those certs to query the metadata endpoint for token signer credentials, and resolving the CSP ID (a unique account identifier) from a device serial number exposed in the outbound JWT during normal SSO flows.

What Makes This Scary

The researcher puts it plainly: "If your defense in depth is to make attackers' lives harder then it doesn't work anymore." GlobalProtect is deployed across countless enterprises as their primary remote access solution—the thing standing between attackers and internal networks. With just a username (typically the user's email address) and valid device certificates, an attacker can authenticate as any user on any enrolled device. The serial number leak happens during normal login attempts, making this exploitable in the wild without special privileges.

Disclosure and patches

Palo Alto published their advisory for CVE-2026-0265 on May 14, 2026, roughly seven weeks after initial disclosure on March 26. Organizations running PAN-OS with CAS authentication enabled should update immediately. The full exploitation chain—including device certificate extraction methods and CSP ID resolution techniques—has not been publicly released, but the underlying vulnerability is now confirmed.

Key Takeaways

  • JWT algorithm confusion remains a critical attack vector even in enterprise security products deployed globally
  • LLM-assisted reverse engineering dramatically lowers the bar for analyzing stripped binaries that previously required specialized infrastructure and weeks of setup
  • Defense-in-depth architectures with cloud authentication brokers create new trust boundaries that must be audited independently

The Bottom Line

This is what the VPN industrial complex doesn't want you to hear: these tools are only as strong as their weakest cryptographic implementation, and algorithm confusion bugs have been well-documented for years. When an LLM can find them in a weekend on hardened enterprise software, maybe the security industry needs to admit that trust-as-a-service models deserve more scrutiny than they currently receive.