PKCE Becomes Mandatory for OAuth Public Clients as RFC 9700 and OAuth 2.1 Close Authorization Code Interception Risks
The OAuth authorization code grant was designed to avoid exposing user passwords to applications by issuing short-lived codes instead of tokens directly. However, public clients such as native mobile apps and single-page applications cannot securely store a client_secret, leaving intercepted codes vulnerable to exchange for tokens.
PKCE (Proof Key for Code Exchange), defined in RFC 7636, solves this by requiring the client to generate a high-entropy code_verifier (43–128 characters) and send its SHA-256 hash as code_challenge during the initial authorization request. The authorization server stores the challenge and later verifies it against the verifier supplied at the token endpoint.
Why mobile apps cannot rely on client secrets
Server-side applications keep secrets in environment variables, but native Android or iOS apps can be decompiled and browser-based applications expose all source code. Even protected storage like iOS Keychain or Android Keystore can be bypassed on jailbroken or rooted devices, making any embedded secret effectively public.
The attack PKCE was created to stop
Multiple applications can register the same custom URI scheme such as myapp://callback. When the authorization server redirects the code, the operating system may deliver it to a malicious app that quietly declared the same scheme in its manifest. RFC 7636 notes that such code interception attacks have been observed in the wild.
How PKCE works in practice
The client creates a code_verifier using a cryptographically secure random generator, computes the code_challenge as BASE64URL(SHA256(verifier)), and includes it with code_challenge_method=S256. At token exchange the original verifier is sent over a secure channel; the server recomputes the hash and rejects any mismatch with an invalid_grant error.
The plain method offers only limited protection and is deprecated in favor of S256, which is mandatory to implement on servers. Omitting the method parameter defaults to plain, silently weakening security.
Three distinct threats often confused
- Code interception: malicious app steals the real user code via URI scheme collision.
- Code injection: attacker supplies its own code to bind a victim session to the attacker account; PKCE blocks this even for confidential clients.
- Downgrade: server accepts requests without a challenge, disabling verification entirely.
PKCE does not replace other safeguards
The state parameter still protects against CSRF, and nonce in OpenID Connect ensures ID token freshness. RFC 9700 allows relying on PKCE for CSRF protection only after confirming server support. PKCE also does not protect issued access tokens; sender-constrained mechanisms such as DPoP (RFC 9449) or mutual TLS (RFC 8705) address that layer.
Current status in 2025–2026
RFC 9700 (BCP) already requires PKCE for public clients and recommends it for confidential clients. The OAuth 2.1 draft (draft-ietf-oauth-v2-1-15) integrates PKCE into the core flow and removes implicit and ROPC grants. Providers differ in defaults: Auth0 and Okta enforce S256, while Microsoft Entra ID still documents both methods.
Even AI agent authorization frameworks such as the Model Context Protocol are adopting OAuth 2.1 with PKCE for HTTP transports where static secrets are impractical.
Related articles
Attackers Chain JFrog Artifactory CVEs for Rapid Admin Takeover and Backdoor Deployment
Real-world attacks against self-hosted JFrog Artifactory have chained multiple CVEs to escalate from unauthenticated requests to full administrative control. Attackers achieved persistence by installing malicious Groovy plugins, executing shell commands, and deploying Rust-based backdoors within minutes. The primary chain relies on CVE-2026-42018 and CVE-2026-42016, allowing anonymous token acquisition and privilege escalation without proper scope validation. A separate critical flaw, CVE-2026-82329 with CVSS 9.8, enables direct authentication bypass and admin token creation on default configurations. Patches are available across multiple 7.x branches, and defenders are urged to audit logs for anonymous admin actions and inspect for unauthorized plugins and binaries. The incidents highlight risks to software supply chains when artifact repositories are compromised.
Check Point Patches Two Critical VPN Vulnerabilities Allowing Unauthenticated Remote Code Execution
Check Point has released fixes for two critical vulnerabilities affecting its Security Gateway, Security Management Server, and locally managed Spark Firewall products. Both flaws received a CVSS score of 9.8 and enable remote code execution without requiring authentication. CVE-2026-85102 resides in certificate trust validation during VPN negotiation, allowing an unauthenticated attacker to force the process and execute arbitrary code. CVE-2026-85103 is a heap buffer overflow triggered while parsing the ASN.1 structure of VPN certificates. Affected versions include R81.20, R82, and R82.10 before the listed hotfixes, as well as unsupported R80.40 and R81 releases. R82.20 remains unaffected. The issues were discovered internally by Check Point researchers, with no active exploitation or public proof-of-concept observed as of the September 10 disclosure.
Positive Technologies Acquires Stake in CyberOK to Advance EASM and PentOps Technologies
Positive Technologies has acquired a stake in cybersecurity developer CyberOK, with the size of the investment and deal terms remaining undisclosed. The partnership will focus on developing External Attack Surface Management (EASM) solutions and PentOps technologies that identify overlooked external assets and validate whether attackers can exploit them. Collaboration between the companies began in 2026, with CyberOK technologies already integrated into PT EASM and the PT X cloud platform. In less than six months, pilot projects for PT EASM exceeded 70, and Positive Technologies expects 80 percent of successful trials to convert into deals by late 2026 or early 2027. The Russian EASM market is projected at 2-2.5 billion rubles by the end of 2026, potentially reaching 8 billion rubles by 2031 when combined with continuous security validation solutions. PentOps will provide continuous cloud-based penetration testing that automatically verifies exploitability of discovered issues, moving beyond simple vulnerability lists. In 96 percent of pilots, unaccounted IT assets with critical vulnerabilities were identified, and CyberOK continues to develop the Vulnum knowledge base along with AI agents and Offensive SOC capabilities.
Exploiting CVE-2025-55182 React2Shell Vulnerability on Hack The Box Reactor Machine
A detailed walkthrough demonstrates remote code execution against a seasonal Hack The Box machine named Reactor by abusing the critical Next.js deserialization flaw CVE-2025-55182, also known as React2Shell. The attack begins with Nmap reconnaissance revealing an exposed Next.js service on port 3000, followed by Wappalyzer identification of an outdated framework version. Public exploit code is used to obtain an initial reverse shell as the node user without authentication. Credential access is achieved by extracting password hashes from the reactor.db SQLite database and cracking the engineer account with Hashcat against rockyou.txt. Privilege escalation leverages an exposed Node.js Inspector debug port on 9229, allowing WebSocket interaction via websocat to set the SUID bit on /bin/bash and obtain root access. The article highlights both the impact of the unauthenticated RCE vulnerability and common misconfigurations such as forgotten debug ports on production systems.