Seven Critical CVEs Hit Core Infra: Step CA, Harbor, Rails

◆ DEEP DIVES

1. 01

   Seven CVSS 9.0+ CVEs Hit Core Infrastructure — Your Triage Checklist

   <p>An unusually dense cluster of critical vulnerabilities landed this week across infrastructure components you almost certainly depend on. This isn't the typical churn of IoT CVEs — these hit your <strong>container registry, PKI, web frameworks, CI/CD pipelines, and security monitoring</strong> simultaneously.</p><h3>The Critical Path</h3><p><strong>Step CA ≤0.30.0-rc6 (CVE-2026-30836, CVSS 10.0)</strong> allows unauthenticated certificate issuance via SCEP UpdateReq. If you're using Step CA for internal PKI — common for device certificate enrollment and mTLS — an attacker can mint certificates your entire service mesh trusts. <em>This undermines zero-trust architectures entirely.</em></p><p><strong>Harbor ≤2.15.0 (CVE-2026-4404, CVSS 9.4)</strong> has hardcoded credentials enabling unauthenticated web UI access to your container registry. Every <code>docker pull</code> from a compromised Harbor becomes suspect. Patch, then rotate all credentials and audit image integrity.</p><p><strong>Spring Security 5.7.0–7.0.3 (CVE-2026-22732, CVSS 9.1)</strong> is the most insidious: it <strong>silently stops writing HTTP security headers</strong> — HSTS, CSP, X-Frame-Options. Nothing in your logs tells you. Your apps have been running without these protections, potentially for weeks. A quick <code>curl -I</code> against your endpoints will tell you immediately.</p><h3>The CI/CD Layer</h3><p><strong>Tekton Pipelines (CVE-2026-33211, CVSS 9.6)</strong> has path traversal via pathInRepo enabling arbitrary file reads — effectively a credential dump, since CI/CD pipelines typically hold keys to everything. <strong>Spinnaker Clouddriver (CVE-2026-25534, CVSS 9.1)</strong> has a URL validation bypass that's a repeat of CVE-2025-61916, meaning the first fix was incomplete.</p><h3>Your Security Tools Are Also Vulnerable</h3><p><strong>Wazuh SIEM 4.0.0–4.14.2</strong> has RCE and privilege escalation from worker to master (CVSS 9.1). An attacker who compromises a worker node can pivot to owning your entire security visibility. The master typically has read access to all agent data, events, and integration credentials. <em>Patch the master first, then workers.</em></p><blockquote>Your vulnerability scanner (Trivy), your SAST tool (Checkmarx), and your SIEM (Wazuh) were all exploitable this week. Security tooling as an attack surface is no longer theoretical — it's the pattern.</blockquote><h3>Also on your list</h3><ul><li><strong>Rails Active Storage (CVSS 9.8)</strong>: Path traversal + injection across versions prior to 8.1.2.1, 8.0.4.1, 7.2.3.1</li><li><strong>Citrix NetScaler</strong>: Unauthenticated memory disclosure matching CitrixBleed severity — TLS-terminating load balancers leak session tokens and plaintext creds from memory</li><li><strong>jsrsasign npm 7.0.0–11.1.1 (CVSS 9.1)</strong>: Biased DSA nonces during signature generation — run <code>npm ls jsrsasign</code> and <code>npm ls jspdf</code> to check transitive exposure</li></ul>

   Action items

   • Run `curl -I` against all Spring Security-backed endpoints to verify HSTS, CSP, and X-Frame-Options headers are present
   • If running Step CA ≤0.30.0-rc6, patch immediately and audit all issued certificates for unauthorized entries via SCEP
   • Check Harbor version; if ≤2.15.0, patch, rotate all credentials, and audit container image integrity checksums
   • Patch Rails Active Storage, Tekton Pipelines, and Spinnaker Clouddriver across all environments this sprint
   • If running Wazuh 4.0.0–4.14.2, upgrade master node first, then workers, and review worker-to-master network controls

   Sources:gRPC-Go auth bypass, Harbor hardcoded creds, Spring Security silent header drop — your infra stack needs triage now · Your Trivy-based container scanning pipeline may be compromised — 1,000+ SaaS environments already breached

2. 02

   Google's 2029 PQC Deadline — Why 7 Independent Sources Are Telling You the Same Thing

   <p>Seven independent intelligence sources flagged Google's post-quantum cryptography migration this week — the strongest cross-source convergence in today's briefing. This isn't an echo chamber effect; each source brings different detail that, combined, paints a clear picture: <strong>the timeline for quantum-safe migration just compressed by six years</strong>, and platform vendors are already shipping implementations.</p><h3>What Google Actually Said</h3><p>Google accelerated its internal PQC migration from <strong>2035 to 2029</strong>, citing faster-than-expected advances in quantum hardware, error correction, and factoring algorithms. This is the company that builds the <strong>Willow quantum processor</strong> and runs arguably the deepest quantum research program outside government labs. When their internal threat modeling moves by six years, the signal carries weight that a random vendor announcement wouldn't.</p><h3>The Implementation Is Already Shipping</h3><p><strong>Android 17 beta</strong> includes PQC key support for app signing and signature verification. Chrome and Cloudflare have been running <strong>hybrid key exchange (X25519+ML-KEM-768)</strong> in production for over a year. The NIST standards are finalized: <strong>ML-KEM</strong> (FIPS 203) for key encapsulation, <strong>ML-DSA</strong> (FIPS 204) for signatures, <strong>SLH-DSA</strong> (FIPS 205) for stateless hash-based signatures. OpenSSL 3.2+, BoringSSL, and AWS-LC all have support at various maturity levels.</p><blockquote>When a platform vendor starts shipping post-quantum primitives in beta, it means they believe production deployment is 12–18 months out. If your systems use RSA-2048 or ECDSA for anything, you need to understand your exposure.</blockquote><h3>The Harvest-Now-Decrypt-Later Threat</h3><p>The White House is simultaneously considering moving the federal deadline from 2035 to <strong>2030</strong>. The convergence from multiple independent parties signals this isn't Google grandstanding. The practical question for engineers isn't <em>"will quantum computing break RSA?"</em> — it's <strong>"will data I encrypt today still be safe in 2032?"</strong> If you handle healthcare records, financial data, or anything with long-lived confidentiality, the answer is increasingly <em>maybe not</em>. Nation-state actors are actively stockpiling encrypted traffic.</p><h3>The Migration Is a Sprawling Dependency Problem</h3><p>The crypto isn't the hard part — it's the <strong>inventory</strong>. Most teams have no consolidated view of where they use which algorithms. RSA in your TLS config, ECDSA in JWT signing, AES-GCM with ECDH key agreement in at-rest encryption — scattered across dozens of config files, libraries, and managed services. ML-DSA signatures are <strong>~40x larger than ECDSA</strong>, which affects certificate chain size and bandwidth. The practical migration path is <strong>hybrid mode</strong>: classical + PQC in parallel. Start with TLS termination points and work inward.</p><h4>Crypto-Agility as Architecture Property</h4><p>The real question: can you swap cipher suites and key exchange algorithms <strong>without redeploying your entire fleet</strong>? If the answer is no, fixing that architectural gap is your first step — before any algorithm changes. Abstract cryptographic operations behind well-defined interfaces managed at the infrastructure layer (service mesh, TLS proxy, KMS).</p>

   Action items

   • Catalog every use of RSA, ECDSA, and ECDH across TLS termination, JWT signing, mTLS, data-at-rest encryption, VPN tunnels, and certificate chains this quarter
   • Prototype hybrid PQC key exchange (X25519+ML-KEM-768) on one non-critical internal TLS endpoint to measure performance overhead
   • Evaluate crypto-agility: test whether you can change cipher suites via config (service mesh, proxy) without code changes in application services
   • Identify all data stores with confidentiality requirements beyond 2029 and flag them as priority PQC migration targets

   Sources:Your CI/CD pipeline may be owned: TeamPCP's cascading supply chain attack · Google says Q Day is 2029 · Google's 2029 PQC deadline means your TLS and key management migration just got 6 years closer · TurboQuant's 3-bit KV cache compression hits 8x attention speedup · TurboQuant's 6x KV cache compression + Google's PQC 2029 deadline · Google says quantum breaks your TLS by 2029

3. 03

   AI Agent Sandboxing Has a Reference Architecture — And DNS Is Still the Escape Hatch

   <p>Two independent projects — NVIDIA's <strong>OpenShell</strong> and Niels Provos's <strong>IronCurtain</strong> — arrived at nearly identical agent sandboxing architectures this week. When independent teams converge on the same design, that's the strongest signal the pattern is correct. If you're running AI agents in production, this is your reference architecture.</p><h3>The Converged Pattern</h3><table><thead><tr><th>Layer</th><th>Mechanism</th><th>Purpose</th></tr></thead><tbody><tr><td>Filesystem</td><td>Landlock LSM</td><td>Restrict file access</td></tr><tr><td>Syscalls</td><td>seccomp-bpf</td><td>Block dangerous syscalls</td></tr><tr><td>Network</td><td>Network namespaces</td><td>Isolate network access</td></tr><tr><td>Actions</td><td>Single chokepoint proxy</td><td>Policy enforcement on all tool use</td></tr><tr><td>Credentials</td><td>Injection outside agent env</td><td>Agent never sees real secrets</td></tr></tbody></table><p>OpenShell ships as <strong>K3s-in-Docker</strong> supporting Claude, Codex, and Ollama out of the box with hot-reloadable policies. IronCurtain's credential isolation pattern — a <strong>MITM proxy that swaps fake API keys for real ones</strong> in <code>--network=none</code> containers — is immediately implementable.</p><h3>DNS: The Universal Escape You're Not Testing</h3><p>AWS Bedrock AgentCore's "Sandbox" network mode — documented as <strong>"complete isolation with no external access"</strong> — allows public DNS queries sufficient for <strong>bidirectional C2 tunneling, reverse shells, and full data exfiltration</strong>. AWS's response: they won't fix it, they'll update the docs, and here's a $100 gift card. <em>If your isolation boundaries don't block DNS, they don't block anything.</em></p><blockquote>Every sandbox and isolation boundary in your infrastructure needs a DNS egress test. Run a simple `dig` from inside your 'isolated' environments. If it resolves, you have a C2 channel.</blockquote><h3>The Shadow Agent Problem Is Already Here</h3><p>Microsoft's Cyber Pulse report shows UK enterprise agent adoption tripled in one year (<strong>22% → 62%</strong>), with <strong>84% of leaders admitting shadow agents are deployed without security oversight</strong>. The confidence gap is telling: <strong>87%</strong> say they can stop unauthorized agents while <strong>86%</strong> simultaneously say they aren't ready for agent security challenges. These aren't chatbots — they're autonomous actors with credentials making write operations against production systems.</p><h3>MCP Governance Is Marketing, Not Engineering</h3><p>Six vendors announced MCP governance at RSAC. None enforce the protocol at a meaningful level. If you're building agents that interact via MCP, you are currently <strong>on your own for security enforcement</strong>. Treat every MCP endpoint like an untrusted external API. Cisco's open-source <strong>DefenseClaw</strong> is notable specifically because you can audit what it actually enforces versus what it claims.</p><h3>CLIs Are Your Agent's New Syscall Interface</h3><p>Cursor published CLI design guidelines for agent consumption, ElevenLabs immediately adopted them, and multiple new tools shipped CLI-first this week. Every CLI you maintain is now a potential <strong>agent API surface</strong>. If your deployment scripts output colored tables with spinners, they're broken for agents. Add <code>--json</code> output modes, proper exit codes, idempotent operations, and eliminate interactive prompts.</p>

   Action items

   • Test DNS egress from every sandbox, container, and isolation boundary in your infrastructure with a `dig` or DNS tunnel PoC this sprint
   • Prototype IronCurtain's credential proxy pattern (--network=none container + MITM proxy swapping fake keys for real ones) for one agent workflow
   • Audit all service accounts, OAuth tokens, and API keys created in the last 12 months for unauthorized AI agent integrations
   • Add --json flags and non-interactive modes to your most-used internal CLIs before agents start consuming them

   Sources:Your AI agent sandbox is probably leaking via DNS — and AWS won't fix theirs · CLIs are becoming your agent's syscall interface · LiteLLM PyPI poisoned (v1.82.7-8) — check your lockfiles now · Shadow AI agents are already in your production environment · TurboQuant's 3-bit KV cache compression hits 8x attention speedup · A production Claude Code agent architecture