Okta

PKCE Becomes Mandatory for OAuth Public Clients as RFC 9700 and OAuth 2.1 Close Authorization Code Interception Risks

PKCE, or Proof Key for Code Exchange, was introduced in RFC 7636 to prevent code interception attacks in OAuth 2.0 flows used by mobile and single-page applications. The mechanism generates a code_verifier and derives a code_challenge using S256 hashing to bind the authorization code to the original client session. Without PKCE, malicious apps on the same device can hijack custom URI schemes like myapp://callback and exchange stolen codes for access tokens. RFC 9700, published in January 2025, now mandates PKCE for public clients and recommends it for confidential ones while requiring S256 over the weaker plain method. The upcoming OAuth 2.1 draft further embeds PKCE into the core authorization code flow and removes implicit and resource owner password credentials grants. Major providers including Auth0, Okta, and Microsoft Entra ID show varying default support, highlighting the need for explicit S256 implementation. The standard also protects against code injection attacks even when client secrets are present.

Cordial Spider Deploys Work Panel Platform for Tech Support Scams Against Corporate Identities

A criminal platform called Work Panel is turning fake technical support calls into structured operations aimed at taking over corporate accounts. The service combines target research, page cloning, telephony, and credential capture within a single control panel. It is linked to the group tracked as O-UNC-045, also known as Cordial Spider. Campaigns target users of multiple identity providers and combine telephone social engineering with fake authentication pages. Operators research names, job titles, corporate emails, phone numbers, and professional profiles before calling to impersonate help-desk staff. While one operator keeps the victim on the line, a manager monitors the phishing session in real time. Captured credentials are sent only to operation managers via Telegram, reducing internal theft risks among the criminals themselves.

OpenSSL Patches HollowByte Vulnerability That Enables Denial-of-Service Attacks on TLS Connections with Just 11 Bytes

OpenSSL has released fixes for a vulnerability dubbed HollowByte that allows denial-of-service attacks against servers using unpatched versions of the library. The flaw can be triggered by a malicious TLS request as small as 11 bytes and was addressed without a CVE or formal security advisory because it was classified as a hardening improvement. Researchers from Okta warn that the operational impact can be significant on internet-facing servers, as the issue occurs during the initial TLS handshake when vulnerable OpenSSL versions reserve memory based on the client-declared size before verifying actual data delivery. Attackers can open connections, claim they will send a large message, and then deliver only a tiny portion, leaving the server waiting indefinitely with reserved memory. In tests with NGINX, low-memory servers could be completely taken down while more powerful machines suffered substantial capacity loss without triggering abnormal traffic volumes. The patches are included in OpenSSL versions 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21, and administrators are advised to update packages, restart affected services, and monitor for unusual memory growth.