One compression library flaw forces four runtime ecosystems into a simultaneous patching sprint. That alone would make today’s brief worth reading. But the Gheist campaign turning GitHub Actions logs into a secret-exfiltration channel and a three-month AitM relay operation replaying M365 tokens across 79 organizations make it clear: the attack surface is expanding faster than most patch cycles can keep up.

In the News

Brotli Decoder RCE Forces Patching Across Node.js, .NET, PowerShell, and Python

Google’s Brotli compression library is one of those invisible dependencies - embedded so deeply into major runtimes that most teams do not realize they ship it. An out-of-bounds write in the Brotli decoder now gives attackers remote code execution via crafted compressed payloads. The flaw, dubbed Node2Shell, affects Node.js, .NET, PowerShell, and Python packages simultaneously.

The blast radius is significant because Brotli decompression happens automatically in web servers, API gateways, and automation scripts. Any application that accepts user-supplied Brotli-compressed content - which includes most modern HTTP stacks - is a potential target. Patches are rolling across all four ecosystems, but the coordination challenge is the real problem: most organizations do not have a single team responsible for all four runtimes.

This is a software composition analysis problem. Organizations that maintain a software bill of materials (SBOM) across their environments can query for the affected Brotli versions immediately. Organizations that do not are running grep and hoping.

What defenders should do: Inventory every application and automation pipeline for Brotli library versions. Prioritize patching internet-facing services that accept compressed input. Deploy IPS signatures to inspect malformed Brotli payloads at the perimeter as a compensating control while patching proceeds.

Gheist Campaign Weaponizes GitHub Actions Logs to Steal Private Repo Secrets

The Gheist campaign demonstrates a CI/CD attack pattern that is elegant in its simplicity. Attackers obtain stolen GitHub personal access tokens - likely from prior credential compromises or leaked .env files - and use them to inject malicious workflow files into private repositories. The planted workflows execute legitimate GitHub Actions commands that dump repository secrets, environment variables, and cloud credentials to the workflow’s own log output.

The attacker then downloads the logs, extracts the credentials, and deletes the workflow file and its run history. By the time a developer checks the repository, the malicious workflow is gone. GitHub Enterprise environments are confirmed targets, which means this is not limited to open-source projects.

The root cause is token scope. Personal access tokens with repo and workflow permissions give an attacker everything they need to inject, execute, and clean up. Organizations that do not enforce least-privilege token scoping, mandatory token expiration, and workflow change monitoring have no detection surface for this attack.

What defenders should do: Audit all active GitHub personal access tokens for excessive scope. Enable branch protection rules that require review for workflow file changes. Ingest GitHub audit logs into a SIEM and alert on workflow file creation in private repositories. Rotate any token that predates your current scoping policy. MITRE ATT&CK: T1528 - Steal Application Access Token.

M365 AitM Relay Campaign - 497 Token Replays Across 79 Organizations

Between July and September 2026, an adversary-in-the-middle relay campaign compromised 97 Microsoft 365 accounts spanning 79 organizations. The attack produced 497 successful sign-ins from attacker-controlled infrastructure - all against accounts with MFA enabled.

The mechanism is straightforward: the attacker operates a reverse proxy that sits between the victim and Microsoft’s login page. The user authenticates normally, including completing their MFA challenge. The proxy captures the resulting session token and replays it from a separate machine. From Microsoft’s perspective, the token is valid - MFA was satisfied at issuance.

This is the operational reality that makes “we have MFA” an insufficient answer. MFA protects the authentication ceremony. It does not protect the session token that results from it. Conditional access policies that enforce device compliance, continuous access evaluation (CAE) that revoke tokens on risk signal changes, and reduced session lifetimes are the controls that close this gap. Phishing-resistant MFA methods like FIDO2 prevent the relay entirely because the authentication is bound to the legitimate domain origin.

What defenders should do: Enable continuous access evaluation in Microsoft 365. Enforce conditional access policies requiring compliant or hybrid-joined devices. Reduce session token lifetimes to the shortest operationally acceptable window. Deploy phishing-resistant MFA (FIDO2) for high-value accounts. Monitor Azure AD sign-in logs for concurrent sessions from geographically impossible IP pairs. MITRE ATT&CK: T1557 - Adversary-in-the-Middle, T1550.001 - Use Alternate Authentication Material: Application Access Token.

Defender Action Items

  • Brotli patching: Inventory Node.js, .NET, PowerShell, and Python environments for embedded Brotli library versions. Patch internet-facing services first. Deploy IPS rules for malformed Brotli payloads as a compensating control.
  • GitHub token audit: Review all active personal access tokens for repo + workflow scope. Enforce expiration policies. Enable branch protection requiring review for .github/workflows/ changes. Alert on workflow file creation in private repos via audit log monitoring.
  • M365 token replay defense: Enable continuous access evaluation. Enforce device-compliant conditional access. Reduce session token lifetimes. Deploy FIDO2 for privileged and high-value accounts. Alert on concurrent sign-ins from mismatched geolocations.
  • Palo Alto CVE-2026-109618: Check Palo Alto security advisory for affected PAN-OS, Panorama, and Cortex versions. Apply hotfixes - exploitation is confirmed in the wild.

Detection Queries

Azure AD sign-in log query for concurrent M365 sessions from mismatched IPs - a high-fidelity indicator of token replay:

1SigninLogs
2| where TimeGenerated > ago(24h)
3| where ResultType == 0
4| summarize IPCount = dcount(IPAddress), IPs = make_set(IPAddress), SignInCount = count() by UserPrincipalName, bin(TimeGenerated, 10m)
5| where IPCount > 1
6| extend GeoCheck = "Review for impossible travel or proxy relay"
7| project TimeGenerated, UserPrincipalName, IPCount, IPs, SignInCount, GeoCheck
8| order by IPCount desc

GitHub audit log query (Splunk SPL) for unexpected workflow file creation in private repositories:

index=github_audit sourcetype="github:audit"
action="workflows.created_workflow_run" OR action="workflows.completed_workflow_run"
repo_visibility="private"
| stats count by actor, repo, created_at
| where count > 0
| sort -created_at

References

Subscribe to it-learn Brief

Get it-learn Brief in your inbox (Mon–Fri) - Daily cybersecurity news, SE angles, and detection queries.