u/Expert_Sort7434

Sysdig's TRT published a report on JADEPUFFER, which they're calling the first fully agentic ransomware operation. Entry via Langflow CVE-2025-3248 (missing auth, patched since May 2025, CVSS 9.8). Once in, the agent harvested LLM provider keys + cloud creds, dumped Postgres, then pivoted to a production MySQL/Nacos box via a 2021 auth bypass and encrypted 1,342 config items — never saving the encryption key, so it's unrecoverable regardless of payment.

What stood out to me technically: the agent adapted mid-attack — rewrote a parser on the fly when it got XML instead of expected JSON, and reportedly fixed a failed login in ~31 seconds. None of the individual techniques are new. The orchestration speed is the whole story.

Open question for the sub: if detection tooling is tuned for human-paced dwell time, how much of current SOC playbook logic actually holds up against an adversary iterating in seconds instead of hours?

https://www.techgines.com/post/jadepuffer-ai-ransomware-langflow-cve-2025-3248

I previously covered a related Langflow RCE (CVE-2026-33017) here if you want more background: https://www.techgines.com/post/cisa-confirms-langflow-rce-cve-2026-33017-attackers-had-working-exploits-before-the-world-had-a-poc

DHS confirmed hackers accessed the Homeland Security Information Network and a connected SharePoint system sometime between late May and early June 2026. Public disclosure didn't happen until July 1–2 (Nextgov broke it, BleepingComputer/TechCrunch confirmed). DHS says no classified systems were touched, but hasn't said whether documents were taken or who's behind it.

I previously covered background on the SharePoint exposure angle here if you want more context: [SharePoint CVE-2026-32201 post — title confirmed, exact URL unverified, will update once confirmed in CMS].

Question for the room: given HSIN's "legacy information sharing environment" framing from DHS — how do you all handle the org politics of getting budget/attention for hardening a system that's simultaneously called "legacy" and "still actively used for World Cup security coordination"? Feels like a recurring pattern with sensitive-but-unclassified platforms specifically.

https://www.techgines.com/post/hsin-breach-dhs-homeland-security-information-network-cyberattack

Adversa AI just published research on something they're calling GuardFall — not a single CVE, but a structural gap in how AI coding agents (Hermes, OpenCode, Roo-Code, and others) validate shell commands before execution.

The core issue: these agents filter the literal text of a command against regex/wildcard patterns. But Bash rewrites that text at runtime — quote removal, $IFS substitution, command substitution — so a string that passes the filter can still evaluate to the exact dangerous command the filter was supposed to block. Tested against 11 agents, 10 failed in at least one of four bypass classes. Only Continue reportedly closed the majority of the surface.

The worst variant doesn't even need the operator to opt into anything — a malicious repo's config (e.g. an .aider.conf.yml with auto-test: true and a poisoned test command) can fire on first accepted edit.

I previously covered a related failure mode here if you want more background: CISA Confirms Langflow RCE CVE-2026-33017 — different mechanism, same root problem: AI tooling given privileged execution with a safety layer that doesn't actually model what the underlying interpreter will do.

Curious what this sub thinks: is sandboxing/credential isolation the only real fix here, or is there a filtering approach that could actually work against a shell that rewrites its own input?

https://www.techgines.com/post/guardfall-ai-coding-agent-shell-injection-vulnerability

The release candidate for MCP 2026-07-28 locked on May 21. Final spec publishes July 28, 2026, with a 12-month deprecation window for legacy MCP.

The good: Stateless architecture eliminates protocol-level session hijacking. Unsolicited server-initiated prompts removed. OAuth 2.1 mandated. New header-based routing (Mcp-Method / Mcp-Name) enables gateway-level inspection without body parsing.

The concerning: Akamai's security research team analyzed the RC and documented five new attack surfaces created specifically by the architectural changes:

1. Workflow hijacking — stateless server trusts client-held state objects; attackers manipulate them to redirect agent workflows
2. _meta privilege escalation — new universal metadata object accepts arbitrary key-value pairs; inject elevated values to bypass role enforcement
3. Header/body inconsistency bypass — Mcp-Method headers must match JSON-RPC body; deliberate mismatches can bypass gateway security controls
4. Hit-and-run async DoS — new Tasks extension enables long-running ops; initiate + disconnect = resource burn with no session to terminate
5. MCP Apps XSS/phishing — rich UI panels rendered in-app introduce XSS surface; AI-generated content can deliver phishing inside trusted tooling

The NSA's AI Security Center also published a formal CSI on MCP security (May 2026, doc ID u/OO/6030316-26) specifically calling out serialization risks, trust boundary failures in multi-server architectures, and lateral propagation from single compromised tool servers.

Current state according to public research: ~40% of internet-accessible MCP services have no auth. VIPER-MCP scan of 39,884 repos found 106 zero-days. These numbers should be verified against primary sources (Practical DevSecOps 2026 MCP stats report and Censys data) before you cite them, but they're directionally consistent with what everyone working in this space is observing.

Question for the thread: How are you handling the state management trust problem specifically? The move to client-managed state seems like it fundamentally breaks any security model that assumed the server could enforce session-level context. Curious whether anyone has built stateless MCP deployments with cryptographic state binding that actually work in production, or whether most teams are just accepting the risk.

For background on MCP's early attack surface footprint, I previously covered its integration into Kali Linux pentesting workflows here: https://www.techgines.com/post/claude-ai-integration-hack-the-gibson-kali-linux-s-new-ai-brain-is-here

Full writeup with the attack chain table and hardening checklist:

https://www.techgines.com/post/mcp-2026-07-28-security-overhaul-enterprise-attack-surface

JFrog Security Research dropped a full technical writeup and exploit walkthrough for DirtyClone (CVE-2026-43503) on June 25 — the fourth variant in what's becoming a frustrating pattern in the Linux kernel networking stack.

The short version of what makes this one interesting:

DirtyClone is the latest variant within the DirtyFrag vulnerability family, a class of Linux kernel memory corruption bugs affecting how socket buffers (skb) reference shared page-cache memory. These vulnerabilities are weaponized through in-place cryptographic transformations in subsystems such as XFRM/IPsec or RxRPC. PBX Science

The specific trigger here is the netfilter TEE target calling __pskb_copy_fclone(), which silently drops the SKBFL_SHARED_FRAG flag on packet cloning. The unflagged clone then passes through an IPsec ESP in-place decryption path that overwrites page-cache-backed memory for a setuid binary like /usr/bin/su.

What's operationally annoying:

The attack is confirmed to work on popular distributions where unprivileged user namespaces are enabled, including Debian, Ubuntu, and Fedora. A system is only fully protected against this exploitation model once the entire series of patches is applied. Jfrog

Meaning if you patched the original DirtyFrag CVEs in May but didn't apply CVE-2026-43503, you're still fully exploitable.

Detection gap worth flagging to blue team folks:

Both exploits avoid the disk entirely. Both bypass file-integrity monitoring because those tools check on-disk state. Both leave no kernel audit log. Both require only a local unprivileged user account to start. The CyberSec Guru

Patch: upstream v7.1-rc5. Ubuntu 24.04 fixed at 6.8.0-124.124. Distro-specific versions in the full write-up.

Discussion question: Has anyone seen robust eBPF-based detection rules for the DirtyFrag family yet? The obvious tripwire is unprivileged namespace creation immediately before su execution, but curious if anyone has tuned Falco or Tetragon rules specifically for this pattern.

I previously covered the Copy Fail predecessor (CVE-2026-31431) here if you want the architectural background on why this family keeps recurring: https://www.techgines.com/post/cve-2026-31431-copy-fail-linux-privilege-escalation

Full DirtyClone technical deep-dive: https://www.techgines.com/post/dirtyclone-cve-2026-43503-linux-kernel-privilege-escalation

Sharing a detailed technical breakdown I put together on FortiBleed for anyone in here managing Fortinet infrastructure.

What happened (quick summary):
Attackers systematically extracted configuration files from internet-facing FortiGate firewalls, cracked stored credential hashes using offline GPU clusters, and assembled a validated, searchable database covering 73,932+ unique firewall URLs across 194 countries — found circulating in criminal communities in mid-June 2026. Panelica

The technical angle that isn't getting enough attention:

Fortinet introduced PBKDF2-based password hashing for administrator credentials in FortiOS 7.2.11, 7.4.8, and 7.6.1, replacing the legacy SHA-256-based storage mechanism. SHA-256 is fast — GPU clusters can run billions of candidates per second against it. That's why cracking at this scale was operationally viable. The irony: patching FortiOS isn't enough. According to Arctic Wolf, after upgrading FortiOS, administrators must log in to the firewall at least once — this automatically re-hashes credentials with PBKDF2. If not feasible, manually update passwords using a super_admin account. Even then, FortiOS v7.2.x and v7.4.x retain SHA-256 hashes in the hidden 'old-password' setting. The Hacker NewsArctic Wolf

Questions for the community:

1. For those running FortiAuthenticator for MFA in front of FortiGate — does the FortiBleed config-level access bypass that layer entirely, or does it only grant device admin access?
2. Has anyone seen active post-exploitation activity from FortiBleed credentials yet, or is this still primarily a credential-sale/initial-access-broker scenario?
3. Researchers reported attackers correlating VPN credentials from FortiBleed with FortiSandbox exploitation to move laterally into internal environments. Anyone in a Fortinet-heavy shop seeing anomalous FortiSandbox behavior? Threat-Modeling

I previously covered how CVE-2026-44277 in FortiAuthenticator created RCE exposure at the identity layer of Fortinet infrastructure — FortiBleed hits the credential storage layer underneath that. Both pieces are relevant if you're doing a full Fortinet security review right now: [https://www.techgines.com/post/fortinet-fortiauthenticator-rce-cve-2026-44277-fortisandbox-cve-2026-26083]

Full breakdown with attack chain, CVE table, and remediation checklist at TechGines if you want the depth: https://www.techgines.com/post/fortibleed-fortigate-credential-compromise-86000-firewalls

The CleverHans Lab preprint from June 2 ("AI Agents Enable Adaptive Computer Worms") is worth a close read if you're in defence architecture or threat modelling.

Quick technical summary:
- Open-weight LLM (unnamed, released 2025) running locally on a single GPU
- 33-host isolated test network: Ubuntu 16.04–24.04, Debian 9–12, Alpine, Rocky, CentOS, Windows Server 2008–2022, IoT devices
- 73.8% exploitation rate / 62% self-replication rate over 7 days
- Exploited EternalBlue, SambaCry, PrintNightmare, DirtyPipe AND three 2026 disclosures (CopyFail, DirtyFrag, CVE-2026-39987) by reading public advisories at runtime
- 5 of 33 hosts had GPUs — the rest borrowed reasoning from compromised GPU peers over internal network

The part that keeps me up at night: this renders the "detect outbound LLM API calls" detection strategy useless. The reasoning engine is distributed across the compromised internal network. There are no cloud calls to flag.

Researchers withheld the agent's reasoning architecture and LLM name from the paper and pre-disclosed to Canadian authorities before release.

What's your team's current posture on detecting AI-augmented lateral movement? Is anyone actually writing detections for this threat class yet, or are we still waiting for vendors to catch up?

I previously covered the depthfirst AI agent that found 21 FFmpeg zero-days for $1,000 — if you want background on the autonomous vulnerability discovery side of this threat arc:
https://www.techgines.com/post/ai-agent-ffmpeg-zero-days-autonomous-vulnerability-discovery

Full breakdown with kill chain and defender checklist: https://www.techgines.com/post/ai-worm-self-replicating-llm-malware-university-of-toronto-proves-autonomous-network-takeover

CVE-2026-5027 dropped yesterday and exploitation is already confirmed in the wild per VulnCheck and BleepingComputer. Quick technical summary for those who haven't seen it:

**The Vuln:**
Langflow's `POST /api/v2/files` endpoint takes a `filename` parameter from multipart form data and passes it directly to the storage layer without sanitizing `../` sequences. Attacker writes a cron job to `/etc/cron.d/` → gets a shell at next cron execution.

CVSS 8.8, and with Langflow's default `auto-login=true`, no auth is needed. The GitHub PoC already shows reverse shell via cron injection working cleanly on exposed instances.

**What makes this interesting from a threat intel perspective:**
- This is the 5th exploited Langflow CVE in under 18 months (CVE-2025-3248, 0770, 21445, 33017, now 5027)
- CISA and VulnCheck confirmed MuddyWater (Iranian APT) was actively using the earlier CVE-2025-3248. The same platform, again.
- Censys found ~7,000 publicly accessible instances (their own caveat: 12-month historical data, current exposure may differ)

**The broader question I keep coming back to:**
Are your blue teams actually monitoring your AI dev tooling infrastructure — Langflow, Flowise, Open WebUI, etc. — with the same rigor as production apps? Because in most environments I've seen, these platforms sit in "shadow AI" territory — deployed by devs, no network controls, no log monitoring.

Patch: Langflow 1.10.0. Disable auto-login. Network-isolate port 7860.

I previously covered the AI tooling attack surface problem when the Malware-Slop npm campaign targeted Claude Code's working directory: https://www.techgines.com/post/malware-slop-the-malicious-npm-package-that-targeted-anthropic-s-claude-ai-supply-chain-and-lea

Curious — for those working in larger orgs, how are you handling inventory and monitoring for AI dev platforms? Are they under IT/security ownership or still living in the developer "move fast" zone?

https://www.techgines.com/post/langflow-cve-2026-5027-path-traversal-rce

Figured this thread was worth starting given the Unit 42 brief that dropped June 5 confirming active exploitation of CVE-2026-0257.

Quick technical summary for anyone who hasnt seen it yet:

The vulnerability is in GlobalProtect's authentication override cookie mechanism. If the same TLS certificate is used for both the HTTPS service and cookie signing (which is apparently not an uncommon configuration), an attacker can grab the public cert from your exposed portal and use it to generate a cryptographically valid auth override cookie. Submit that to the gateway, it accepts it, you get a VPN session. Theres a public PoC tool (forge_cookie.py released by Rapid7) that automates the forgery step.

Rapid7 MDR identified successful exploitation across numerous customers going back to May 17. Two distinct attack waves: Wave 1 from Vultr infrastructure on May 18, Wave 2 from Dromatics Systems on May 21. Both targeted local admin accounts specifically.

Unit 42 published IOCs on June 5 — IPs and suspicious host ID patterns (things like WINDOWS-LAPTOP-001, aa:bb:cc:dd:ee:ff in the VPN logs). Worth hunting those now if you havent already.

One thing that's stuck with me: Rapid7 noted that in roughly 8/10 impacted MDR customers, the gateway was accepting forged cookie probes even in cases where a full VPN session wasn't established. So if you're seeing cookie-auth-accepted events that didn't result in full VPN connection, don't close those as benign.

Mitigation options per the advisory:
- Patch (obviously)
- Disable "Accept cookie for authentication override" in portal/gateway config as workaround
- Separate the cert used for cookie signing from the HTTPS service cert
- Enable Cloud Authentication Service if you can

https://www.techgines.com/post/cve-2026-0257-pan-os-globalprotect-authentication-bypass-exploit

This fits into a wider pattern I've been tracking — we've seen similar perimeter auth bypass CVEs hit Cisco SD-WAN (CVE-2026-20182, CVSS 10.0, CISA KEV May 14), and the attack objective in both cases is the same: get unauthenticated remote access through the network edge. Previous coverage on that: https://www.techgines.com/post/cve-2026-20182-the-cvss-10-0-flaw-that-hands-attackers-the-keys-to-your-entire-sd-wan-fabric

Questions for the community:

1. For those who have GlobalProtect deployed — are you using auth override cookies? Was the cert configuration something that was set deliberately or just a default that wasn't hardened?
2. Has anyone seen post-VPN lateral movement in their environment from this? Unit 42 says they havent confirmed any as of June 5 but that seems like a narrow window given how many environments may be affected.
3. Curious whether anyone's tuned detections specifically for the forge_cookie.py host ID patterns — those fake MAC addresses and generic hostnames seem like relatively easy signals to alert on if you have good VPN log visibility.

Been going through the full EO text and most of the coverage is missing the technically interesting parts. Dropping what I found relevant as someone who works in network security.

**What's actually in it:**

Section 2 - CISA has 30 days to issue Binding Operational Directives for AI-powered defense of federal civilian networks. A Treasury-led clearinghouse is also being stood up to coordinate AI-driven vuln scanning across critical infrastructure — hospitals, banks, utilities. Practically this means new BODs incoming in early July. Worth tracking if you're in critical infra.

Section 3 - NSA gets classified authority to benchmark frontier AI models for "advanced cyber capabilities" before release. Voluntary framework, but labs are unlikely to decline. The threshold for "covered frontier model" designation is classified, which creates real uncertainty for AI labs.

Section 4 - This is the interesting one. AG directed to prioritize CFAA (18 U.S.C. 1030) and wire fraud enforcement specifically for AI-enabled attacks. The order explicitly names "AI agents" that autonomously breach systems "without human direction" as a covered activity. First time I've seen autonomous agent attacks legally defined in federal policy.

**What it doesn't do:**
- No mandatory pre-deployment testing for AI models
- No independent oversight body
- No binding safety standards for commercial AI
- Cannot mandate licensing or pre-clearance (the order says so explicitly)

**My question for this community:** The Section 4 criminal enforcement provision is interesting but attribution is still the hard problem. Does AI-generated attack infrastructure — LLM-written malware, AI-automated phishing — create new forensic fingerprints that could actually make attribution easier, or harder?

For context on what AI-enabled attacks look like in practice, I previously covered the ChatGPhish attack technique here if you want background: https://www.techgines.com/post/chatgphish-prompt-injection-chatgpt-phishing

Full EO breakdown: https://www.techgines.com/post/trump-ai-executive-order-cybersecurity-2026

So I've been going through the Wiz, JFrog, and Aikido analyses of the Miasma campaign that dropped June 1. A few things are worth unpacking beyond the headlines.

The attack used a compromised Red Hat employee's GitHub account to push malicious commits directly, then triggered GitHub Actions OIDC to publish packages to npm with valid SLSA provenance. This is the part that should concern everyone: the packages passed supply chain verification because the build pipeline itself was injected upstream of the attestation step. SLSA didn't fail here — its trust boundary was just further back than people assumed.

The new GCP and Azure identity collectors in this Shai-Hulud variant also feel like a notable escalation. Previous versions were credential harvesters. This one is actively enumerating cloud access — which is a different kind of threat model.

Attribution is genuinely uncertain: TeamPCP published the toolkit publicly in May, so this could be a copycat. The "Miasma" branding (replacing Dune refs with Greek mythology) could support that. https://www.techgines.com/post/red-hat-npm-supply-chain-attack-miasma

I previously covered the original TeamPCP PyPI campaign here if you want background on the Shai-Hulud lineage: https://www.techgines.com/post/pytorch-lightning-supply-chain-attack-pypi-teampcp

Question for the community: given that OIDC trusted publishing was the attack vector here, what's actually the correct trust model for npm publishing workflows? Does restricting OIDC to specific branch patterns meaningfully reduce risk, or is a compromised developer account always going to find a way through?

Palo Alto Networks' CVE-2026-0257 is worth discussing because the core issue is not just "patch the VPN." The vulnerability affects GlobalProtect portal/gateway configurations where authentication override cookies are enabled and a specific certificate configuration creates exposure. Palo Alto's advisory says attackers can bypass security restrictions and establish unauthorized VPN connections. Rapid7 reported successful exploitation across multiple customers and described suspicious cookie authentication activity, including a second observed wave where VPN IP assignment occurred in some environments.

The technical lesson is that authentication override cookies function like delegated identity. If the gateway accepts a cookie as proof that a user has already authenticated, then that cookie validation path becomes as sensitive as MFA, SSO, or any other primary authentication decision. Rapid7's analysis points to certificate reuse as the dangerous configuration pattern: when the same certificate material is exposed through the HTTPS service and used for authentication override cookie handling, forged cookies may become possible.

For defenders, the interesting question is what telemetry actually proves abuse. Gateway logs may show cookie authentication to a local account, unusual client hostnames, generic device identifiers, suspicious source infrastructure, or VPN IP assignment after cookie-based authentication. But many organizations still treat VPN logs as compliance records rather than high-fidelity detection sources.

https://www.techgines.com/post/cve-2026-0257-globalprotect-vpn-bypass-exploited

I previously covered Palo Alto's agentic endpoint security move here if you want more background: https://www.techgines.com/post/palo-alto-networks-agentic-endpoint-security-koi-acquisition

Discussion question: If you run GlobalProtect or a similar VPN stack, do you treat authentication cookies and VPN session logs as identity-tier security data, or mostly as infrastructure telemetry?

Heads up for anyone running self-hosted Gitea or Forgejo.

CVE-2026-27771 was disclosed yesterday (May 27, 2026). The short version: the "private" flag on Gitea container repositories only controlled how things looked in the UI. The actual registry API endpoint — where Docker/OCI pulls happen — had no auth enforcement whatsoever. Any unauthenticated remote user could pull private images using standard pull commands.

NoScope (UK-based security firm) found this using their autonomous AI penetration testing agent in April 2026. They responsible disclosed it to the Gitea team, who patched in v1.26.2. The flaw has apparently been present since the container registry feature was first shipped, roughly four years ago.

Scale: NoScope used Shodan to estimate 30,000+ affected public-facing instances across 30+ countries. Their methodology was deliberately conservative — doesn't count instances behind custom-branded reverse proxies or Shodan-invisible deployments. So the actual number is likely higher.

Forgejo is also confirmed affected. NoScope tested it directly.

What to do:
- Update Gitea to v1.26.2
- If you can't patch immediately: set [service].REQUIRE_SIGNIN_VIEW=true in config (note: this blocks ALL unauthenticated access including intentionally public images)
- Rotate any secrets/credentials baked into container images on affected versions
- Monitor your registry access logs for anonymous pull activity

No public PoC released. No confirmed active exploitation at time of writing — but given the Shodan visibility, that window might be short.

I previously covered the Megalodon GitHub Actions supply chain attack here if you want more background on how developer infrastructure is becoming a primary attack surface: https://www.techgines.com/post/megalodon-github-actions-supply-chain-attack-safedep-2026

Full writeup with attack chain diagram and remediation checklist:https://www.techgines.com/post/cve-2026-27771-gitea-vulnerability-private-container-images

Questions/discussion welcome — particularly curious whether anyone's seen anomalous pulls in their Gitea logs that they may have previously dismissed.

Broadcom's Threat Hunter Team (Symantec + Carbon Black) dropped a detailed report on MuddyWater's Q1 2026 espionage campaign yesterday and I've been digesting it. The short version: 9 organisations across 9 countries hit using DLL sideloading through two signed binaries — Fortemedia's fmapp.exe and SentinelOne's sentinelmemoryscanner.exe.

The second choice is what got me. Deliberately using a security vendor's binary because it's unlikely to trigger alerts. Pair it with a rogue DLL (sentinelagentcore.dll), embed ChromElevator inside to bypass Chrome App-Bound Encryption, and you've got credential theft happening inside a process your SOC probably trusts by default.

Technical highlights:

• Node.js → PowerShell implant chain: recon, screenshots, SAM hive dump, privilege escalation, SOCKS5 reverse proxy tunneling
• C2 contact via 157.20.182[.]49 (fmapp.dll variant)
• Data staged on sendit[.]sh and in some cases uploaded to victim orgs' own public web roots (compressed as RAR), then pulled via axel + proxychains
• Dwell time in South Korean electronics manufacturer: ~1 week

Symantec notes the group is running "implant-driven activity rather than continuous operator presence" — which is actually harder to catch than loud, interactive C2 sessions.

My question for the room: how are you handling DLL load path auditing for signed security product binaries? Traditional allowlisting based on process name clearly doesn't cut it here. Are any of you enforcing DLL path constraints via AppLocker or WDAC to the point where you'd catch sentinelagentcore.dll loading from a non-standard directory?

I previously covered the Webworm EchoCreep + GraphWorm campaign (China-aligned, abused Discord + Microsoft Graph API as C2) which follows the same "abuse trusted infrastructure" doctrine — worth reading alongside this one if you're thinking about detection strategy:
https://www.techgines.com/post/webworm-echocreep-graphworm-discord-microsoft-graph-api-c2-backdoor

Full breakdown with IOCs and full attack chain at TechGines (no paywall, no signup):
https://www.techgines.com/post/muddywater-dll-sideloading-espionage-campaign-2026

Source report: Broadcom/Symantec — security.com/threat-intelligence/iran-seedworm-electronics

Just finished digging through the SafeDep report and a few corroborating sources on the Megalodon campaign that hit GitHub on May 18.

The short version: an automated attack pushed 5,718 malicious commits to 5,561 repositories in a six-hour window. The commits were authored under names like "build-bot", "auto-ci", "pipeline-bot" — with emails designed to look like noreply CI automation — and injected Base64-encoded bash payloads into GitHub Actions workflow files.

By May 21, the attacker's C2 (216.126.225[.]129:8443) had received 575K+ files and 449 GB of data. Still ongoing at last count.

What's technically interesting:

**Two payload variants:**
- *SysDiag*: Adds a new workflow file, triggers on every push + pull_request_target. Active exfiltration every pipeline run.
- *Optimize-Build*: Replaces existing workflows with workflow_dispatch. Dormant until the attacker fires it manually via the GitHub API. These are the scary ones.

**What gets stolen:**
- All CI environment variables
- AWS/GCP/Azure credentials (both static and IMDSv2 role-based)
- GitHub Actions OIDC tokens → direct cloud provider auth without static credentials
- SSH keys, Docker configs, .npmrc, kubeconfig, Vault tokens, Terraform creds
- 30+ secret regex pattern grep sweep across the entire workspace

The OIDC piece is the part that sticks with me. Rotating credentials post-breach doesn't help if the attacker can just mint a fresh OIDC token via a workflow_dispatch call on a repo you haven't audited yet.

**Detection:** Search your repo history for commits authored by `build-system@noreply[.]dev` or `ci-bot@automated[.]dev` around May 18.

Affected npm package: `@tiledesk/tiledesk-server` versions 2.18.6–2.18.12.

I covered the TanStack CVE-2026-45321 supply chain attack a couple weeks back which used the same OIDC exfiltration primitive, if you want background on how this attack surface works: https://www.techgines.com/post/tanstack-npm-supply-chain-attack-cve-2026-45321-teampcp

Full Megalodon breakdown with IOC table and remediation checklist: https://www.techgines.com/post/megalodon-github-actions-supply-chain-attack-safedep-2026

**Question for the community:** How many organisations actually audit their GitHub Actions permissions regularly? In my experience, most teams treat the Actions runner as a trusted internal system — but after this, it's clear it needs to be treated as a potential adversary foothold. Are people actually implementing SHA pinning and workflow approval gates in practice, or is it still mostly aspirational?

A lot of the coverage this week on the TanStack supply chain attack has focused on the victim list (Grafana, GitHub, OpenAI, Mistral AI, etc.) and the ransom angle. Which makes sense from a news perspective. But I think the two most technically significant aspects of CVE-2026-45321 are getting buried:

1. The SLSA bypass. The malicious packages carried valid signed provenance certificates and passed SLSA checks. This isn't a failure of the certificates themselves — the attackers had access to the legitimate build pipeline via the pull_request_target pwn request + GitHub Actions cache poisoning chain. So the provenance was technically real. This is a significant problem for how the industry is positioning SLSA as a supply chain security solution.

2. The dead man's switch. The payload (router_init.js) polls stolen GitHub tokens every 60 seconds. Revoking the token — step one in every IR playbook I've ever read — triggers rm -rf ~/. The attacker designed the malware around the defender's expected response. I've not seen this kind of IR-aware design in an npm package attack before. Has anyone else?

The three root causes (pull_request_target misconfig, cache poisoning across trust boundaries, OIDC token extraction) are all documented techniques individually. None of them are novel. But requiring all three in sequence is operationally sophisticated and means patching one would've broken the chain. That's worth discussing.

High-level question for the thread: At what point does SLSA need to be rethought as a control, given that it can be satisfied by an attacker who controls the build pipeline? And is anyone actually pinning CI/CD dependencies to commit SHAs rather than semver ranges? Because that seems like the single biggest architectural gap this attack exposed.

I previously covered the Hugging Face LeRobot RCE (same threat model — AI open-source dev toolchain as attack surface) here if you want more background: https://www.techgines.com/post/cve-2026-25874-hugging-face-lerobot-rce-pickle-deserialization

Full analysis including attack chain and correct remediation order (the token revocation sequence matters a lot here): https://www.techgines.com/post/tanstack-npm-supply-chain-attack-cve-2026-45321-teamPCP

So CVE-2026-45585 dropped publicly on May 19 and I've been going through the technical details. The short version: an attacker with physical access can inject autofstx.exe into the BootExecute value inside the WinRE image. That binary runs pre-OS, completely before your EDR stack initialises, and it bypasses BitLocker's pre-boot authentication entirely.

Affected: Windows 11, Server 2022, Server 2025.
No patch yet — just Microsoft's 6-step manual WinRE mitigation (mount → load hive → remove autofstx.exe → unload → unmount/commit → reagentc disable/enable cycle) and the recommendation to move from TPM-only to TPM+PIN.

A few things I'm genuinely curious about from a practical ops standpoint:

1. For those managing large Windows fleets — what's your current rollout strategy for TPM+PIN enforcement at scale? Intune, GPO, something else? Any gotchas with user PIN resets in a helpdesk-heavy environment?
2. The WinRE mitigation has to be applied per-machine. Is anyone scripting this and if so how are you handling the fact that reagentc operations occasionally fail silently on certain hardware configs?
3. Physical access attacks are often dismissed as "out of scope" in threat models. Does something like YellowKey — with a public PoC — change how your organisation frames physical device loss in risk assessments?

The public PoC on GitHub is the part that concerns me most. This isn't theoretical anymore — the barrier to exploitation just dropped significantly.

I previously covered the Microsoft MDASH story (AI finding 16 Windows zero-days) here if you want background on the broader Windows security picture: https://www.techgines.com/post/microsoft-mdash-agentic-ai-security-windows-vulnerabilities

Full technical breakdown at TechGines: https://www.techgines.com/post/cve-2026-45585-bitlocker-bypass-yellowkey-zero-day

Hey everyone,

Just wanted to kick off a discussion because I think a lot of sysadmins are going to be scrambling on this one.

Microsoft confirmed active exploitation of CVE-2026-42897 — a cross-site scripting zero-day in Exchange Server's Outlook Web Access (OWA) component. The attack vector is genuinely simple: attacker sends a crafted email, victim opens it in OWA, arbitrary JavaScript runs in their browser session. That's the exploit. No credential stuffing, no lateral movement required to initiate.

Affected: Exchange Server 2016 CU23, 2019 CU14/CU15, and SE RTM. Exchange Online is NOT affected.

**The patch situation is messy:**
- No permanent patch exists yet
- EEMS auto-mitigation deployed May 14 (should have applied automatically if EEMS is enabled)
- Manual mitigation: run `.\EOMT.ps1 -CVE "CVE-2026-42897"` from elevated Exchange Management Shell
- Exchange 2016/2019 customers need Period 2 ESU enrollment to receive the permanent patch when it drops
- CISA KEV listed — federal agencies must remediate by May 29

**The tradeoffs with the mitigation:**
- OWA Print Calendar breaks
- Inline images in OWA reading pane won't display
- OWA Light mode also affected (though that should already be deprecated in your environment)

This feels like déjà vu from the ProxyLogon/ProxyShell days, and honestly I'm surprised more people aren't talking about this given that 14 of the 19 Exchange CVEs in CISA's KEV catalog were later weaponized in ransomware attacks.

**My questions for the community:**
- How quickly was EEMS mitigation confirmed in your environments?
- Anyone in the r/sysadmin crowd still not enrolled in Period 2 ESU for 2016/2019? How are you handling the patching gap?
- Has anyone seen detection hits in IIS logs suggesting pre-disclosure exploitation?

I wrote a more detailed technical breakdown including the full attack chain visualization and step-by-step mitigation here if you want more background: https://www.techgines.com/post/microsoft-exchange-server-zero-day-cve-2026-42897-owa-xss-exploit

And for context — this is the second critical mail server vulnerability this week. We covered the Exim CVE-2026-45185 (Dead.Letter) RCE three days ago here: https://www.techgines.com/post/dead-letter-exim-cve-2026-45185-a-critical-unauthenticated-rce-is-hiding-inside-your-gnutls-mail

If you're running a hybrid environment with Exim relay + on-prem Exchange, you've had a rough week.