The Engineer

CVE-2026-29000: pac4j JWT Forgery via Public RSA Keys

This is maximum-severity, pre-authentication, internet-facing, and has a public proof-of-concept. The pac4j Java security library accepts JWTs signed with HS256 using the public RSA key as the HMAC secret when it should only accept RS256 signatures verified against that public key. This is a well-known algorithm confusion vulnerability class (see Auth0's 2015 advisory), but the fact it's appearing in a widely-used library integrated into hundreds of packages in 2026 is alarming. The patches shipped within two days, which is commendable — but the real risk window is right now, between PoC publication and widespread patching.

If pac4j is three layers deep in your dependency graph behind a framework adapter, you might not even know you're affected. This is precisely the scenario where SBOM generation pays for itself.

Run mvn dependency:tree -Dincludes=org.pac4j and equivalent Gradle commands. Check fat JARs and shaded dependencies where the package name may be relocated.

MCP Authorization Is Broken by Design — Not by Implementation

Doyensec published a comprehensive attack surface map of MCP's OAuth 2.0 and JAG (Identity Assertion JWT Authorization Grant) model. Four structural flaws make production MCP deployments provably insecure:

1. No token revocation path for misbehaving agents — compromised agents retain access until token expiry
2. LLM-driven scope escalation without user consent — the scope negotiation layer is LLM-influenceable
3. Undefined client credential issuance enabling namespace collision and resource identifier injection
4. ID-JAG replay amplifies blast radius across multiple MCP access tokens

Confirmed CVEs already exist: CVE-2025-53100 and CVE-2025-53818 for command injection, CVE-2025-4144 and CVE-2025-4143 for SSO metadata manipulation. DNS rebinding against unauthenticated localhost WebSocket servers rounds out the attack surface. These aren't bugs to patch — they're design gaps in a spec being deployed to production today.

Copilot Agent Weaponized as Zero-Click Exfil Channel

CVE-2026-26144 turns Microsoft's Copilot Agent into a data exfiltration tool via an Excel information-disclosure flaw. The attack requires zero user interaction. The blast radius is everything the Copilot Agent can read — which, by design, is broad. This is the 'confused deputy' problem applied to AI assistants: a traditional flaw lets an attacker hijack the agent's execution context, and the agent's ambient permissions amplify the damage.

Two additional Office RCEs (CVE-2026-26110, CVE-2026-26113) are exploitable through the preview pane alone — a malicious document in your inbox or shared Teams channel executes code before anyone deliberately opens it. Automated document processing pipelines are also attack surfaces.

Every organization rolling out AI copilots needs to treat the agent's permission model as a security-critical architecture decision, not an IT configuration checkbox.

The Core Problem: One Prompt, Two Competing Objectives

When you ask GPT-4 to translate four lines of English filler words into Japanese, it produces one clean sentence — linguistically correct, structurally catastrophic for a subtitle system expecting exactly four timed slots. The screen goes blank for three time windows. Vimeo calls this 'the blank screen bug,' but the same class of failure hits any system piping LLM output into rigid schemas: JSON APIs, database records, form fields, code templates.

Research by Tam et al. (2024) confirms this is fundamental, not a prompt engineering problem: format constraints measurably degrade LLM reasoning quality. The more structural rules you pack into a prompt, the worse the creative output gets.

The Architecture: Separation of Concerns Applied to Prompts

Vimeo's pipeline splits into three phases, each optimizing for a single objective:

1. Smart Chunking (pre-processing): Group source lines into 3-5 line thought blocks at sentence boundaries. This gives the LLM complete semantic units without drowning it in full-transcript context, which triggers hallucination.
2. Creative Translation: Send each chunk with zero structural constraints. No line counts, no formatting, just 'produce the best possible translation.'
3. Line Mapping (separate LLM call): Take the translated block and break it into exactly N lines matching source rhythm. Pure structural task.

Separation of concerns — the oldest principle in software engineering — is the highest-leverage pattern for production LLM pipelines.

The Fallback Chain: 100% Valid Output Guaranteed

The 95% first-pass success rate isn't good enough for production. The remaining 5% enters a graduated fallback chain:

The correction loop datapoint is concrete: LLM self-correction works when the model knows what went wrong, resolving ~32% of failures. Quality degrades gracefully through the chain, but nothing ever breaks. The cost: 4-8% more latency, 6-10% more tokens — eliminating roughly 20 hours of manual QA per 1,000 videos.

Cross-Language Quality as a Production Concern

Vimeo acknowledges that structurally divergent languages (Japanese, Korean) disproportionately hit degraded fallback paths compared to Romance languages. This is an honest documentation of a real production trade-off. They made an explicit product decision: repeated subtitle text is better than blank screens. That kind of trade-off documentation distinguishes engineering maturity from 'we threw an LLM at it.'

If your architecture diagram shows a single arrow from 'user input' to 'LLM' to 'output,' you're building demo-ware. The real system is the pipeline around the model.

The Data: AI Adoption Hit 95%, But the Constraint Moved

A 340-person industry survey provides the numbers your instinct already knew. 35% of teams cite unclear/changing specs as their top slowdown — 2× the rate of QA (16%). Only 8% of engineers say tickets give them everything they need. AI adoption is near-universal (95%), but it's almost entirely applied to code production while the constraint has shifted upstream.

The asymmetry is telling: 35% understand the problem but not the success criteria, while only 13% have the inverse. Your PMs are communicating what to build but failing to specify what done looks like.

52% of Teams Have Zero Shared AI Context

This is the most technically actionable finding. Over half of engineering teams have no shared infrastructure for AI context — no AGENTS.md, no CLAUDE.md, no Cursor Rules. Each developer individually decides what context, conventions, and architectural constraints to communicate to AI tools. This is the distributed systems equivalent of running every service with a different config file.

Only 29% use shared repo files. Only 3% intentionally organize existing docs for AI consumption. Yet 48% of documentation site visitors are now AI agents according to Mintlify data. Your documentation is becoming a machine-to-machine interface whether you planned for it or not.

Treat AI context as a code artifact. Put it in the repo. Review it in PRs. Keep it updated alongside the code it describes.

Yegge's 500K LOC Ceiling Changes Decomposition Calculus

Steve Yegge puts a hard constraint on AI agent effectiveness: ~500K to a few million lines of code. Beyond that, agents can't fit enough context to be useful. This is a concrete, measurable threshold that reframes decomposition from a team autonomy argument into an AI productivity blocker.

Multiple sources confirm the convergence: AI agents amplify messy codebases rather than coping with them. Practices historically treated as aspirational — 100% test coverage, small well-scoped files, end-to-end types, fast ephemeral dev environments — are now functional prerequisites for effective AI-assisted development. Previously, cleaning up tech debt was about long-term maintainability. Now it determines whether your team can use AI tools at all.

Yegge separately claims orchestration, not model intelligence, is the bottleneck (citing Opus 4.5 as 'good enough'). His 'Dracula Effect' insight is underrated: AI eliminates easy tasks, concentrating engineers on pure high-intensity cognition — sustainable for roughly 3 hours/day at dramatically higher output. Sprint planning models built around 5-6 productive hours need recalibration.

Knowledge Management Is Now AI Context Infrastructure

64% of teams store critical knowledge in people's heads. Only 20% use ADRs. When a senior engineer leaves with the understanding of why the payment service uses event sourcing, that's not just an onboarding problem — it's an AI context problem. The AI will suggest CRUD patterns because nobody documented the decision.

Only 9% of teams use AI for requirements generation — the single highest-leverage underutilized AI application in the survey. A structured prompt that takes a ticket description and returns missing acceptance criteria, edge cases, and dependency questions could directly attack the 59% mid-cycle discovery rate.