Palo Alto Networks published advisory CVE-2026-0257, "GlobalProtect Authentication Bypass Vulnerabilities," for an authentication bypass in the GlobalProtect portal and gateway of PAN-OS. NVD rates it CVSS 9.1 with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N and classifies it CWE-565; Palo Alto's own score is lower, CVSS 7.8 on the v4.0 scale. CISA added the CVE to the Known Exploited Vulnerabilities catalog on May 29 with a remediation due date of June 1 — three days. The advisory states the reason plainly: "Palo Alto Networks has become aware of limited exploit attempts on unpatched PAN-OS devices."

The flaw lets an unauthenticated remote attacker "bypass security restrictions and establish an unauthorized VPN connection," per NVD. CWE-565 — "Reliance on Cookies without Validation and Integrity Checking" — names the mechanism: the weakness is in how GlobalProtect trusts authentication-override cookies. That detail also scopes the blast radius. A firewall is exposed only when its GlobalProtect portal or gateway has "Generate cookie for authentication override" or "Accept cookie for authentication override" enabled. If neither option is on, this specific bypass does not apply to that firewall.

That scoping is the difference between a quiet patch cycle and an emergency. Authentication-override cookies are a convenience feature — they let a user skip re-authentication on the portal after the gateway has already authenticated them — and plenty of GlobalProtect deployments never turn them on. But the ones that do are now reachable by anyone who can connect to the HTTPS service, and exploitation is already happening.

What to do this week:

1. Inventory every GlobalProtect-enabled firewall and check the override setting. For each managed PAN-OS firewall running a GlobalProtect portal or gateway, check whether Generate cookie for authentication override or Accept cookie for authentication override is enabled (Network > GlobalProtect > Portals / Gateways > Authentication). A firewall with the option enabled and a reachable GlobalProtect interface is the exploitable case — treat it as patch-now.

2. Patch to a fixed release on your branch. Per Palo Alto's fixed-software table, PAN-OS 10.2, 11.1, 11.2, and 12.1 all have fixed builds — representative fixes include 10.2.18-h6, 11.1.15, 11.2.12, and 12.1.7, with multiple hotfix builds listed per branch. Match the fix to the maintenance release each firewall is already on rather than jumping trains under pressure.

3. If you cannot patch immediately, apply the workaround. Palo Alto's supported mitigation is to disable the authentication-override options, or "generate a new certificate exclusively for authentication override cookies." Disabling the override is the faster lever; it costs users a re-authentication prompt, not access.

4. Hunt for unauthorized VPN sessions before and after you patch. A successful bypass produces a GlobalProtect session that never passed real authentication. Review GlobalProtect gateway logs for sessions from unexpected source geographies, sign-ins without a matching authentication event, and accounts connecting from new device fingerprints. Patching closes the door; it does not evict an attacker already inside.

5. If you find evidence of unauthorized access, treat it as a breach. Rotate credentials for any account that holds a suspect session, review what internal resources the VPN scope reaches, and check for follow-on persistence. An unauthorized VPN connection is an internal-network foothold, not just a login.

This is the third edge-appliance authentication bypass to lead ENKVA in the past month, after the Cisco Catalyst SD-WAN auth bypass in issue #006 and the cPanel WHM auth bypass in issue #004. The pattern holds: internet-reachable management and remote-access planes are where the active exploitation is. Confirm your GlobalProtect estate is patched, then keep walking the rest of the edge inventory.

Advisories

Two developer-tooling supply-chain compromises hit KEV with ransomware flags set

CISA added two software supply-chain CVEs to the KEV catalog on May 27, both with a June 10 due date and both flagged knownRansomwareCampaignUse: Known. CVE-2026-48027 is a compromised build of the Nx Console VS Code/Cursor extension: malicious version 18.95.0 was live on the Microsoft Marketplace for roughly 18 minutes (12:30–12:48 UTC) and on OpenVSX for roughly 36 minutes (12:33–13:09 UTC), drawing about 6,000 extension activations, and the patched build is 18.100.0. The payload harvested Vault tokens, npm .npmrc tokens, AWS metadata and Secrets Manager credentials, GitHub ghp_/gho_/ghs_ tokens, 1Password CLI vault contents, and SSH private keys. CVE-2026-45321 is the parallel npm compromise — "Malware in 42 @tanstack/ packages exfiltrates cloud credentials, GitHub tokens, and SSH keys," with malicious versions 1.169.5 and 1.169.8 published in a six-minute window on May 11*.

Action: if your team or your clients run VS Code, Cursor, or any CI/CD that installs @tanstack/* router packages, check for the malicious versions and roll forward (Nx Console 18.100.0; the patched TanStack builds such as @tanstack/react-router 1.169.9). Then rotate every credential reachable from a developer workstation or build runner — npm tokens, GitHub PATs, cloud keys, SSH keys. Both flaws steal long-lived secrets; the package fix does not undo the theft.

Chrome 148 stable ships 151 security fixes — Edge inherits the Chromium CVEs

Google shipped Chrome Stable 148.0.7778.216/217 for Windows (148.0.7778.215/216 for Mac, 148.0.7778.215 for Linux) on May 27. Per the release post, "This update includes 151 security fixes." Microsoft Edge is built on the same Chromium base and inherits the bulk of these CVEs on its own release cadence, typically within days.

Action: confirm managed browsers are updating. For Chrome fleets, check that your update policy (UpdaterAutomaticUpdates / relaunch enforcement) is pulling 148.0.7778.216 or newer; for Edge, watch for the matching Stable build and push a managed relaunch rather than waiting for users to restart. Browser CVEs of this volume are routine, but an unpatched browser is a soft drive-by target on an otherwise managed endpoint.

KEV also added Oracle WebLogic, a Linux cgroups escape, and an Android Framework bug

The same KEV window picked up three more entries worth a scan of your estate. CVE-2024-21182 in Oracle WebLogic Server (added June 1, due June 4) lets an unauthenticated attacker compromise the server over T3/IIOP. CVE-2022-0492 in the Linux Kernel (added June 2, due June 5) is the cgroups v1 release_agent privilege-escalation path — a well-known container-escape primitive. CVE-2025-48595 in the Android Framework (added June 2, due June 5) is an integer overflow enabling local privilege escalation.

Action: the Linux cgroups bug is the one most likely to be live in an MSP estate, via container hosts. Confirm your container runtimes block release_agent writes (modern Docker/containerd defaults and a non-root, no-CAP_SYS_ADMIN posture close it). For WebLogic, the July 2024 Oracle CPU carries the fix; for Android, the June 2026 security patch level. None of these is the week's headline, but KEV due dates are compliance obligations for anyone scoped to BOD 22-01.

Product changes

Defender XDR adds local AI-agent discovery and runtime protection on Windows endpoints

The June 2026 Defender XDR What's new entries add two preview capabilities aimed at the AI tooling now running on developer and analyst machines. Local AI agent discovery automatically finds supported local AI agents on onboarded Windows devices — "coding agents and IDE extensions, desktop AI assistants, local AI runtimes, and agent platforms" — and surfaces them in the AI agent inventory, exposure map, and advanced hunting. Local AI agent runtime protection inspects "the agent loop (user prompts, tool calls, and tool responses) and can block risky activity before it executes," targeting prompt injection and unsafe agent actions at the device level. The CloudAuditEvents and CloudDnsEvents hunting tables also reached GA.

Action: if your clients' developers run local coding agents or IDE AI extensions — exactly the attack surface the Nx Console compromise above abused — turn on local AI agent discovery in preview to get an inventory before you decide on policy. The two features are preview-gated; pilot them on an internal device group first, then scope runtime protection to teams with the highest local-agent usage.

Entra GA wave: passkey registration campaigns and first-factor system-preferred auth

The May 2026 Entra What's new GA wave moves two phishing-resistance levers to general availability. Passkeys (FIDO2) in the registration campaign are now GA, so you can nudge users into passkey enrollment at scale through the same prompt flow used for authenticator registration. System-preferred authentication expanded to first-factor is also GA — in Microsoft-managed configurations, users holding phishing-resistant credentials can sign in without a password as the first factor. A changed-feature note bumps the passkey policy storage to a dedicated 20-KB allocation and raises the maximum passkey profiles per tenant from 3 to 10.

Action: for tenants you are moving toward passwordless, turn on the passkey registration campaign now that it is GA — it is the lowest-friction path to enrollment. Review the first-factor system-preferred change before it surprises users: in Microsoft-managed config, the sign-in experience shifts for anyone with a registered passkey. Communicate the change to client help desks so the "where did my password prompt go" tickets do not pile up.

Intune RBAC roles now inherit Copilot in Intune access automatically

The week of May 26, the Intune What's new page documents a change to how Copilot access is granted. When Intune is enabled as a data source in Security Copilot, the Entra ID Intune Administrator role automatically inherits Security Copilot owner access to Copilot in Intune, and all other built-in and custom Intune RBAC roles automatically inherit Security Copilot contributor access. Previously, Copilot in Intune required a separate role assignment in Security Copilot.

Action: this removes onboarding friction, but it also means anyone with an Intune RBAC role gains Copilot access the moment you enable the Intune data source in Security Copilot — without a second, deliberate grant. Before you flip that data source on for a client tenant, confirm your Intune role assignments are scoped the way you want, because they now double as Copilot access grants.

Field notes

Microsoft details the "Miasma" npm worm in Red Hat's package scope

Microsoft published an analysis on June 2 of a self-propagating credential-stealing campaign it calls Miasma, which compromised "32 maliciously modified packages across more than 90 versions" under the @redhat-cloud-services npm scope. The malware ran via an npm preinstall hook that executed "a heavily obfuscated 4.29 MB dropper script," stealing GitHub, npm, AWS, Azure, GCP, HashiCorp Vault, and Kubernetes credentials plus SSH keys and browser/wallet data, and — in CI/CD — scraping GitHub Actions runner memory and escalating "using passwordless sudo." It then republished poisoned packages "with forged Supply-chain Levels for Software Artifacts (SLSA) provenance" and self-spread, leaving repositories tagged with the description "Miasma: The Spreading Blight."

Action: this is the same playbook as last week's @antv mini Shai-Hulud compromise — preinstall/postinstall hook, runner-memory credential theft, worm-like republication. Run npm install with --ignore-scripts in CI by default, pin known-good versions of any @redhat-cloud-services dependency, and rotate npm tokens, CI/CD secrets, and cloud credentials that touched a build in the exposure window. Audit for repositories carrying the "Miasma: The Spreading Blight" description as an indicator of a compromised account.

Microsoft flags malicious npm packages using dependency confusion for recon

Separately, Microsoft reported on May 30 on a batch of malicious npm packages spread across nine organizational scopes that abuse dependency confusion to profile developer environments. Unlike the credential-stealers above, this campaign runs a postinstall.js hook that "operates in 'reconnaissance-only' mode, collecting system information, hostnames, environment variables, and developer context" — fingerprinting machines rather than stealing credentials outright.

Action: dependency confusion works when an internal package name resolves to a public registry copy. Scope-lock your .npmrc so internal scopes always pull from your private registry, and run npm install --ignore-scripts to neuter postinstall hooks — the same control that blunts the Miasma and TanStack droppers. For clients with internal package registries, confirm the registry precedence is configured per project, not just per developer machine.