Ransomware groups exploit PAN-OS bypass; Meta notifies about 1,500 people

The PAN-OS issue is an authentication bypass affecting GlobalProtect and Prisma Access. It was disclosed in May 2026 and has since come under active exploitation. The exploitation is not limited to researchers: two named ransomware groups are using it.

The second item is a source code platform intrusion. Unknown threat actors broke into some of Meta's GitHub repositories. Meta is notifying about 1,500 people, and most of them are its own employees in the U.S.

For the PAN-OS flaw, the quoted reporting describes it as an authentication bypass in two remote access products. That class of bug lets a request reach functionality that should sit behind a login. The gap between disclosure in May 2026 and current exploitation is the part worth noting: the window between a public advisory and ransomware use is short enough that patch scheduling is the real control.

For the Meta case, the available detail is that unknown threat actors broke into some of the company's GitHub repositories. The method is not stated in the quoted lines, so we are not going to guess at it. What is stated is the scope of notification, which points at people whose data was reachable from those repositories.

Two short checks, one for edge access and one for source control.

1. 01

   Inventory every PAN-OS gateway you run

   Pull the device list from Panorama or your asset inventory and record the software version of each firewall running GlobalProtect, plus every Prisma Access tenant. Cross-check that list against what is reachable from the internet using your external scan data or a simple sweep of tcp/443 on your public ranges. A gateway that nobody owns or that is missing from the inventory is the bad result.

2. 02

   Confirm the fixed version is deployed, not just scheduled

   Compare the running version on each device against the vendor advisory for CVE-2026-0257 rather than trusting a change ticket. Export the version field from the management console and diff it against the fixed release list. Anything still on an affected build, including standby units and lab gateways with public addresses, counts as unpatched.

3. 03

   Review gateway authentication logs back to the disclosure date

   Query your SIEM for GlobalProtect authentication and session events going back to May 2026, not just the last week. Look for sessions without a matching successful authentication event, logins from unusual source ranges, and new or unexpected local administrator accounts. Gaps in log retention are themselves a finding to write down.

4. 04

   Test what an attacker reaches after the gateway

   Map the network ranges and internal services a VPN session can touch, then verify segmentation rules in the firewall policy rather than in the design document. Check that domain controllers, backup servers and hypervisor management interfaces are not reachable from the remote access pool. Flat reachability from a gateway subnet is the result to fix first.

5. 05

   List everything that can read your private repositories

   In your source control settings, export the list of members, outside collaborators, machine accounts, personal access tokens, deploy keys and installed apps, with their scopes. Flag any token with broad read access, no expiry, or no named owner. Unused integrations that still hold organisation-wide read are the ones to revoke.

6. 06

   Search repository history for personal data and secrets

   Run a secret scanner and a keyword search across full git history, including deleted files and old branches, for employee identifiers, email lists, HR exports and credentials. Use git log and git rev-list to reach content that is no longer in the working tree. Anything found means a repository break-in becomes a people notification problem as well as a code problem.