The Engineer

The Situation

Three independent security developments converged today, each invalidating a different trust assumption in your stack. Together, they represent the most actionable security day in weeks.

1. Dell RecoverPoint: CVSS 10.0, Actively Exploited

CVE-2026-22769 is a hardcoded admin credential in tomcat-users.xml on Dell RecoverPoint for Virtual Machines. The threat actor UNC6201 is actively exploiting it to deploy malicious WAR files via /manager/text/deploy, achieving root-level code execution. Persistence is maintained by hijacking convert_hosts.sh (runs at boot via rc.local). The audit trail lives in /home/kos/auditlog/fapi_cl_audit_log.log.

The deeper concern: UNC6201 has evolved from BRICKSTORM to a new GRIMBOLT backdoor compiled with native AOT, which strips .NET CIL metadata and renders standard analysis tools (dnSpy, ILSpy, dotPeek) useless. GRIMBOLT introduces Ghost NICs for covert communication and iptables-based Single Packet Authorization on compromised vCenter appliances. This is a nation-state actor deliberately targeting backup infrastructure to deny recovery capability.

2. EDR Blind Spot: ADWS Port 9389

ADWSDomainDump uses Active Directory Web Services (port 9389) instead of LDAP to enumerate AD objects — and it bypasses both CrowdStrike Falcon and Microsoft Defender for Endpoint. This isn't a signature gap fixable by a rule update; it's a protocol-level architectural blind spot. EDR vendors built detection around LDAP patterns and simply don't monitor ADWS. Until they add an entirely new data source, you're exposed.

3. Password Manager Zero-Knowledge: Marketing, Not Cryptography

ETH Zurich's Applied Cryptography Group demonstrated 25 attacks across three major vendors:

The attacks work via lightweight server impersonation during routine sync operations — not a full infrastructure compromise. Root cause: feature-bloat complexity and reliance on obsolete 1990s-era cryptographic primitives. Full paper drops at USENIX Security 2026.

Your backup infrastructure, your EDR coverage, and your password manager all have known, exploitable gaps right now — the question isn't whether to act but which one you patch first.

The Pattern

Three independent production infrastructure findings from Pinterest, FloTorch, and Vercel converge on the same lesson: simpler approaches are outperforming complex ones, often dramatically. If your team is investing in sophisticated solutions for Spark memory management, RAG chunking, or SSR streaming, these benchmarks should trigger a reassessment.

Pinterest: CPU-First Spark OOM Recovery (96% Reduction)

Pinterest discovered that many Spark OOM failures aren't genuine memory exhaustion but contention-induced failures. Their progressive retry strategy:

1. First retry: Increase CPU allocation only (no memory change)
2. Subsequent retries: Launch progressively bigger executors — 2x, 3x, 4x resource profiles scaling memory, overhead, and off-heap

Result: 96% reduction in OOM failures plus compute cost savings from not over-provisioning every job. This is specifically tuned for Gluten jobs (native Spark execution engine), but the CPU-first insight applies to vanilla Spark too. The trade-off: you need spare cluster capacity for 2x-4x executors to schedule — this works best with elastic compute or deliberate headroom.

FloTorch: Naive RAG Chunking Wins

Simple 512-token recursive character splitting beat both semantic and proposition-based approaches on accuracy while generating 3-5x fewer vectors. That's 3-5x less embedding compute, storage, and retrieval latency. Caveat: corpus characteristics and query types aren't disclosed — domain-specific content may differ.

Vercel: The WebStreams Promise Tax

The WebStreams spec requires a Promise allocation per chunk when piping between streams. For SSR workloads streaming HTML fragments at high frequency, this creates CPU overhead unrelated to application logic. Vercel's fast-webstreams collapses linear pipe chains into a single Node.js pipeline() call, claiming 10x throughput improvement. The API is a drop-in replacement, and Vercel intends to merge it into Node.js core.

Pinterest, FloTorch, and Vercel independently proved the same thing: the industry is over-engineering what should be straightforward, and the simpler approach wins on both performance and cost.

What's Converging

GitHub Agentic Workflows entered technical preview, letting you define automation outcomes in plain Markdown and execute them via coding agents in GitHub Actions. Simultaneously, Agoda shipped a zero-code API-to-MCP bridge using DuckDB for schema introspection, and authorization models for AI agents are emerging as a critical infrastructure gap. These three developments signal that agents are moving from demos to deployment — and the trust model isn't ready.

GitHub Agentic Workflows: The Promise and the Risk

The architecture: Markdown-defined intent → coding agent interpretation → execution within GitHub Actions runners. Target use cases include issue triage, documentation generation, and code quality enforcement. But critical questions remain unanswered:

• Determinism: Traditional Actions are deterministic. Agent-driven workflows are not. How do you debug a flaky agent? How do you reproduce a failure?
• Prompt injection: If the agent processes issue bodies or PR descriptions as input, adversarial content could manipulate behavior. This is the biggest unaddressed risk in agentic CI/CD.
• Trust boundaries: What repo permissions does the agent get? Can it push to protected branches or modify workflow files?

Authorization: The Missing Infrastructure Layer

Static policy engines like AWS Cedar model "user X has role Y" but can't express "agent A was delegated access by user B to resource C in context D." SpiceDB and Zanzibar-style systems model this as a relationship graph — the correct abstraction for agent delegation chains. If your agent fleet is growing, this architectural decision matters now, not after your first authorization incident.

Where to Draw the Line

Agent-generated code is still code you own. Every line an agent writes goes into your codebase, your maintenance burden, your on-call rotation.

The Landscape

Three distinct supply chain attack vectors were disclosed today, each targeting a different layer of the software delivery chain. Individually, each is a known attack pattern. Together, they illustrate that adversaries are pursuing simultaneous multi-layer compromise — and your defenses need to cover all three.

Firmware: Keenadu Android Malware

Keenadu hijacks Android's Zygote process — the parent of every app process on the device. Once injected, it's in every app, deploying modules targeting Amazon, Temu, monitoring Chrome queries, and running ad fraud. 13,000 devices confirmed across Russia, Japan, Germany, Brazil, and the Netherlands. Remediation requires full firmware replacement — no software fix exists. Kaspersky has published IoCs.

Repository: Triton Fork Social Engineering

An attacker created a fake GitHub fork with backdated commits padding the contribution graph to appear legitimate, then embedded a Windows-only malware ZIP in an Xcode asset path. Sandbox analysis reveals a multistage chain: 7zip → LuaJIT → anti-analysis tricks → C2 traffic masquerading as Microsoft and blockchain traffic. The social engineering is the innovation — the contribution graph manipulation makes provenance verification harder.

Distribution: Notepad++ Update Hijack (Mitigated)

A hijacked update server for Notepad++ 8.9.2 was caught and mitigated. The fix: double-lock verification requiring both a signed installer and signed XML manifest. This is the correct pattern — but most internal tools and smaller open-source projects don't implement it.

Supply chain attacks are no longer single-vector — adversaries are hitting firmware, repositories, and update mechanisms simultaneously, and your defense needs to cover all three layers.