← All issues
Issue 5Week of 28 September 2026Archived

Next.js 16.3.7 is not the security release. Two labs landed on $2 and $10 a day apart.

Vercel shipped 16.3.7 on 29 September as a bug fix, then the actual security release on 30 September as 16.3.8 and 15.5.27. Two of the nine planned fixes did not make it, one critical and one high, and both are still open. Anthropic released Claude Sonnet 5.5 and OpenAI released GPT-6.1 Sol a day apart, both at $2 and $10 per million tokens, though the Anthropic cut is smaller than it looks. A critical privilege escalation landed in LiteLLM. And if you shipped a generative feature to EU users after 2 August, the output marking rule already applies to you, rather than starting in December.

This issue is a snapshot of week of 28 september 2026 and is kept as published. Figures and links were accurate at the time and are not updated retroactively. Read the current issue →

Hot takes

2

Our read on the week. Opinion, and labelled as such.

Two labs priced a day apart at exactly $2 and $10. The Anthropic cut is nearer 13 percent than 33.

Opinion
29 Sep

Anthropic released Claude Sonnet 5.5 on 28 September at $2 input and $10 output per million tokens, with cache reads at $0.20, against Sonnet 4.5 at $3 and $15 with cache reads at $0.30. OpenAI released GPT-6.1 Sol on 29 September at the same $2 and $10, with cached input at $0.10, a fifth of GPT-6 Astra at $10 and $50. The Anthropic migration guide adds a caveat the price table does not: Sonnet 5.5 uses Sonnet 5's tokenizer, and against Sonnet 4.6, Sonnet 4.5 and Haiku 4.5 the same text produces about 30 percent more tokens, depending on the content. A 2000x1500 image costs about 2.5 times as many tokens, because 5.5 uses the high resolution image tier.

So what

Do the arithmetic before you promise anyone a saving. A third off the rate, times about 30 percent more tokens for the same text, is roughly 13 percent cheaper in practice, not 33. Images get more expensive, not less. Anyone already on Sonnet 5 sees no token inflation at all, because it is the same tokenizer. Run your real prompts through the token counting endpoint, then raise max_tokens, or long outputs will start truncating at the old limit. And note where the two vendors differ: OpenAI's cached input is $0.10 against Anthropic's $0.20, which decides it if you resend a large fixed prompt.

Mistral gave one day of notice. Reddit gave six weeks. Plan for the notice you actually get.

Opinion
30 Sep

On 29 September Mistral's changelog announced that Leanstral 1.5 and OCR 4.0 were deprecated and retired on 30 September 2026, one day later, with Z.ai GLM 5.2 following on 31 October. On 30 September, according to TechCrunch, Reddit said it will retire RSS feeds on 13 November 2026 and close remaining public API access in March 2027, with third-party app and bot developers required to register before 12 January 2027. Reddit is quoted saying "We know RSS has been a beloved part of the open web for a long time". Separately, Reve says that after 27 September 2026 creating new images and videos is no longer available, with asset downloads until 31 October, and Google is reported to be retiring Gemini Gems on 17 November in favour of a skills format.

So what

Four withdrawals in one week, with notice periods ranging from one day to six weeks. The useful response is not outrage, it is an inventory. Write down every external thing your product reads or calls that you do not pay for, because a free public API is a courtesy and courtesies get withdrawn. Then rank that list by how long it would take you to replace, and fix the worst one. A hardcoded model id in a document pipeline is the cheapest thing in the world to protect and the most annoying to discover at 2am.

Post-mortems

4

What broke, and the specific thing to check in your own stack.

The Next.js security release is 16.3.8, not 16.3.7, and 15.5.27 does not fix the same things

Security
30 Sep

Vercel published 16.3.7 on 29 September. Its release notes say it is "backporting bug fixes" and list one change to the Turbopack backend, with no security content. The security release followed on 30 September: "Updates are now available in v16.3.8 (Active LTS) and v15.5.27 (Maintenance LTS)". The pre-announcement carries two dated notes, one saying 16.3.7 "does not include the security fixes planned for September 30", and one saying the release "now addresses seven vulnerabilities instead of nine. The remaining two (one critical, one high) are pending upstream coordination". The headline fix is CVE-2026-94483, server-side request forgery in Image Optimization, rated high at CVSS 8.3. The release notes for 15.5.27 list only three of the seven, so the 15.5 line does not get the SSRF fix.

So what

Upgrade to 16.3.8 on the 16.x line, and note that stopping at 16.3.7 leaves you unpatched. On the SSRF, the blog says plainly that if no images.remotePatterns are configured your application is not affected, so check that first and only audit allow-listed hosts if it is populated. Read the per-issue scoping rather than assuming: one cache poisoning item says applications deployed on Vercel are not affected, one affects only next dev, and one does not affect Turbopack builds. None of that is a blanket exemption. Then keep watching, because one critical and one high are still unfixed as of today, with no CVE, no version and no date published.

A critical LiteLLM flaw lets an ordinary user become proxy admin and run commands

Security
30 Sep

LiteLLM published three advisories. The critical one, GHSA-7hp6-4w63-5g45 at CVSS 9.9, says "An authenticated user with internal_user privileges can escalate to proxy_admin and achieve remote code execution." The root cause is that "The proxy uses one encryption key for two purposes: sealing secrets at rest and minting session tokens", so a user can have the proxy encrypt forged admin metadata and present it back as a bearer token. Patched in 1.100.4, 1.101.3, 1.102.2, 1.103.1 and 1.104.0rc2. A high severity issue published 1 October, GHSA-g5ff-637f-6q2m at CVSS 8.1, lets an authenticated user read arbitrary local files through a vertex_ai_credentials alias the blocklist missed, fixed in 1.95.0, and the advisory says "There is no reliable configuration workaround on affected versions." A moderate reflected XSS in the SSO debug callback is fixed in 1.85.0. None has a CVE assigned.

So what

Upgrade to the highest patched release on your line, then rotate. Both the critical and the high end in exposure of LITELLM_MASTER_KEY and the provider API keys the proxy holds, so after upgrading change the master key, rotate every upstream provider key, and reissue virtual keys. If you cannot upgrade today the advisory offers EXPERIMENTAL_UI_LOGIN=false, but it says that also breaks CLI SSO and Claude Code gateway login, so do not flip it blind. One range detail worth checking: 1.87.0 through 1.90.x is exploitable only if that flag was explicitly set to true, so a version below 1.91.0 is not automatically safe.

Two Zammad flaws are being actively exploited, with a KEV deadline of 5 October

Security
2 Oct

CISA added CVE-2026-102489 and CVE-2026-102490 to its Known Exploited Vulnerabilities catalogue on 2 October with a remediation deadline of 5 October. The first is a session fixation issue that "can lead to remote code execution as the zammad user", the second an improper privilege management issue that "can allow the local zammad user to escalate privileges to root", and CISA notes each can be chained with the other. The Dutch security organisation DIVD says its own systems were reached on 21 September through the pair, in its words allowing "session hijacking, remote code execution and privilege escalation from the Zammad user to root, in seconds". DIVD gives the remotely exploitable range as Zammad 6.3.0 to 6.5.4, and Zammad staff on the project forum say exploitation is only possible on 6.5 and older and that 7.0 and later are not affected by the remote execution issue.

So what

If you self-host Zammad for your support desk, update to 7.2.0 now. The 6.3.0 to 6.5.4 band is the remotely exploitable one, and 7.0 to 7.1.3 still carries the root escalation. DIVD publishes a log check script for its indicators of compromise, so run that before you assume you are clean. If anything matches, rotate what the Zammad host could reach rather than just the application: database credentials, SMTP and API keys in its environment, and any SSH or cloud credentials on that box. Note that neither CVE has a GitHub Security Advisory yet, so a dependency scanner will not catch this for you.

UpGuard says it found 16,326 Supabase databases exposing readable tables, and blames how the projects were configured

Security
1 Oct

Research from UpGuard dated 1 October says it "gathered ~300,000 unique domains with indicators of Supabase usage" and "identified 16,326 databases exposing readable tables", with "over half of the databases" showing indicators of some PII and a smaller share including passwords or authentication tokens. UpGuard attributes the exposure to application-side configuration rather than a product flaw, noting that "Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default", alongside policies that do not adequately restrict access and public keys used in client code as if they were secret. It credits Supabase with having "made product changes to implement RLS by default for tables created in the Table Editor UI". Supabase's chief information security officer Bil Harmer told TechCrunch the company provides "secure defaults and tooling, and customers control how their own projects are configured".

So what

The gap UpGuard identifies is specific and worth checking today: a table your coding agent created through the API does not get row level security by default, while one you created in the dashboard now does. Run a query over pg_class for every project and confirm relrowsecurity is true on every table in the public schema, then confirm each one actually has a policy, because RLS enabled with no policy and RLS disabled are very different states. Separately, grep your client bundles and mobile builds for a service_role key. The anon key is meant to be public. The service role key is not, and if it shipped, rotate it.

Wins

3

Rounds, launches, and benchmarks worth measuring yourself against.

GPT-6.1 Sol arrived at a fifth of GPT-6 Astra, with computer use added to the Agents API

Launch
29 Sep

OpenAI released GPT-6.1 Sol on 29 September "for complex coding and professional work at a lower cost than GPT-6 Astra". Standard pricing for prompts up to 272K input tokens is "$2 input, $0.10 cached input, $2.50 cache write, and $10 output" per million, against Astra at $10 input, $1 cached and $50 output. The context window is 1,050,000 tokens with 128,000 maximum output and an April 2026 knowledge cutoff. The same day OpenAI added computer use to the Agents API, where "Agents can complete tasks in an OpenAI-hosted browser, with website access approvals and sign-in handled by your application", and an Ultrafast mode for GPT-6 Astra through service_tier, which the changelog says has global processing and US data residency and does not support EU or other regional inference residency.

So what

If you are paying Astra rates for agentic coding, this is an 80 percent cut on the same workload if your evals hold, so run them this week. Two catches. There is still no dated snapshot id for the GPT-6 family, only the bare alias, so you cannot pin a version and should expect quiet behaviour drift. And do not route EU customer traffic through Astra Ultrafast, because OpenAI says regional inference residency is not supported there.

Cloudflare made AI Search generally available, and billing starts 1 November

Launch
1 Oct

Cloudflare moved AI Search to general availability on 1 October. The changelog says "Usage-based billing begins on November 1, 2026, with included monthly ingestion, storage, semantic query, and full-text query usage", without publishing rates or the size of those allowances. Cloudflare says it will email a reminder the week before. A quieter change sits in the same entry: Workers AI embedding and reranking calls made by AI Search are now included in AI Search pricing, and "These calls no longer appear on your Workers AI bill or in your AI Gateway logs." Artifacts, described as a versioned file system that speaks Git, entered open beta the same day for Workers Paid customers, with billing starting 14 October 2026.

So what

Diarise 14 October and 1 November if anyone wired either of these up during the free beta. The log change is the sharper operational point and it fails silently rather than loudly: a cost model that reads AI Gateway logs will start understating spend, and a monitor watching embedding call volume will see it drop to zero and may page you about an outage that is not happening. Fix those queries before 1 November.

Restate raised a $20M Series A led by Singular for durable workflow infrastructure

Funding
30 Sep

Restate announced a $20M Series A led by Singular, with Redpoint Ventures and Capital One Ventures participating. It sells durable execution infrastructure that keeps multistep processes consistent across crashes and network interruptions, and co-founder Stephan Ewen is quoted saying "You need to make sure you track exactly what you do to make it reproducible and have a consistent outcome." The company built its own storage, replication and redundancy layers rather than depending on an external database, and names Replit as a customer. For context, Temporal raised $550M at a $12.55B valuation on 18 September.

So what

This is the one round this week that maps onto a problem small teams actually hit: an agent run that dies halfway and leaves inconsistent state. Nothing to change this week, but if you are hand-rolling retry and checkpoint logic around agent calls, the durable execution category now has a funded incumbent and a funded challenger, which is the point at which it is worth a real evaluation rather than a bookmark.

On the radar

6

Shifts that have not hit you yet but will.

The EU rule on marking AI output is already live for anything you shipped after 2 August

Compliance
2 Dec

Article 50(2) of the EU AI Act requires providers of systems generating synthetic audio, image, video or text content to ensure "that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated". Chapter IV, which contains it, has applied since 2 August 2026. The Digital Omnibus on AI, Regulation (EU) 2026/1744, added a new Article 111(4) giving a transitional period to providers of such systems "that have been placed on the market before 2 August 2026", who must comply "by 2 December 2026". The same regulation deferred the high risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I. The marking duty does not apply "to the extent the AI systems perform an assistive function for standard editing or do not substantially alter the input data provided by the deployer or the semantics thereof", or where authorised by law for criminal investigation.

So what

Read the two cohorts carefully, because most coverage collapses them. If your generative feature was on the EU market before 2 August 2026, you have until 2 December. If you launched it on or after 2 August 2026, the obligation already applies and the December date is not yours. Either way the requirement is machine-readable marking, not a visible "AI generated" label, so decide this week whether you are inside the assistive editing carve-out, and if not pick a provenance scheme and book the work.

Claude Sonnet 4.5 retires on 30 November, and which platform you are on decides whether that date is yours

Deadline
30 Nov

Anthropic announced on 30 September that claude-sonnet-4-5-20250929 is deprecated, "with retirement on the Claude API scheduled for November 30, 2026", recommending claude-sonnet-5-5 as the replacement. That is roughly 60 days of notice, matching Anthropic's stated policy, and requests to a model past its retirement date fail. The deprecation page adds an important scope note: "The dates on this page apply to Anthropic-operated platforms: the Claude API, Claude Platform on AWS, and Microsoft Foundry. Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model's lifecycle status and dates can differ."

So what

Search your code and prompt configs for the pinned string, including eval harnesses and cron jobs where old model ids survive longest. The AWS wording is a genuine trap: Claude Platform on AWS is Anthropic-operated and on this clock, while Amazon Bedrock is partner-operated and is not, and both run on AWS. Check which one you actually use. Then budget time for the migration rather than a string swap, because Sonnet 5.5 rejects forced tool use, the thinking disabled setting, assistant prefill and non-default sampling parameters, each with a 400.

GitHub starts failing macOS 14 Actions jobs on Monday, and the replacements are all arm64

Breaking change
5 Oct

GitHub announced on 1 October that "The macOS 14 runner image will be retired on November 2, 2026", covering the labels macos-14, macos-14-large and macos-14-xlarge. Eight brownout windows precede it, during which jobs using macOS 14 "will temporarily fail", the first running from "October 5, 14:00 UTC to October 6, 00:00 UTC". GitHub also warns it "may reduce macOS 14 runner capacity, which could result in longer queue times" before retirement. The replacements it lists are all described as "macOS arm64 labels": macos-latest, which is macos-26, plus macos-15, macos-latest-xlarge and macos-15-xlarge.

So what

The first brownout is Monday afternoon UTC, so this is a today job. Search every workflow and composite action for macos-14 and its large and xlarge variants, including matrix entries. Then treat it as more than a label swap: the replacements are arm64, so any Intel-assuming step, Homebrew path or prebuilt binary in a mac job needs a real test run rather than a rename and a hope.

Supabase stops exposing new public tables to the Data API on 30 October, and RLS alone will not save you

Breaking change
30 Oct

Supabase's breaking change entry says new tables in the public schema will no longer be exposed to the Data API by default, "enforced on all projects on 2026-10-30". The dashboard control is named "Automatically expose new tables and functions". The entry is explicit that row level security is not the mechanism here: "Without an explicit GRANT, a role will not have access to the created table." It advises bundling GRANT statements alongside the ENABLE ROW LEVEL SECURITY and policy statements in the same migration if you use a custom migration framework.

So what

Open each project's Data API settings and note the current state of that toggle, then audit your migration template. A migration that creates a table and only enables RLS plus a policy will produce a table your client SDK cannot read after 30 October, which looks like a mysterious empty result rather than a permissions error. Add the grant to your boilerplate now. If you create tables programmatically at runtime, that code path needs an explicit exposure step.

Stripe's new API version removes payment_method_types from Checkout, Payment Intents and Elements

Breaking change
30 Sep

Stripe released API version 2026-09-30.endive on 30 September with an unusually broad set of breaking changes. Passing payment_method_types when creating a Checkout Session "now returns a 400 error", and the parameter is removed from Payment Intents and Setup Intents too, with excluded_payment_method_types and a new allowed_payment_method_types named as replacements. In Stripe.js, setting paymentMethodTypes means "Stripe.js now throws an integration error and prevents the Elements instance from being created or updated", and elements.create for the payment request button now throws, with the Express Checkout Element as the replacement. Behaviour also changed where it still works: allowed_payment_method_types "silently filters out incompatible methods" where the old parameter returned an error. Stripe publishes no end-of-life date for older API versions.

So what

Nothing breaks on a date here, because Stripe versions are pinned, which is exactly why this is easy to sleep through and expensive later. Grep for payment_method_types across server and client code and for paymentRequestButton or PaymentRequestButtonElement, then confirm your API version is pinned explicitly rather than inherited from the dashboard default. One trap when you do upgrade: snapshot_api_version can only be set when an event destination is created, so moving webhooks to a new version means standing up a parallel endpoint and making your handler idempotent while both are live.

Apple's original Developer ID authority expires on 1 February, and .pkg installers signed by it stop installing

Deadline
1 Feb

Apple posted on 1 October that "The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date." The consequence is stated plainly: "Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install." The remedy is to generate a replacement from the current authority, Developer ID Certification Authority (G2), which Apple says "is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year".

So what

This hits anyone shipping a signed Mac app, installer or CLI tool outside the App Store. List your Developer ID certificates in the developer portal and work out which came from the original authority rather than G2, then reissue, update the signing identity in your CI secrets and notarisation step, and re-sign anything you still serve for download. Set two reminders: 1 February 2027, and an annual one, because the G2 certificates expire every year.

Open the tool.

Most of what shows up in Post-mortems maps to one of ten categories the Stack Grader already checks.

Check your stack against these failures