The Stack Report: Your Nameserver Boxes Got 28 CVEs And Two Of Them Reach Postgres

The one that actually reaches your estate

PostgreSQL shipped 28 security fixes across every supported version, and that is not a number I have had to say on this show before. It is Wednesday, 26 August, and 7 days have gone by since the last one.

The number alone is not the point. Most weeks a database security release is a shrug for you, because your Postgres sits behind a container network on 10.10.11.1 and nothing on the open internet talks to it. That is still true, and it is the reason none of this is an emergency.

What makes it worth three minutes is what is IN the list. Several of these are arbitrary code execution through ordinary query paths, not through admin surfaces. A heap buffer overflow in to_char. A type confusion in cursor close and declare. A heap buffer overflow in pg_stat_statements. A stack overflow in argument matching that writes into server memory. These are reachable by anything that can run a query, which in your world means every service in the parkit family, the parpod schema, deadline, parwiki, and anything else sharing that spine.

Now the practical part, and this is where it stops being a security story and becomes a migration story.

Your box runs 18.4. The fixed line is 18.6, and the release notes say something unusual: 18.5 was never shipped, because it carried a regression. So the jump is 18.4 straight to 18.6, and there is no intermediate step to be careful about.

Three of the fixes require action AFTER the update, not just a restart, and that is the part a routine bump would silently skip. Parallel GIN index builds could leave a table's row-count estimate set to a nonsense value, including infinity, and a table in that state is never processed by autovacuum again and never fixes itself. The release ships a query that lists every table with a GIN index and its current estimate. Then there are corrections in btree_gist for float and bit columns, and an integer overflow in ltree comparisons that can present as a corrupt index. Both of those may need a reindex.

Your relevant question is not whether you use ltree. It is whether Capture's full-text search touches GIN, because it does, and Capture just finished a schema reshape where public dot items became a view over two tables. The audit is one query and it is in the announcement. That is the shape of this item: a bump, then a read of one number, then possibly one reindex.

The thing I would not do is let this ride into the next Capture phase. Migration 028 is coming, and rehearsing a migration against a prod restore on a database with a suspect row-count estimate is a way to chase a ghost for an afternoon.

Podman grew a Quadlet key you will want

Podman 6.1 landed, and one line in it is aimed directly at the shape of your fleet: Quadlet container units now support an ImageVolume key, which controls how volumes coming from an image are handled.

Every service on that box is a rootless Quadlet, and a recurring theme in your deploy work has been the seam between what is baked into the image and what is mounted at runtime. The Director library already carries a lesson about a runtime-editable file living inside an image, which is exactly the confusion this key exists to resolve. Not urgent, and nothing breaks without it, but next time a service wants a directory that comes from the image and needs to behave a particular way at runtime, this is a declared key rather than a workaround.

Two more from the same release worth knowing. Podman volume rename now exists, which it did not before. And a race condition that could cause Quadlet to generate corrupt systemd units has been fixed. That last one is the kind of fault that produces exactly one confused hour, six months from now, and no explanation.

There is also a separate 5.8.6 security release, for a flaw where the quadlet install replace command did not truncate the file it was replacing, so replacing a long file with a short one left the tail of the old content behind. Your deploys go through the floor broker, not through quadlet install, so this is almost certainly not your path. Worth checking once rather than assuming.

A speech model at 20 milliseconds, and a behaviour change that already applies to you

Inworld shipped two things, and the second one matters more than the first.

The new one is Realtime TTS-2 Flash. 20 milliseconds to first audio, five times faster than the model you actually run, the cheapest per character in the family, and the same 200-plus languages. No steering, no professional voice cloning. That means it is wrong for PärPod episodes, where directed delivery is the whole reason you are on TTS-2. But it is right for anything conversational, and the honest read is that this is a model for a product you do not have yet.

The one that applies today is the steering change from 6 August, and it changed the rules underneath you. A steering tag now applies from where it is written until you change it. Previously an inline tag affected only the text right after it, and delivery could revert on its own partway through longer text. There is a new reset tag to end a styled passage, and pauses no longer clear an active instruction.

Read that as a fix, because it is one. The old behaviour was that a tag wore off unpredictably, which is a horrible property in a rendering pipeline. But it is a behaviour change on a live path: any script authored under the old semantics, expecting an instruction to fade, now carries that instruction to the end of the passage. Your authoring guidance mostly does not use steering tags, so exposure is probably narrow. There is also a new request-level instruction field, which sets one instruction for a whole request without putting tags in the text at all. That is a cleaner fit for a per-segment renderer than inline markup ever was.

This is a listening question, not a reading question, and you have a standing rule about that. If any archived script carries an inline steering tag, the answer is a labelled render on the temp feed, not an argument in a session.

The MLX pair moved again, and the pattern is now the finding

Last week I told you the MLX core library and the vision-language library move together and do not move alone. This week they did it again, on consecutive days: core 0.32.2 on the 25th, vision-language 0.6.16 on the 24th.

I am not going to give the same warning twice. What I will say is that the twice-in-two-weeks cadence changes the conclusion. This is not an occasional coupling to watch for, it is the normal release rhythm of that pair, and anything on this Mac that pins one of them is going to hit this roughly every fortnight. That argues for pinning both together as a single unit in whatever declares them, rather than remembering.

Inside the vision-language release, the item worth your attention is a Metal buffer leak on long hybrid-model generation, fixed. Your Director library already carries the hardest-won lesson on this Mac: Apple Silicon does not kill a process that accumulates wired Metal memory, it freezes the whole machine, and it took a transcription tool doing it before anybody named it. A per-token buffer leak on long generation is the same failure family arriving through a different door. If any local batch job runs a hybrid model over long inputs, this release is the one you want under it.

Also in there: a Qwen 3.8 27B speculative decoding path, exact rather than approximate, which is the model I pointed you at last week as the local agent candidate. Speculative decoding is a straightforward speed win, and it means the candidate got faster while you were not looking at it.

Two smaller doors

Pocket ID 2.14 added support for multiple client secrets per OIDC client. That is the mechanism that makes secret rotation possible without a window where something is broken: add the new secret, move the consumers, remove the old one. Your entire estate authenticates through that identity plane, and you rotated a passphrase and re-keyed a dead Capture alert token in the past two weeks. The next rotation could be seamless instead of coordinated. Small, real, and it is a config change rather than a build.

Anthropic took the Files API, Agent Skills, and the computer use tool out of beta, and shipped a browser use tool that drives a browser your own application hosts. It reads the page structure rather than screenshotting a desktop, handles forms, tabs and downloads. Your browser QA lane currently drives a real browser through a skill, and this is the model-native version of that. Not a replacement today. Worth remembering when the QA lane next frustrates somebody.

Everything else

The Python releases from 12 August were five simultaneous maintenance versions across the 3.10 through 3.14 lines. One explanation covers all five and there is nothing in it for you.

uv shipped 0.12.6, which is mostly profile-guided optimisation for the release binaries and a pile of resolver edge cases. Faster, no behaviour change worth naming.

Codex shipped an interactive agents dashboard for searching, starting and stopping tasks, a queue command for sending messages into existing sessions, and working-directory commands in the terminal UI. Reasonable, and you already have your own version of most of it.

Astro shipped six patch releases in twelve days, all bug fixes. Your static sites are Hugo, so this one is not for you at all, and I am now wondering out loud whether Astro deserves the slot it is occupying in this show.

ElevenLabs deprecated its local MCP server in favour of a hosted one that signs in with OAuth and needs no API key. You do not use either.

DuckDB, PyTorch, Transformers, FastMCP and Scaleway all shipped, and none of it lands anywhere near what you are building. Scaleway's entry was startup probe configuration in the console and SCIM group provisioning.

If you look at one thing

Bump Postgres to 18.6 and run the GIN row-count audit query afterwards. It is 28 security fixes, three of them need a post-update step that a plain restart skips, and the audit is one query that either returns nothing or hands you a real problem before Capture's next migration does.