Wait, isn't that how everyone is building their harnesses? I actually struggle to imagine an alternative. Just keeping a a single row in the DB for chat history and always overwriting that?
Maybe I'm biased because we are primarily building a chat interface ala ChatGPT, which isn't anything different than a "remote harness". I'm not sure why one would design a local harness differently.
I think a lot of people are building their harnesses this way more recently, but last year, Claude, Codex (and other harnesses) were storing everything on a big json file on disk.
Codex has (to my knowledge) always stored sessions in append-only .jsonl files. Whether you store an append-only log in a file or a database makes no difference.
It really feels like I'm being gaslight here into believing "durable agents" are novel. All I'm seeing is the API that is behind any Chat Web UI. Persistence, resumability, recovery from errors and branching and forking have been table stakes there since the release of the first ChatGPT.
Depending on how the billing engine is deployed, and whether there are adequate controls that it's being deployed correctly, there is nothing wrong with accepting a header like this from an upstream service that produces it or verifies it in the correct manner. It only becomes an issue if the service is directly exposed to potential attackers that could use it for impersonation, e.g. a service directly exposed to the internet.
The entire Page is AI written 100%, and it's very likely DeepSeek because the prose matches my experience. I've been working heavily with DeepSeek this past week on an Architecture issue, so I read A LOT. The most obvious tell-tale of deepseek I've is long, condensed paragraphs that should've been bullet-point lists.
Parts of the exploit chain that was laid out in the blog posts that claim an RCE were bugs that have previously been reported. Dealing with them in the past in the severity you outline would have possibly prevented the exploit chain.
However, it's specifically the ability to complete this to an RCE what makes or breaks the headlines here.
The CA thing is bad, but in practice a lot more high effort to exploit. As a prerequisite the attacker has to be present on the same network, which makes any individual attack a lot more high effort. In contrast for something like PHP2Shell (if exploitable) any PHP instance exposed on the internet can be attacked by anyone from anywhere.
With a MITM, you also mainly breach confidentiality, but this doesn't directly give you an exploit chain to pwn the device (though the many auto-updaters people are using nowadays might be one).
For IOT devices, there are also factors that limit the exposure. The certs are only from 2025/2026, so few devices with them installed are likely present in any given home, and depending on the hardware footprint devices may only come with the few select CAs bundled that they require due to size constraints anyways.
This is shaping up to be the single worst security news day ever. Given the role that AI played in some of the discoveries, one has to wonder if this marks the start of some dark age of IT security.
I think this marks the beginning of the golden age. Investments in automated agent driven security scans on all software is coming to every business. Software and infrastructure will become more secure than ever before.
I also hope that we come out in a golden age, but we are very much in for a rough few months/years where all the low hanging fruit is being picked up until we end up with much more hardened systems.
Maybe I'm not enough in the weeds to see it as much, but the last few months seem to have been a much slower trickle of "how did we not catch this" exploits, while they are now appearing with much more sophisticated (though still usable in practice) exploit chains on much larger target codebases.
The last few months seem to have been a lot more imunder control with also the frontier labs more warning of "what happens when Mythos-class model get in the hands of everyone" than that actually becoming reality. Now, it appears to be actuually turning into reality.
The problem is fixing the bug and not only fixing the code, but applying the fix in production in a timely manner and without interrupting the business.
It's ok, we'll just point more LLMs at the new code and the problem will fix itself. In the mean time can we unplug the ethernet cable from the nuke silos for a while?
Code does not need to be reviewed to be secure. [^]
It needs to be designed to be secure.
[^] of course I'm hyperbolic here, it does still need to be reviewed – I just mean, review doesn't matter as much as choosing a secure design, where certain bugs just can not or will not happen.
Code review is just one of many filters. 'Secure designs' are as secure as the designer, and no designer is perfect. Implementations are as secure as the implementors and processes are not perfect either. You need these and many other layers in your filter to be secure for some arbitrary level of security where the final result is roughly proportional to how much money you are willing to expend.
So what if there are no known mitigations and it's such an open attack surface that logging doesn't help in containing it?
Since you wrote your comment the official blog posts describing what exactly is the in the exploit have been released, and "shut it all down" was definitely the right advice to give.
Maybe I'm biased because we are primarily building a chat interface ala ChatGPT, which isn't anything different than a "remote harness". I'm not sure why one would design a local harness differently.
reply