{"id":107,"date":"2026-10-12T07:52:13","date_gmt":"2026-10-12T07:52:13","guid":{"rendered":"https:\/\/www.0xprathamesh.com\/blog\/?p=107"},"modified":"2026-10-12T07:58:58","modified_gmt":"2026-10-12T07:58:58","slug":"patch-durability","status":"publish","type":"post","link":"https:\/\/www.0xprathamesh.com\/blog\/patch-durability\/","title":{"rendered":"Patched in August, Broken in October: Measuring Patch Durability in an AI Agent Framework"},"content":{"rendered":"

On the 7th and 8th of October 2026 the PraisonAI project published sixteen security advisories. Six weeks earlier, in August, it published thirteen.<\/strong> Five component classes appear in both waves. The August fixes shipped in release 4.6.58. The October advisories affect releases up to 4.6.77, which is nineteen releases later. That gap is the subject of this article.<\/p>\n

Nineteen releases separate those two numbers. In between, the Jobs API, the MCP HTTP transport, the webhook signature path and the workspace confinement logic were all fixed, and all came back.<\/p>\n

This piece argues that the interesting measurement is not how many vulnerabilities a project has. It is how long a fixed component stays fixed. I am going to call that patch durability. I will propose four checks for estimating it before the next wave arrives. Applied to the newest fix in the batch, they find a gap that is still open.<\/p>\n

The two waves<\/h2>\n

The August batch closed thirteen advisories in a single release, 4.6.58. Read the summaries and a pattern is already visible, because two of them are explicitly repairs of earlier repairs.<\/p>\n

CVE-2026-55536 is described by the maintainers as a patch bypass of CVE-2026-40289, a browser server origin check defeated by an unanchored regular expression. CVE-2026-55537 is described as a bypass of CVE-2026-40114, webhook SSRF surviving through a DNS fail-open path. August was not a first discovery. August was already the second visit to those components.<\/p>\n

The October batch is larger and more severe. Sixteen advisories, scored from 5.3 up to 9.9, with the top entry being arbitrary file write and command execution through LLM tool calls. Fourteen carry a CVSS score. All but one affect versions up to and including 4.6.77 and are fixed in 4.6.78.<\/p>\n

Sorting both waves by the component they touch, rather than by severity, gives the comparison that matters.<\/p>\n\n\n\n\n\n\n\n\n\n
Component class<\/th>\nAugust 2026, fixed in 4.6.58<\/th>\nOctober 2026, affects up to 4.6.77<\/th>\n<\/tr>\n<\/thead>\n
Jobs API<\/td>\nNo authentication (CVE-2026-55539)<\/td>\nNo authentication plus webhook SSRF (CVE-2026-60091)<\/td>\n<\/tr>\n
MCP HTTP transport<\/td>\nOrigin validation bypass (CVE-2026-55529)<\/td>\nUnauthenticated by default (CVE-2026-61427)<\/td>\n<\/tr>\n
Webhook handling<\/td>\nSSRF via DNS fail-open (CVE-2026-55537)<\/td>\nForged unsigned events accepted<\/td>\n<\/tr>\n
Workspace confinement<\/td>\nSymlink escape<\/td>\nPath traversal reads<\/td>\n<\/tr>\n
Server auth posture<\/td>\nRecipe server auth fail-open<\/td>\nAgentOS network-exposed no-auth (CVE-2026-61426)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\"Four
Figure 1: The Patch Durability Test. Four checks applied in order to any security fix, each mapped to the PraisonAI advisory that fails it.<\/figcaption><\/figure>\n

Five classes, both waves, nineteen releases apart.<\/p>\n

Why this is not simply a bug count<\/h2>\n

A sceptical reading says that a fast moving project gets more scrutiny, so more advisories is evidence of attention rather than decay. That reading is fair and it is partly right. It does not explain the shape of the data.<\/p>\n

If a project were simply attracting new researchers, you would expect new components to appear in each wave. New components do appear. The AICoder tool call path, the deploy code generator, the SecurityPolicy backend and the prompt injection defences are all fresh in October.<\/p>\n

But the repeat classes are the ones that were examined closely six weeks earlier, by researchers who filed detailed reports and received fixes. Those are the components with the best documentation, the clearest reproduction steps and the most recent attention. If any part of the codebase should be durable, it is the part that was audited most recently.<\/p>\n

That is the signal. Not that bugs exist, but that the fix did not generalise.<\/p>\n

\"Two
Figure 2: The same component classes across both waves. August was fixed in 4.6.58. October affects releases up to 4.6.77.<\/figcaption><\/figure>\n

Patch durability as a property<\/h2>\n

Authentication asks who you are. Authorisation asks what you may do. Patch durability asks a different question entirely, and it is asked of the maintainer rather than the user.<\/p>\n

When this component was fixed, was the instance closed, or was the class closed?<\/strong><\/p>\n

An instance fix stops the proof of concept in the report. A class fix makes the whole category unrepresentable. The difference is invisible at the moment of patching, because both produce a green test and a closed advisory. It only becomes visible on the next wave, which is exactly when it is too late to act on.<\/p>\n

So the useful version of this question is predictive. Given a patch I can read today, can I estimate whether it will hold? I think there are four checks that answer it, and they can be applied to a diff in about ten minutes.<\/p>\n

Check one: Scope<\/h3>\n

Does the fix name the reported input, or the property that made the input dangerous?<\/strong><\/p>\n

A patch that adds the attacker’s exact string to a block list has closed one instance. A patch that changes how the input is parsed has closed the class. The August unanchored regex bypass is the textbook case. Anchoring that particular expression fixes that expression. The class of problems, trusting a pattern match against a structured identifier, survives anywhere else the same idiom appears.<\/p>\n

Check two: Enumeration<\/h3>\n

Is the guard a list of known bad values, or a test of a property?<\/strong><\/p>\n

Lists are finite. Properties are not. Any guard written as a set membership check will be exactly as complete as the author’s imagination at the moment of writing, and attackers get to iterate afterwards.<\/p>\n

This is the check that finds the open gap, and I will come back to it in a moment because it deserves a worked example.<\/p>\n

Check three: Default<\/h3>\n

Did the fix change the default, or only document the risk?<\/strong><\/p>\n

A documented risk is a risk that is now the operator’s fault. It is not a risk that has been removed. Most deployments run on defaults, so the default is the only configuration that gets meaningfully tested by reality.<\/p>\n

Several October advisories say “by default” directly in the summary. The MCP HTTP stream transport is unauthenticated by default. The Jobs API is unauthenticated by default. These are not obscure misconfigurations, they are what happens when somebody follows the quickstart.<\/p>\n

Check four: Reachability<\/h3>\n

Can the control be skipped entirely, rather than defeated?<\/strong><\/p>\n

The strongest guard in the world does nothing if the code path that registers it is conditional. This failure mode never shows up in a test that exercises the control, because such tests configure the control first. It only shows up when nobody configures anything, which is the common case.<\/p>\n

The worked example, and what the checks find<\/h2>\n

The newest advisory in the cluster is CVE-2026-61426, scored 8.6, covering the AgentOS server in the praisonai-ts<\/code> package. The summary states that AgentOS defaults to a network exposed no auth mode, allowing unauthenticated agent invocation and instruction disclosure. It is fixed in 1.7.3.<\/p>\n

I read the current configuration source to see what the fix did. Three things changed or did not change, and the four checks have an opinion about each.<\/p>\n

The default host moved to 127.0.0.1<\/code>. That is check three passing, and it is a genuine improvement. The common case is now safe.<\/p>\n

The default corsOrigins<\/code> remains ['*']<\/code>. That is check one in doubt. The permissive origin policy was not the reported issue, so it was not touched, even though it widens the consequence of any binding mistake.<\/p>\n

The new protection is a guard that refuses to start when the server is exposed without an API key. It is implemented as a set membership test against three literal strings: 0.0.0.0<\/code>, ::<\/code> and ::0<\/code>. If the host is in that set and no key is configured, it throws.<\/p>\n

That is check two failing, visibly, in the shape of the code. The guard enumerates three spellings of “any address”. There are more than three.<\/p>\n

I ported the merge and guard logic into a standalone script and ran it against a spread of host values to confirm the reading rather than assume it. The output is unambiguous.<\/p>\n

A bind to 0.0.0.0<\/code> with no key throws, as intended. A bind to 192.168.1.50<\/code> with no key starts and serves, because a specific LAN address is not in the set. It remains reachable by everything on that network. A bind to [::]<\/code> in bracketed notation starts and serves. A bind to ::ffff:0.0.0.0<\/code>, the IPv4 mapped form of the same any address, starts and serves. In every one of those cases the authentication middleware is never registered at all, because its registration is conditional on an API key being present.<\/p>\n

That last detail is check four. The guard and the middleware are two separate decisions keyed off the same missing value, and when the guard does not fire, the middleware simply does not exist.<\/p>\n

Configuration is not consequence, so I built a small server mirroring the real middleware order. I bound it to the any address with no key and queried it. An unauthenticated request to the agent listing returned the agent definitions, including the instruction text. An unauthenticated request to the chat endpoint invoked the agent. A cross origin request received permissive access control headers.<\/p>\n

I then ran the same server with a key configured as a control. Every endpoint returned 401. The control matters more than the finding, because without it a test that returns data proves nothing about the code and only proves the harness is broken.<\/p>\n

The full reproduction, including the harness source, the request transcripts and the control run, is written up separately in Reproducing the AgentOS Auth Guard Gap<\/a>.<\/p>\n

What to do if you run this<\/h2>\n

Upgrade. 4.6.78 for the Python package, 1.7.3 for praisonai-ts<\/code>. Sixteen advisories is a strong argument on its own.<\/p>\n

Then do the thing the upgrade does not do for you. Set an API key explicitly rather than relying on the guard to notice that you need one. Set the bind host explicitly rather than inheriting it. Set corsOrigins<\/code> to the origins you actually use. None of these are difficult, and all of them are outside the scope of the patch.<\/p>\n

The general form is harder. If you depend on an agent framework, the component list is the useful artefact from a wave like this, not the CVE list. The components that broke twice are the ones to put an external control in front of, because the third wave will probably touch them too.<\/p>\n

The uncomfortable part<\/h2>\n

I want to be careful about what this analysis does and does not show.<\/p>\n

It does not show that PraisonAI is unusually bad. It shows something less comforting. A project doing the right things visibly, triaging reports, shipping fixes quickly, crediting researchers and publishing detailed advisories, still had five component classes come back within six weeks. The projects that do none of that do not produce this data at all, so they cannot be measured this way.<\/p>\n

It also does not show that the maintainers made careless fixes. The exposedHosts<\/code> guard is a reasonable piece of code. It would pass review. It handles the case in the report, and the case in the report is the one with a working proof of concept attached. Writing a guard that enumerates the obvious values is what everybody does under time pressure, and the gap only becomes obvious when you deliberately go looking for the fourth spelling.<\/p>\n

That is the actual lesson, and it generalises well beyond this one project. Patch durability is low by default, because the incentive at patch time is to close the report, and the report contains one input. Nobody is graded on the inputs that were not sent.<\/p>\n

One question belongs in every security review, in writing: did we close the class? Until it is asked, the next wave will keep containing the last one.<\/p>\n

One next action<\/h2>\n

If you maintain an agent framework, or depend on one, take the most recent security fix in your own codebase and run check two against it. Find the guard, and ask whether it tests a property or enumerates values. If it enumerates, write down the fourth spelling you did not include.<\/p>\n

This class of problem is why I built AgentCrash<\/a>, an open source harness for breaking AI agent deployments before somebody else does. It is on PyPI, it is public, and it takes a few minutes to point at a target you own.<\/p>\n

Frequently asked questions<\/h2>\n

What is patch durability?<\/h3>\n

Patch durability is the property that a fixed component stays fixed. It asks whether a patch closed the specific reported instance or the whole class of problem that made the instance possible. It is measured retrospectively by seeing whether the same component class produces new advisories in a later wave, and estimated prospectively using the four checks of scope, enumeration, default and reachability.<\/p>\n

Which PraisonAI versions are affected and what should I upgrade to?<\/h3>\n

The October 2026 advisories affect PraisonAI versions up to and including 4.6.77 on PyPI, fixed in 4.6.78. The AgentOS advisory CVE-2026-61426 covers the npm package praisonai-ts below 1.7.3, fixed in 1.7.3. The earlier August wave was fixed in 4.6.58.<\/p>\n

Which component classes appeared in both the August and October 2026 waves?<\/h3>\n

Five classes appear in both waves: the Jobs API authentication and webhook SSRF path, the MCP HTTP transport, webhook signature verification, workspace confinement and path traversal, and a further uncategorised pair. The August fixes shipped in 4.6.58 and the October advisories affect up to 4.6.77, which is nineteen releases later.<\/p>\n

Does upgrading to the patched AgentOS version fully solve the authentication problem?<\/h3>\n

It solves the default case, because the default bind host moved to 127.0.0.1. It does not cover every exposed bind. The start up guard tests the host against a set of three literal strings, so a bind to a specific LAN address, to the bracketed IPv6 any address, or to the IPv4 mapped any address does not trigger it, and the authentication middleware is only registered when an API key is configured. Operators should set an API key explicitly rather than relying on the guard.<\/p>\n

How do I apply the four checks to a patch in my own codebase?<\/h3>\n

Read the diff and ask four questions in order. Scope asks whether the fix names the reported input or the property that made it dangerous. Enumeration asks whether the guard tests a property or lists known bad values. Default asks whether the default configuration changed or the risk was only documented. Reachability asks whether the control can be skipped entirely rather than defeated, which usually means checking whether its registration is conditional.<\/p>\n

Does a high advisory count mean a project is insecure?<\/h3>\n

Not on its own, because a high count can indicate active research attention and responsive maintainers. The more informative signal is repetition. New components appearing in a wave is expected. Components that were audited and fixed six weeks earlier appearing again suggests the fix addressed an instance rather than a class.<\/p>\n

Sources<\/h2>\n