A poisoned VS Code extension gave attackers read access to 3,800 internal GitHub repositories. The same week, Verizon’s 2026 DBIR confirmed what defenders have felt for two years: exploiting unpatched vulnerabilities is now how most breaches start. Today’s newsletter covers the GitHub supply-chain compromise, the DBIR’s historic shift in initial access vectors, a critical unauthenticated RCE in PAN-OS DNS proxy (CVE-2026-0264), and Microsoft’s full writeup of the Storm-2949 identity abuse campaign.

In the News

GitHub Confirms 3,800 Internal Repos Breached via Malicious VS Code Extension

GitHub disclosed that a trojanized Visual Studio Code extension compromised approximately 3,800 internal repositories after an employee installed it. The attack is attributed to TeamPCP, the same threat group responsible for last week’s npm supply-chain campaign. The malicious extension operated as a credential harvester — once installed, it exfiltrated repository access tokens and developer credentials, granting the group broad read access to private codebases.

The attack surface here is the IDE extension marketplace itself. VS Code’s extension model grants plugins deep access to the development environment: file system reads, terminal execution, and credential store access. TeamPCP’s approach bypassed traditional network-layer controls entirely. The extension passed marketplace review and appeared legitimate until post-installation behavioral analysis flagged the credential exfiltration.

This validates a supply-chain attack vector that has been theoretical for most organizations. If GitHub — an organization with mature security operations and deep familiarity with software supply-chain risk — can be compromised through a developer tool plugin, the assumption that “our developers know better” is not a control. It is a hope.

What defenders should do: Implement extension allowlisting for VS Code and other IDEs at the organizational level. Deploy endpoint detection on developer workstations with behavioral rules that flag credential store access by IDE extensions. Treat developer environments as high-value targets in your threat model — they have direct access to source code, secrets, and CI/CD pipelines. [MITRE ATT&CK: T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain]

Source: BleepingComputer

Verizon DBIR 2026: Vulnerability Exploitation Overtakes Credentials as Top Breach Vector

The 2026 Verizon Data Breach Investigations Report documents a fundamental shift in attacker behavior. Exploitation of software vulnerabilities accounted for 31% of confirmed breaches, overtaking stolen credentials as the primary initial access method for the first time in the report’s 19-year history. The report attributes this to two converging trends: faster weaponization of disclosed CVEs (median time from disclosure to first exploitation continues to compress) and persistent patch lag across enterprises that still measure remediation in months.

This is not a subtle trend line. For over a decade, credential theft — phishing, credential stuffing, password reuse — dominated the DBIR’s initial access findings. That dominance shaped how organizations allocated security budgets: identity and access management, MFA rollouts, phishing awareness training. Those investments remain essential. But the DBIR data now says that an attacker is more likely to walk in through an unpatched vulnerability than through a stolen password.

The implication for defenders is that exposure management and patch orchestration are no longer secondary controls behind identity security. They are co-primary. Virtual patching via IPS signatures on NGFWs and WAFs provides the compensating control that buys time between CVE disclosure and patch deployment — but only if signature updates are applied on the same timeline as the exploits being written.

What defenders should do: Benchmark your mean time to remediate (MTTR) against the DBIR’s median exploitation timeline. If your patch cadence is monthly, you are leaving a window that attackers are now statistically more likely to exploit than any other vector. Deploy vulnerability prioritization tools that score by real-world exploitability, not just CVSS base score. Enable virtual patching (IPS signatures, WAF rules) as a bridging control for internet-facing assets. [MITRE ATT&CK: T1190 — Exploit Public-Facing Application]

Source: SecurityWeek

PAN-OS DNS Proxy Flaw Enables Unauthenticated Remote Code Execution (CVE-2026-0264)

Palo Alto Networks published a security advisory for CVE-2026-0264, a heap-based buffer overflow in the PAN-OS DNS proxy and server component. The vulnerability allows unauthenticated remote code execution — an attacker who can send specially crafted DNS packets to an affected firewall achieves full system compromise with no credentials required. No exploitation has been observed in the wild as of the advisory date.

The attack surface is significant. Firewalls running with DNS proxy enabled accept DNS queries from clients and forward them to upstream resolvers. This is a network-facing service that is reachable without authentication by design. A heap overflow in this code path means that any device on the network (or on the internet, if DNS proxy is exposed) can potentially trigger the vulnerability. DNS-layer exploits against network appliances are uncommon, which means many organizations may not have detection signatures ready for this class of attack.

Palo Alto has released patches. Organizations running PAN-OS with DNS proxy or DNS server functionality enabled should patch immediately. As a compensating control, disable the DNS proxy feature on firewalls where it is not operationally required.

What defenders should do: Identify all PAN-OS devices with DNS proxy or DNS server enabled. Patch to the fixed version per the advisory. If patching requires a maintenance window, disable DNS proxy as an interim measure. Deploy IPS signatures for DNS heap overflow patterns on inline security devices. [MITRE ATT&CK: T1190 — Exploit Public-Facing Application]

Source: Palo Alto Security Advisories

Storm-2949 Turned One Compromised Identity into Cloud-Wide Data Exfiltration

Microsoft published the full attack-chain analysis of Storm-2949, a campaign first reported last week that weaponized Self-Service Password Reset (SSPR) to escalate a single compromised identity into cloud-wide data exfiltration across M365 and Azure. The updated report includes ScreenConnect post-compromise activity and detailed indicators of compromise.

The attack chain is notable for what it did not use: no malware, no exploits, no custom tooling. Storm-2949 compromised an initial identity (the vector for the initial compromise was not disclosed in the report), then abused the SSPR flow — which did not require step-up authentication — to reset passwords for additional accounts. From there, the group accessed SharePoint, Exchange Online, and Azure storage using only legitimate features. Post-compromise persistence was maintained through ScreenConnect remote access, which blended with legitimate remote support traffic.

This is a pure identity-layer attack. Every action Storm-2949 took was a legitimate feature used for an illegitimate purpose. Conditional access policies that require phishing-resistant MFA for password reset operations would have broken the chain at the escalation step.

What defenders should do: Enforce phishing-resistant MFA (FIDO2, certificate-based) on all password reset flows, not just primary authentication. Review conditional access policies to ensure SSPR triggers step-up authentication. Monitor for anomalous password reset volumes from single source identities. Flag ScreenConnect installations on endpoints that do not have approved remote support use cases. [MITRE ATT&CK: T1078.004 — Valid Accounts: Cloud Accounts, T1098 — Account Manipulation]

Source: Microsoft Security Blog

Today’s Deep Dive — Supply-Chain Attacks Through Developer Tools

The GitHub breach via a malicious VS Code extension is the latest in an accelerating pattern: threat actors targeting the software supply chain not at the build or deployment stage, but at the developer’s workstation. TeamPCP’s campaign — spanning both npm packages and now IDE extensions — demonstrates a group that understands developer workflows deeply enough to insert malicious code at the earliest possible point in the software lifecycle.

The Mechanism

VS Code extensions run with the same permissions as VS Code itself, which on most developer machines means full user-level access to the file system, terminal, network, and credential stores. The extension marketplace’s review process, while improved over the years, cannot catch every behavioral payload — particularly those that activate conditionally or exfiltrate data slowly to blend with legitimate telemetry. TeamPCP’s extension reportedly harvested GitHub tokens from the local credential store (a standard VS Code feature for GitHub integration) and exfiltrated them to attacker-controlled infrastructure.

This is not a new attack class. In 2021, researchers demonstrated that typosquatted VS Code extensions could achieve code execution on developer machines. In 2023, multiple malicious extensions were discovered exfiltrating SSH keys. What makes the TeamPCP campaign different is the operational maturity: the group combined npm supply-chain poisoning (T1195.002) with IDE extension compromise in a coordinated campaign targeting both the package ecosystem and the development environment.

Detection

The primary detection signal for malicious IDE extensions is behavioral: credential store access patterns that do not match the extension’s declared purpose, unexpected network connections from IDE processes, and file system reads targeting .ssh, .aws, .git-credentials, and similar sensitive paths. On Windows, Sysmon Event ID 1 (process creation) and Event ID 3 (network connections) from code.exe child processes are high-value telemetry. On macOS and Linux, equivalent auditd or Endpoint Security Framework events apply.

For organizations using Splunk:

index=sysmon EventCode=3
| where process_name="code.exe" OR process_name="code"
| where NOT (dest_ip IN ("github.com","*.github.com","marketplace.visualstudio.com","*.vscode-cdn.net"))
| stats count by dest_ip, dest_port, user, process_name
| where count > 5
| sort -count

This query surfaces VS Code processes making network connections to destinations outside expected Microsoft and GitHub infrastructure. False positives will include legitimate extensions that reach external APIs — the key is baselining your environment’s expected extension traffic and investigating outliers.

Primary Mitigations

  1. Extension allowlisting — Maintain an organizational allowlist of approved VS Code extensions. Distribute via VS Code settings sync or configuration management. Block installation of extensions not on the list.
  2. EDR on developer workstations — Deploy endpoint detection with behavioral rules for credential store access by IDE processes. Developer machines are not exempt from endpoint security.
  3. Token scoping and rotation — GitHub personal access tokens and OAuth tokens should use minimum required scopes. Rotate tokens on a schedule and audit token usage for anomalous repository access patterns.
  4. Network segmentation for developer environments — Developer workstations should not have unrestricted outbound access. Proxy all traffic and flag connections to infrastructure outside known-good destinations.

[MITRE ATT&CK: T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain, T1555 — Credentials from Password Stores, T1041 — Exfiltration Over C2 Channel]

Detection Spotlight

Storm-2949 SSPR Abuse Detection — Azure AD Sign-In Logs

Storm-2949’s abuse of Self-Service Password Reset leaves traces in Azure AD sign-in and audit logs. The following KQL query identifies anomalous password reset activity — multiple resets initiated by a single identity within a short window, which is the core escalation pattern in this campaign:

AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName == "Reset password (self-service)"
| extend InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)
| summarize ResetCount = count(), TargetAccounts = make_set(TargetResources[0].userPrincipalName) by InitiatedBy, bin(TimeGenerated, 1h)
| where ResetCount > 3
| project TimeGenerated, InitiatedBy, ResetCount, TargetAccounts

This surfaces any identity that triggered more than three self-service password resets within a one-hour window. In legitimate operations, a single user resets their own password once. An identity resetting multiple accounts — or resetting the same account repeatedly — is a high-fidelity indicator of SSPR abuse. False positive rate is low in environments where SSPR is scoped to self-service (users reset only their own passwords); adjust the threshold for help desk accounts that perform delegated resets.

Pair this with a second query monitoring for ScreenConnect process creation on endpoints that do not have approved remote support tools:

DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where FileName has_any ("ScreenConnect.ClientService.exe", "ScreenConnect.WindowsClient.exe")
| where DeviceName !in ("approved-support-device-1", "approved-support-device-2")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine

References

Subscribe to the it-learn Brief

Get the daily cybersecurity brief in your inbox every weekday morning — news, SE angles, and detection queries.