Patch Cadence Belongs on the Evaluation Sheet
Vulnerabilities in coding agents are no longer news in themselves — this site covered Manifold's GitSpawn disclosure on September 7 and LiteLLM's entry in CISA's exploited-vulnerabilities catalog on September 8. The value here is elsewhere: it puts the handling of one class of problem at different vendors side by side — about a week, versus about 50 days. That comparison matters because it measures the response mechanism rather than whether a particular release had a bug. For a team putting coding agents into daily development, the risk actually carried is not "does it have vulnerabilities" (it does) but "how long after a report until one is fixed." And that metric appears on no feature comparison, no pricing page and no benchmark leaderboard. The detail about roughly 30 updates shipping during those 50 days is the sharpest part: product iteration was proceeding normally, so what was backlogged was not engineering capacity but priority.
Two Boundaries to State Clearly
First, the discloser has a commercial motive. Accomplish is a security startup in stealth, and publicizing problems across a competitor ecosystem also builds its own narrative. That does not weaken the technical findings, but the conclusion "this vendor patches slowly" comes from someone building a business in exactly this area, and a reader should know that. Second, Avner's claim that attackers may already have exploited the gaps during that window has no public evidence behind it. By this site's convention that is an unverified inference and cannot be written as fact. What is actually established is narrower: the flaws existed, they were privately reported, and the time to fix differed.
Four Teams Pointing at One Structural Problem
Line up the disclosures from this window and they are describing the same thing. Manifold's GitSpawn is a repository's own git configuration naming a command that executes when the agent calls git in the background. Pillar Security looked at files the agent itself generates, later processed by trusted host software — researchers explicitly call that a trust problem rather than a classic sandbox escape. Cymulate summarizes it as systemic weakness in isolation, configuration, and trust in model- or user-controlled input. The common thread: these boundaries were drawn around "will the model request permission" rather than "who on this path is actually executing." Which is why the sandbox appears to be present and still leaks. Some executable steps for teams: treat a coding agent as a service that will execute untrusted input — give it its own credentials rather than your personal ones, configure least privilege, put egress behind an allowlist, and do not open externally delivered repositories on a machine with direct access to production credentials. Also add "the vendor's vulnerability response time" to your procurement questions: is there a published security contact, and is there a committed response and remediation window. Those two are less work than chasing any individual CVE.
via: Upstarts Media, Cymulate on configuration-based sandbox escape, Cloud Security Alliance research note on AI coding agent sandbox escapes