DEV Community: Qasim Parray

Uptime Kuma Docker Setup: What I Change Before Trusting It

Qasim Parray — Thu, 05 Nov 2026 16:39:40 +0000

I found out a client's site had been down for six hours the way nobody wants to: the client told me. A WhatsApp message at breakfast, one line, no greeting. The server was fine. A certificate renewal had failed quietly, the browser was throwing a full-page warning, and my only monitoring was me occasionally opening the site and thinking "looks okay."

That was the week I stopped treating monitoring as a someday task. I wanted something I could host myself, that cost nothing per monitor, and that I could set up in an evening. Uptime Kuma fit. It is also very easy to install badly, which is the part most tutorials skip.

Short version for the impatient: the default Docker setup works, but I change four things before I trust it with a client's name on the status page. Where it runs, who can reach port 3001, how I get alerted when the monitor itself dies, and what I do with the data folder. The rest of this post is those four, in the order I get bitten by them.

What the default compose file gives you

The project's README shows the fastest path: make a folder, download a compose.yaml, run docker compose up -d. I checked the file as it stands today and it is short.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "3001:3001"

That's the whole thing. One container, one bind mount for state, one port. It pins to the major version 2 tag, so you get minor updates when you pull but not a surprise jump to a different major release. I like that default. I have been burned by latest before, and not only with this tool.

What you get on first launch is a pleasant surprise if you have used paid monitors. HTTP and keyword checks, TCP, ping, DNS, a push monitor for cron jobs, and a Docker container monitor. Check intervals go down to 20 seconds. Notifications can go to Telegram, Discord, Slack, email and, according to the README, more than 90 other services. Multiple status pages, each mappable to its own domain. That covers what most small agencies pay a monthly fee for.

The setup is fine for a laptop. It is not fine for a VPS with a public IP, and the reason is on the ports line.

Port 3001 is open to the world

Writing "3001:3001" in a compose file binds the port on every network interface. The README says as much: Uptime Kuma is now running on all network interfaces. On a home machine behind a router, nobody cares. On a Hetzner box with a public address, you have just put an admin login on the internet at a predictable port, and the first thing the setup screen asks you to do is create the admin account.

I have seen people leave that screen open for a day. Whoever loads it first becomes the admin. That is a bad race to run.

The README mentions the fix itself: limit exposure to localhost. In compose terms that is one extra prefix.

    ports:
      - "127.0.0.1:3001:3001"

Now the container only answers on the loopback interface. To reach the dashboard you need something in front of it. I use a reverse proxy with automatic certificates, and if you are choosing between the common options, I wrote up how Caddy and nginx compare on a small VPS. The Caddy config for this is two lines: the hostname, then a reverse_proxy 127.0.0.1:3001. Done.

If you would rather open no inbound ports at all, a tunnel works too. I covered that route in the Cloudflare Tunnel post. Either way, the dashboard belongs behind a hostname with TLS, not an IP and a port number.

One more thing on the first-run screen. Create the admin account immediately, pick a long passphrase, and turn on two-factor auth. The README lists 2FA as a built-in feature, so there is no excuse. It takes a minute and it removes the most likely way someone else ends up owning your monitor.

The monitor cannot watch itself die

This is the mistake I made first, and it is the one that matters most.

If Uptime Kuma runs on the same server as the sites it watches, then a dead server takes out both the sites and the thing that was supposed to tell you. Your phone stays silent. Silence looks exactly like "everything is fine." I only noticed my version of this because a test outage produced zero alerts, which was embarrassing, since I had caused the outage on purpose.

There are two fixes, and I use both.

The first is location. Run Uptime Kuma on a different provider or at least a different machine from the thing it watches. A cheap second VPS in another datacenter is enough. It does not need much: the process is a single Node app with a small database behind it, so it will sit comfortably on the smallest plan most providers sell. If your sites are on one host, put the monitor somewhere else. That is the entire rule.

The second is a heartbeat going the other way. Uptime Kuma has a push monitor type: instead of the tool calling out to a URL, something calls in to a URL it generates, and if the call stops arriving, the monitor goes red. I point a tiny cron job at it from the box that runs Uptime Kuma, and I watch that push monitor from a free external ping service. Now if the monitor machine dies, something else notices. It sounds like turtles all the way down, but you only need one level of it. A free tier at an outside service is plenty for a single check.

A smaller version of the same mistake: alerts that go to an email address on the domain you are monitoring. When the mail server is down along with everything else, the alert never lands. Send to Telegram, or a personal address on a different domain. I use a Telegram bot for anything urgent because the notification arrives on my phone within seconds and I cannot sleep through it as easily as an email.

Tuning the checks so you trust the alerts

A monitor that cries wolf gets muted. A muted monitor is worse than none, because you think you have coverage.

My first week I left every check at the lowest interval and every alert on the first failure. A single dropped packet paged me at 3 a.m. The fix is dull. Set retries to 2 or 3 before a monitor flips to down, and keep the interval at a minute for client sites, longer for anything internal. A 20-second interval is available, and I use it for exactly one thing, a payments endpoint where thirty seconds of downtime has a price.

Check what the monitor actually checks, too. An HTTP monitor that accepts any 2xx will happily report "up" for a site that now serves a blank page or a maintenance banner. For client sites I switch to a keyword monitor and look for a string I know sits in the footer or the page title. If the string disappears, the page broke, even when the server still answers 200. That one change caught a broken deploy for me before the client noticed, which made up for the six hours of embarrassment.

Certificates deserve their own monitor. Uptime Kuma shows certificate info and can alert before expiry. Turn it on for every HTTPS check. It would have saved me that breakfast message.

Backups and updates for the data folder

Everything the tool knows lives in the ./data directory from the compose file: the database, your monitors, your notification settings. Lose it and you rebuild by hand from memory. The README also warns that network file systems like NFS are not supported for this path, so keep it on local disk or a normal volume.

I back that folder up with the same job that handles the rest of my small servers, a nightly copy off the machine. If you have not set one up, the Docker Compose services reference is where I would start for understanding how the bind mount and restart policy fit together. The unless-stopped policy in the default file means the container comes back after a reboot, but it will stay down if you stopped it on purpose. That is the behavior I want.

For updates I do it manually and on a schedule. Pull the new image, recreate the container, look at the dashboard, done. The project keeps update instructions on its wiki, and I read the release notes before any major jump. Because the compose file pins to the major tag, a routine pull stays inside version 2.

Do one restore test, even a rough one. Copy the data folder to a scratch machine, start a container against it, and confirm your monitors show up. Mine took ten minutes and found that I had forgotten to include the folder in the backup job at all. I would much rather learn that on a Tuesday afternoon than during an outage.

What I would do this week

If you run client sites and have no monitoring, set up Uptime Kuma on a machine that is not the one hosting those sites. Bind it to localhost, put it behind a hostname with TLS, and create the admin account with 2FA before you do anything else. Add one keyword monitor and one certificate check per site, then route alerts to Telegram.

Then break something on purpose. Stop a site, wait for the alert, and time how long it takes to reach your phone. If it never arrives, you just found the real work. I do this kind of setup for small teams as part of my freelance engineering work, and the failed test alert is the single most common thing I find on day one.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

iframe Sandbox Lessons From the ChatGPT Account Takeover

Qasim Parray — Wed, 04 Nov 2026 16:39:31 +0000

I have a confession about iframes. For years I treated the sandbox attribute like a seatbelt: I clicked it in, felt safe, and never once asked what the car was doing. Then I read Simon Willison's link post about how researchers took over ChatGPT accounts and realised the seatbelt was fine. The problem was a door nobody had locked, three feet away.

Short version for the impatient: the sandbox held. The attack worked because the parent page had a message handler that wrote whatever it received into the DOM with innerHTML, and it never asked who was talking. If your app embeds untrusted HTML and also listens for postMessage, that handler is the thing to audit this week, not the iframe attribute.

I'll walk through the chain as Simon summarised it, then show the handler pattern I now use in my own code. I'm working from his write-up and not from the original researchers' report, so treat my account of the details as a summary and go read the sources yourself.

What the attack chain actually did

ChatGPT lets you preview interactive HTML apps in a sandboxed iframe. That's the same idea as the artifacts pattern you may have seen elsewhere. The point of the sandbox is that the HTML inside is untrusted. It might be written by a stranger, shared through a link, and opened by you while signed in.

According to Simon's summary, the researchers at Parameter Labs found a chain of small problems. The parent page used the MathLive library for graph support, and MathLive ships its own virtual keyboard. That keyboard can be triggered in the parent page through postMessage(). The receiving code used innerHTML, so anything able to send a message could push HTML into the parent. Nothing stopped a sandboxed preview frame from sending one.

Inserting HTML is not the same as running script. innerHTML won't execute a <script> element you hand it. But it will happily create an <iframe>, and a new iframe created by the parent has no sandbox unless the parent adds one. So the attacker got an unsandboxed frame inside the page.

Then came the content security policy. It blocked inline scripts and only allowed scripts from a short list of domains. One of those domains was YouTube, and the YouTube oEmbed endpoint could be coaxed into reflecting JavaScript back in a form that ran. With script running on the ChatGPT origin, fetching private data from the APIs and sending it out through an image request was, in Simon's word, trivial. Share a link, wait for a signed-in person to open it, collect their data.

I find the shape of this more useful than the specific bug. Four separate decisions, each defensible in a code review on its own, added up to account takeover. A message handler that trusts its sender. A DOM write that accepts markup. A frame that inherits no restrictions. An allowlist entry for a big, friendly domain. Remove any single one and the chain breaks.

Why the sandbox attribute wasn't the problem

The sandbox attribute did its job. A sandboxed frame without allow-same-origin gets an opaque origin, so it can't read the parent's cookies or storage, and it can't touch the parent's DOM directly. What it can still do, if you let it run scripts, is call window.parent.postMessage(). That channel is deliberate. It's the supported way for a restricted frame to talk to the page around it.

So the real question is what your page does when a message arrives. Think of that handler as a public API endpoint, because functionally it is one. Any frame that can reach your window can call it, including frames you never meant to host.

Here's the pattern that worries me:

// Before: trusts every message from every frame
window.addEventListener('message', (event) => {
  const { type, html } = event.data;
  if (type === 'show-keyboard') {
    document.getElementById('kb').innerHTML = html;
  }
});

Nothing here checks event.origin. Nothing checks event.source. The payload shape is whatever the sender says it is. And the innerHTML write means the sender controls markup, which is the exact step the researchers needed.

A handler I would actually ship

The MDN documentation for postMessage is blunt about this: always verify the sender's identity using the origin and possibly source properties, and be wary of what you do with the data. Here's my current version, rewritten after reading the ChatGPT write-up:

// After: known sender, known shape, no markup from outside
const KEYBOARD_ORIGIN = 'https://app.example.com';
const keyboardFrame = document.getElementById('keyboard-frame');

window.addEventListener('message', (event) => {
  if (event.origin !== KEYBOARD_ORIGIN) return;
  if (event.source !== keyboardFrame.contentWindow) return;

  const data = event.data;
  if (!data || data.type !== 'show-keyboard') return;
  if (typeof data.layout !== 'string') return;

  const layouts = { numeric: 'numeric', text: 'text' };
  const layout = layouts[data.layout];
  if (!layout) return;

  document.getElementById('kb').dataset.layout = layout;
});

Four things changed. The handler compares the origin against one exact string, not a prefix and not endsWith. It also compares event.source to the specific frame I expect, because two different frames can share an origin. The payload is validated against a closed set of values. And nothing from the message ever becomes markup. It becomes a data- attribute that my own CSS reads.

That last change is the one that matters most. If a handler needs to render something the sender supplied, use textContent, or build elements with createElement. If it genuinely has to accept markup, run it through a sanitizer such as DOMPurify and then think hard about whether you really needed markup.

One more trap with sandboxed frames: their origin is the string "null". If you ever write if (event.origin === 'null') to accept messages from a sandboxed preview, you've just accepted messages from every sandboxed frame on the internet. It's an easy line to write when a preview pane refuses to load, so search your code for it. The fix is checking event.source against a frame reference you created, because origin can't tell opaque frames apart.

The combination that disables your own sandbox

While I'm confessing, here's the other classic. The MDN iframe reference warns that combining allow-scripts and allow-same-origin on a frame whose content is served from your own origin lets that content reach into the parent and remove the sandbox attribute entirely. It's a one-line escape. People add both flags because the embedded app breaks without same-origin access to local storage, the app starts working, and the ticket closes.

If you host user-supplied HTML, serve it from a different registrable domain, not just a different subdomain, and keep allow-same-origin off. Separate origin for untrusted content is the boring, old, reliable answer. Google, GitHub and others have used the same trick for years for exactly this reason.

My rule of thumb now:

<iframe
  src="https://preview.example-usercontent.net/abc123"
  sandbox="allow-scripts"
  referrerpolicy="no-referrer"
  loading="lazy"
></iframe>

Scripts allowed, nothing else, different site entirely. If the preview needs forms or popups I add those flags one at a time and write down why in the commit message.

The allowlist entry nobody reviews

The detail in the story that bothers me most is the YouTube entry in the CSP. I'd have waved it through too. Embedding videos is a normal product need, and YouTube is not a hostile domain. But a script-src allowlist trusts everything that domain will serve, including endpoints that reflect input. Large shared domains tend to have many such endpoints.

If you want a stricter setup, nonce-based CSP with strict-dynamic avoids the host allowlist problem altogether. I wrote about the nonce route, and the one inline style attribute I couldn't lock down, in my React security post. It isn't free. Nonces mean server-rendered headers and some careful plumbing. But a host allowlist has a failure mode you can't see from the policy text, and a nonce doesn't.

I also want to say something about the bounty. Simon points out that the reported $5,000 payout seemed low for a bug that could expose a signed-in user's private data. I agree with him, with the caveat that I don't know the programme's rules or how OpenAI scored it. The takeaway for me is practical: a payout doesn't tell you how much the bug would have cost if someone less friendly found it first.

Things to do this week

Open your codebase and search for addEventListener('message' and onmessage. Every hit is a trust boundary. For each one, answer three questions: who can send to this window, what happens if they lie about the payload shape, and does any value end up in innerHTML, outerHTML, insertAdjacentHTML or document.write?

Then search for sandbox= and look for any frame carrying both allow-scripts and allow-same-origin. If the content in that frame isn't entirely yours, you have the same shape of problem the researchers exploited. I do this kind of review for clients, and you can see what I work on.

Do the grep before lunch tomorrow. Fix the worst innerHTML first, because that single change would have broken the chain described above.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Postgres Restore Drill: What a Green pg_dump Exit Code Proves

Qasim Parray — Sun, 01 Nov 2026 08:39:15 +0000

Short version for the impatient: a pg_dump that exits with code 0 tells you the dump finished. It doesn't tell you the dump restores, and it says nothing about whether the restored database has your data in it. The only way to know is to restore it somewhere disposable and look.

I've been thinking about this since two Postgres announcements landed on postgresql.org in the same week. BackupDrill is an open-source CLI for Supabase projects that restores each backup into a throwaway container. SafeGrd does a similar thing as a service. Two separate projects shipping the same idea in a week tells me a lot of people are tired of finding out about broken backups on the worst possible day. I haven't used either one yet. What follows is the DIY version I'd build first, so you can judge what the tools add.

What a green pg_dump actually proves

Not much. When pg_dump exits cleanly, you know it connected, read the catalogs, streamed table data, and wrote an archive to disk. The pg_dump documentation is clear that it takes a consistent snapshot, which is great, but consistent isn't the same as restorable.

Here are the ways a successful dump still fails you. The archive can be truncated if the disk filled up and your script ignored the error from a pipe. The dump can come from a role that couldn't see some schemas, so those schemas are silently missing. A dump from a newer major version can't be restored by an older pg_restore, so a staging box on an old version can tell you nothing about a production archive. And if your cron job redirects errors to a log nobody reads, a run that dumped zero rows looks identical to a good one.

Notice the pattern. Every one of those failures happens at dump time and surfaces at restore time, which is months later. That gap is the whole problem.

Here's what BackupDrill says its drill checks, according to the announcement: the archive checksum, that pg_restore completed, that post-data objects like indexes, constraints and triggers were created, that every table is present, and that tables which held data aren't empty. It also records how long the restore took. I like that list because it's specific. It goes past "the command returned 0" and asks what a restored database should look like.

A restore drill in about twenty lines

You don't need a product for the first version. You need Docker, a dump file in custom format, and a script that fails loudly. Custom format (pg_dump -Fc) matters here, because pg_restore can list and selectively restore from it, and plain SQL dumps can't do that.

#!/usr/bin/env bash
# restore-drill.sh /path/to/backup.dump
set -euo pipefail

DUMP="${1:?path to a pg_dump -Fc file}"
NAME="drill-$$"

docker run -d --rm --name "$NAME" -e POSTGRES_PASSWORD=drill postgres:17 >/dev/null
trap 'docker stop "$NAME" >/dev/null' EXIT

until docker exec "$NAME" pg_isready -U postgres >/dev/null 2>&1; do sleep 1; done
sleep 3   # the image runs a temporary server first; see the gotcha below

docker exec "$NAME" createdb -U postgres drill

start=$(date +%s)
docker exec -i "$NAME" pg_restore -U postgres -d drill \
  --exit-on-error --no-owner < "$DUMP"
echo "restore took $(( $(date +%s) - start ))s"

docker exec "$NAME" psql -U postgres -d drill -At -f - <<'SQL'
select 'tables', count(*) from pg_tables where schemaname = 'public';
select 'indexes', count(*) from pg_indexes where schemaname = 'public';
select 'triggers', count(*) from pg_trigger where not tgisinternal;
SQL

A few choices in there deserve a defense. --exit-on-error makes pg_restore stop at the first failure, instead of its default of printing errors and carrying on, which is how a half-restored database ends up looking fine. --no-owner avoids a flood of errors about roles that exist in production and not in the throwaway container. You lose the ownership check, and I think that's an acceptable trade for a drill. The pg_restore reference lists both flags if you want to read the details.

Now the gotcha I promised. The official postgres Docker image starts a temporary server to run its init scripts, shuts it down, then starts the real one. pg_isready can report success against the temporary server, and your next command then lands in the gap between the two. The sleep 3 is ugly. A cleaner fix is to retry createdb in a loop, and I'd do that in anything that runs unattended.

Match the major version of the container to the server you dump from. Restoring a dump from Postgres 17 into a 15 container is the kind of mismatch a drill should catch, and that's the point, but then the failure tells you about your drill and not about your backup.

Counts are not enough

The script above prints table, index and trigger counts, and those numbers only help if you know what they should be. So record the expected values at dump time and compare. The cheapest version is to write a small manifest next to every dump:

psql "$DATABASE_URL" -At -c "
  select 'orders', count(*) from orders
  union all select 'customers', count(*) from customers
  union all select 'invoices', count(*) from invoices
" > backup-2026-10-29.manifest

After the drill restores, run the same query against the container and diff the two files. Use exact count(*) for the tables that matter and skip pg_stat_user_tables.n_live_tup, which is an estimate and will drift from the real number. The numbers won't match if rows were written between the dump and the manifest, so generate both back to back on a quiet system, or accept a tolerance and say so in the script.

Table counts catch missing data. They don't catch wrong data. For the one or two tables a business can't lose, I'd add a single spot check that mirrors something a human cares about, like the sum of invoice totals for last month. If that sum is off by a cent after restore, you want to know before a client asks.

Also compare sequences. pg_dump records sequence values, so last_value should match between source and restore. If it doesn't, you have a partial restore that still passes every row count and then fails on the first insert with a duplicate key error. It's a small query, and I'd rather run it in a drill than discover it in production.

Where the tools fit

Once you have the script above, the interesting question is what BackupDrill and SafeGrd would add, and the answer is mostly scheduling, storage and alerting. BackupDrill's announcement describes backups streamed to any S3-compatible bucket (S3, R2, Backblaze B2, Wasabi) with a checksummed manifest, plus a hosted service that runs drills on a schedule and sends email alerts when one fails. SafeGrd describes age encryption on your host before upload and Object Lock on the bucket, which protects backups from deletion, and that's a real concern the script above ignores.

I'd think hard about scope before adopting either. BackupDrill covers Supabase-hosted Postgres only for now, per its own announcement, and dumps the public schema by default. If you run Postgres on a VPS, that rules it out today. SafeGrd supports Postgres 13 and later and lists Supabase, Neon and RDS from a connection string, which is broader. In both cases you're trusting a third party with the one job where being wrong is expensive, so read what leaves your host and who holds the keys. SafeGrd says the backup data doesn't go through its servers, and that's the right claim to want. I'd still test it with a database I can afford to lose.

If you already run your own backups on a small server, I wrote up retention and restore testing in my restic and Postgres dump post. The drill in this post slots in after that pipeline, as the step that proves the files are usable.

Making it a habit

A drill that runs once teaches you very little, so schedule it. On a small box a systemd timer or a cron entry is plenty. I do this kind of operational hardening for clients, and you can see the sort of work on my portfolio. The pattern is always the same: the backup job and the drill are separate jobs, and the drill alerts you when it fails, not when it passes. A passing drill that emails you every night trains you to ignore it.

Two decisions to make up front. How old a backup can be before you consider it a failure? And how long a restore can take before you consider it a failure? The second one is the number people skip, and it's the one that matters during an outage. If your restore takes 40 minutes, your recovery objective is at least 40 minutes, whatever the plan on paper says.

This week, take your most recent dump and run the script above against it on your laptop. Time the restore, write the number in your runbook, and note the first thing that goes wrong. Something will.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Next.js Bundle Analyzer in 16.4: The Import That Defeats Lazy Load

Qasim Parray — Sat, 31 Oct 2026 16:39:13 +0000

Confession: bundle analyzers are the tool I know I should open more often and mostly don't. The usual finding is something small and slightly embarrassing, like a date library imported for one format() call and sitting in the initial chunk of a page with no dates on it. You fix it, feel smug for a day, and forget to check again until someone complains about load time.

So when the Next.js team published Ship less JavaScript in Next.js with your AI agent on 28 October, I read it twice. Short version for the impatient: Next.js 16.4 adds an agent skill and a better next analyze, and the most useful idea in the post is a boring one about imports that quietly undo each other. I haven't run the skill on a production app yet, so this isn't a review. It's what I would check first, and why I'm more interested in the analyzer than in the agent bolted onto it.

The lazy import that never deferred anything

Here is the example from the Next.js post, nearly verbatim in spirit. You have a heavy component and you want it out of the initial bundle, so you wrap it:

// HeavyComponentLoader.js
'use client';
import { lazy } from 'react';

export const HeavyComponentLoader = lazy(() => import('./HeavyComponent'));

That looks right. React's lazy documentation says the code for a lazy component isn't loaded until it first renders, and the Next.js lazy loading guide says much the same about next/dynamic. Both are true. The catch is that the bundler works on the whole module graph, not on your intentions. If any other module in the same bundle does this:

// Toolbar.js
import HeavyComponent from './HeavyComponent';

then HeavyComponent is part of the initial chunk anyway, and your lazy wrapper becomes a decoration. One static import, three folders away, written by someone who never saw your loader. The bundle doesn't warn you. Lighthouse just gets a little worse and nobody connects it to a pull request from last month.

Picture a chart library that is lazy loaded on a reports page, which feels like a good job done. Then someone adds a small summary card to the home page that imports one helper from the same chart file, and the whole library moves into the shared chunk. You'd stare at the lazy call for an hour, because the lazy call is fine. The bug is somewhere else entirely. I haven't been bitten by this exact case on a client project, but it's the shape of bug I'd expect to find in any app with more than one contributor.

The old way to find this was to open a treemap, spot the big rectangle, and then grep the codebase for every place that imports it. It works. It's also slow, and you only do it when someone is already complaining about load time.

What next analyze gives you without any agent

Before the agent part, the human tooling. In 16.1 the team shipped the first Turbopack Bundle Analyzer, and 16.4 adds a few things that matter more than the headline. You run next analyze in your app directory, and you now land on a route summary that lists your largest client routes. Open one and there's a table you can sort by size, with each source marked as initial load, behind an async boundary, or both.

That last label is the one I care about. A module marked "Initial + async paths" is exactly the lazy-import bug above: it's loaded lazily from one place and eagerly from another. In the post's illustrative blog app, a search component sits at 18 kB with that label. You can see the problem in one row, without reading a treemap.

Two more features I'd use right away. The analyzer now saves a snapshot of each analysis automatically, and you can diff two snapshots, which gives you a before and after for any change. The post's example goes from 123 kB to 81 kB on one route, with a per-file table of what moved. And there's a filter for the critical render path, so you can hide async dependencies and look only at what blocks first paint.

I'll be blunt about one limitation. All of this needs Turbopack, because the analyzer relies on its module graph. If you're on 16 or later, that's the default and you won't think about it. If you pinned webpack for a plugin that doesn't work elsewhere, you stay with the older webpack bundle analyzer and none of this applies to you yet.

What the agent skill adds

The skill is installed with npx skills add vercel/next.js --skill next-bundle-optimizer and run with /next-bundle-optimizer. According to the post, it exports saved analyses as JSON, rebuilds the module and chunk graphs, finds large groups of connected modules, and uses a minimum cut to pick a small set of import boundaries that would defer them. Then it checks those proposals against your source code and how the components are used.

The minimum cut is the clever part, and it's a good fit for the problem. "Which handful of imports, if I changed them, would let this whole cluster load later?" is a graph question. It's the question I answer badly by hand, because I follow the first import chain I find and stop. A tool that looks at every chain at once will beat me on that, and I have no pride about it.

By default it only reports. You have to run /next-bundle-optimizer fix to have it apply changes, re-run the analysis, and compare snapshots. I like that default. It means the first run on a client codebase is read-only, and I can bill the findings as an audit before anyone touches a file.

The numbers in the post are large. Across v0 and vercel.com, the team says agents cut nearly two megabytes of compressed JavaScript, with individual wins like 150 KB from an experimental editor loaded on nearly every page, and 255 KB on the Vercel dashboard from markdown rendering and chart drawing that shipped before the agent panel was even open. Those are self-reported results on Vercel's own apps, tuned by the people who wrote the tool. Treat them as proof the approach works, not as a forecast for your app. A typical agency site has fewer megabytes to find. I'd be happy with three or four wins in the 20 to 80 KB range.

Where I would not trust it blindly

Deferring code isn't free, and this is where I'd push back on the "let the agent open a pull request" workflow. When you move a 150 KB editor behind a dynamic import, you haven't removed the cost. You've moved it to the moment the user needs the editor. If that moment is a click, the first click now waits on a network request. On a fast connection you won't notice. On a train in poor coverage, the button looks broken.

So every proposed boundary needs a question: what does the user see while this loads? A spinner, a layout jump, a blank panel? The post says the agent checks how components are used interactively, and I believe it tries. But a model reading source can't feel a 400 ms gap on a mid-range phone. You can.

My review checklist for each agent change, in order:

Is the deferred component above the fold or behind an interaction?
Does the loading state match the final layout, so nothing shifts?
Did INP get worse on the page, measured on a preview deployment rather than on my laptop?
Is the saving big enough to justify the extra moving part?

The Vercel team says they verified each fix on a preview deployment before shipping, which is the right habit. Copy it. I'd also keep pull requests one change each, the way the post suggests, because a single combined "optimize bundles" diff is impossible to bisect when INP regresses.

If you are also deciding whether Next.js is the right base for a project in the first place, I went through that trade-off in my Next.js vs Vite post. The bundle tooling above is one more thing that tilts the answer, mostly for teams already on Turbopack.

A routine I would run this week

You don't need the agent to get most of the value. Here's the sequence I'm going to use on my next client audit, which is the kind of work I describe on my portfolio:

# on a branch, after upgrading to Next.js 16.4
npx next analyze

# optional: read-only report from the agent skill
npx skills add vercel/next.js --skill next-bundle-optimizer
# then run /next-bundle-optimizer in your agent (no "fix" argument)

# export the graph if you want to poke at it yourself
npx next analyze export

Start with the route summary and write down the three largest client routes. In each, sort by size and look for two things: any source labeled "Initial + async paths", and any package you can't explain. A date library on a page with no dates counts. Then pick exactly one finding, fix it by hand, take a new snapshot, and read the diff. If the diff shows the number you expected, you understand your bundle. If it doesn't, the import graph is teaching you something, and that's the useful part.

Only after that would I run the agent in report mode and compare its list with mine. Where we disagree, I want to know why before I apply anything.

This week, run next analyze on your biggest route and write down the single largest file in the initial load. If you can't say why it's there, trace its imports until you can.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

PHP EOL and PHP2Shell: The Build Date Check for Old Branches

Qasim Parray — Fri, 30 Oct 2026 16:39:11 +0000

I have a client whose invoicing app still runs PHP 7.4. I've been asking to upgrade it for two years. The answer is always the same: it works, so leave it. On October 21 that answer got a lot harder to defend, because the PHP2Shell fixes shipped for 8.2 through 8.5, and the old branches live in a murkier place.

Short version for the impatient: if you run PHP 7.4, 8.0 or 8.1, a patched build exists but it carries the same version number as the vulnerable one, so php -v cannot tell you if you're safe. If you run 7.3 or older, no fix exists at all. The rest of this post is how to check, what to do about each case, and why I think "it works" has expired as an argument.

If you're on a supported branch, my PHP 8.5.12 patch checklist is the better starting point. This post is about the PHP end of life problem.

Which branches got what

The fixed versions for supported branches are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Those are the easy ones.

The older branches are where it gets strange. According to Plesk's patch summary, PHP 8.1, 8.0 and 7.4 are fixed in builds dated October 21, 2026, and those builds keep the version numbers 8.1.34, 8.0.30 and 7.4.33. Plesk marks those three as Linux only. PHP 5.6, 7.2 and 7.3 are not patched.

Rapid7 describes the 7.4, 8.0 and 8.1 fixes as limited source backports supplied by the PHP project. watchTowr adds two points: there is "no official release" for those three branches, and PHP 7.3 and older have no fix available but are confirmed affected.

So the state of the world is this. 7.4, 8.0 and 8.1 can be patched if someone builds or ships a backport. 7.3 and below can't be patched by anyone except a paid extended support vendor.

I'll admit that last part annoys me. Plesk's article recommends TuxCare Extended Lifecycle Support for the unpatched branches, which is a reasonable thing to mention, but it also means the fix for abandoned PHP is a subscription. Whether that's worth paying depends on how long you plan to stay on the old version, and I'd put a hard date on it before signing anything.

Why the version number lies

Here's the trap. The vulnerable 8.1.34 and the patched 8.1.34 print the same thing.

# example output
$ php -v
PHP 8.1.34 (cli) (built: Oct 21 2026 08:12:41) NTS

If that build line says October 21, 2026 or later, you have the fix. If it says anything earlier, you don't, even though the version looks identical. Plesk's article describes the same check: the patched 8.3 build should report 8.3.36 with a build date of Oct 21 2026, and EOL branches should be checked by build date for the same reason.

Distro packages make this messier, because Debian and Ubuntu and RHEL-family vendors backport security fixes without bumping the upstream version. Rapid7 notes this too: its authenticated Linux package checks recognize backported fixes that keep the original version number. If you're on a distro package, the build date in php -v may not be a reliable signal. What I'd check instead is whether the vendor's package changelog mentions the CVE:

# Debian / Ubuntu
apt changelog php8.1-cli 2>/dev/null | grep -m3 -E 'CVE-2026-109618|CVE-2026-109619'

# RHEL / Alma / Rocky
rpm -q --changelog php-fpm | grep -m3 -E 'CVE-2026-109618|CVE-2026-109619'

I should flag that this is my own check, and it assumes your vendor names the CVE in the changelog, which most do but not all. No match doesn't prove you're vulnerable, and a match tells you the package claims a fix. Treat a missing line as a prompt to read your distro's security tracker.

What I'd do for each situation

If you're on 8.1, 8.0 or 7.4 from a distro or hosting provider that is still maintaining it: check the changelog as above, patch, restart the workers, and verify. Then put the real upgrade on the calendar, because the vendor will drop it eventually.

If you're on 8.1, 8.0 or 7.4 and building from source or using a plain Docker tag: you'll need the project's source backports or a newer tag. A Docker image tagged php:8.1-fpm that was last pulled before the 21st may still be sitting on a pre-fix build, and an old cached layer on your server is easy to forget. Pull again and read the build line instead of trusting the tag.

If you're on 7.3 or older: there's no patch. Huntress, in its rapid response write-up, suggests taking end-of-life PHP off the internet, or putting it behind a VPN or WAF. It also suggests adding session.upload_progress.enabled = Off to php.ini and restarting, which it says mitigates the known abuse cases. That's a partial measure for one attack path, not a fix.

Inventory the bundled copies too. Huntress specifically advises finding PHP installed inside vendor software. A control panel, a CMS installer or an old billing tool can carry its own PHP binary that your system php -v never reveals. Plesk is a good example: its UI component needs a separate update (Obsidian 18.0.80 Update 11 or 18.0.81 Update 4) on top of the PHP builds.

A realistic route off the old branch

Patching a backport buys time, nothing more. The real answer to PHP 7.4 end of life, or PHP 8.1 end of life for that matter, is moving to a supported branch, and the sooner the smaller the jump.

My routine for a client app like the invoicing one is boring. I clone the production code into a branch, run it under the newest supported PHP in a container with the test suite and a static analyser, and read the list of deprecations it produces before I touch a line. Most of the pain is a few dozen deprecated calls and one or two libraries that need a major version bump. The first run is always uglier than the second.

I do it in steps, not one leap. I'd rather ship 7.4 to 8.1 this month with the new build date confirmed, then 8.1 to 8.3 next quarter, than hold a six-month branch open that nobody wants to merge. While the app stays on the old branch, I keep it off the public internet where I can, or behind the proxy request limits I set up in my VPS hardening notes.

The argument I'd make to my client

"It works" is a statement about yesterday. For the 7.4 app, I can now say three concrete things.

The branch has had no routine upstream updates for a long time. A critical unauthenticated bug just landed that it can only get through a special backport. And the cheapest realistic option for 7.3 and older is paid support.

I'd also point at the cost side: the longer a branch sits unsupported, the bigger the jump becomes. I wrote about planning those windows in my Laravel 13 support window post, and the same logic applies to plain PHP. A jump from 7.4 to 8.3 breaks more than 8.1 to 8.3 does.

If you want help scoping an upgrade like that, my portfolio has what I've shipped and how to reach me.

This week, run php -v on every server and container and write down the build date next to each version. Anything on 7.3 or older, or on 7.4, 8.0 or 8.1 with a build date before October 21, goes to the top of the list.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

PHP2Shell Explained: The Two Bugs and Who Is Really Exposed

Qasim Parray — Fri, 30 Oct 2026 08:39:11 +0000

I read the PHP2Shell advisory twice and still got one thing wrong. I assumed "unauthenticated RCE in PHP" meant a bug in some function I could grep my codebase for. It doesn't. Neither bug lives in a function you call. They live in what PHP does when a request goes badly, and that is why this pair of CVEs has people more rattled than the usual patch-Tuesday noise.

Short version for the impatient: CVE-2026-109618 and CVE-2026-109619 are both memory-safety bugs in PHP's request lifecycle, both scored 9.2 on CVSS v4.0, and both are fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you want the step-by-step patch routine, I wrote that already in my PHP 8.5.12 patch checklist. This post is the other half: what the bugs actually are, and which of your servers are really in the blast radius.

I haven't reproduced either bug and I'm not going to. Everything below comes from the vendor advisories, and I'll say where I'm inferring.

The first bug: PHP runs out of memory at a bad moment

CVE-2026-109618 is an out-of-memory problem. According to Rapid7's write-up, when an allocation fails while PHP is setting up request data, PHP abandons the setup partway through. The request structures are then half initialized. Cleanup code later treats them as if they were fine, and that is the path to code execution.

The part that surprised me is how the attacker gets PHP to run out of memory. Rapid7 says a crafted multipart request can exhaust memory even when its size looks like it fits inside your configured limits. So "my post_max_size is small" is not the comfort it sounds like.

Why does this matter more on one setup than another? Because of what happens after the failure. On Apache with mod_php, cleanup still runs even though startup failed, so the demonstrated attack works before any of your application code executes. On PHP-FPM, a failed startup kills the worker, which breaks that particular sequence. Rapid7's source analysis says FPM may still be susceptible after a successful startup, but their advisory reports no complete FPM exploit for this CVE.

I'd read that as "FPM has a better day than mod_php", not "FPM is safe". The distinction affects how fast you move, and I'll come back to it.

The second bug: a request inherits the last one's leftovers

CVE-2026-109619 is a use-after-free across requests. A worker process handles many requests over its life. Some internal state is supposed to be reset between them. In this bug, a pointer survives pointing at memory that was already freed at the end of an earlier request, and a later request on the same worker can read it before initialization clears it.

What puts the stale pointer there? Fatal errors, mostly. Memory exhaustion and execution timeouts can interrupt the cleanup. Rapid7 also says some non-fatal shutdown diagnostics can repopulate error state after it was reset.

Two confirmed exploit paths are described. One needs mod_php on PHP 8.5 with fatal_error_backtraces switched on, which is the default. The other goes through the session upload progress feature, which is also enabled by default. That one affects both mod_php and PHP-FPM, and it can consume the stale state even if your application never calls session_start().

That last detail is the one I keep thinking about. Plenty of apps never touch sessions, so the natural reaction is "this doesn't apply to me." It does, because the feature is on at the PHP level, before your code decides anything.

Who is actually exposed

Here's the matrix as I understand it, with the caveat that I'm summarizing vendor text.

All web-serving SAPIs are in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team's own wording, as quoted by Huntress, is that all PHP installations serving web requests are at risk. CLI-only scripts that never take a web request are a different story, though I'd still patch them because the changelog carries other fixes too.

mod_php is the highest risk. FPM sits a notch lower for the OOM bug but is fully in play for the session path. If you run a typical Nginx plus FPM stack, you are exposed to 109619 through upload progress and possibly to 109618 after startup.

Versions: 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. Older branches are messier, because for 7.4, 8.0 and 8.1 the patched build carries the same version number as the vulnerable one and only the build date differs.

Wiz, according to Huntress's summary, demonstrated unauthenticated RCE against WordPress, Drupal and Joomla. That detail matters if you're a freelancer like me. A client's WordPress site on shared hosting is the same bug as my own VPS, with a different person holding the keys.

What a 9.2 score does and doesn't tell you

Both CVEs carry the same CVSS v4.0 vector, AV:N/AC:H/AT:P/PR:N/UI:N, plus high impact on confidentiality, integrity and availability. Read the first half of that slowly. Network reachable, no privileges, no user interaction. That is the scary part. But AC:H means high attack complexity and AT:P means the attack needs specific conditions to be present, such as a particular SAPI or setting.

So the score is honest about two things at once. The bug is as bad as a bug gets once the conditions line up, and getting the conditions to line up takes work. That matches what Rapid7 found when they tried the public exploits: each one worked for one combination of OS, PHP version and web server and fell over elsewhere.

I find that more useful than the headline number. It tells me the risk is not evenly spread across my servers. A stock mod_php box on a distro I can name is the worst case. A containerized FPM pool with upload progress disabled is a much harder target. I'd still patch both, but I know which one gets my evening.

What the exploit situation looks like

I want to be careful here because the story changed several times in a week.

PHP shipped the fixes on October 21, a day earlier than planned after details leaked on the 20th. By the 23rd Datadog Security Labs noted working public proofs of concept. Rapid7's testing found that each public exploit works only for a specific combination of OS, PHP version and web server, and that none looked broadly reliable. They haven't developed a general exploit themselves.

That is a useful corrective to the panic, and a poor reason to wait. A bug that needs a tailored exploit per environment is still a bug that people with a lot of free time will tailor. And watchTowr reported seeing exploitation through its honeypot network, so "nobody is trying" is not a safe assumption. Watching the timeline unfold is its own lesson, and I'd rather you learn it from this post than from an incident ticket.

What I'd do in the next hour

Pick the box with mod_php first. If you have one, patch it before anything else, then FPM boxes that take public uploads, then the rest.

Check what is really running, because the package version and the running process can disagree. A restart is part of the fix, since old workers keep running old code.

php -v
php-fpm8.4 -v 2>/dev/null
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi|frankenphp|lsphp' | grep -v grep

If a worker's start time is before your upgrade, it is still the old binary. Restart the service, then run that last line again.

Then do the one thing that costs nothing while you wait for a maintenance window: set session.upload_progress.enabled=0 in php.ini or your FPM pool, not through ini_set() or .user.ini, and restart. The advisory is explicit that those two apply too late. It is a partial measure for one bug, so treat it as a seatbelt.

I maintain PHP servers for clients (there's more on that on my portfolio), and the order for a bug like this is always inventory, patch, restart, verify. If you want a baseline for the rest of the box, my VPS hardening notes cover the stuff I set up before PHP is even installed. This week, run that inventory command on every server you own before you go to bed, and write down which ones still show an old worker start time.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

PHP Vulnerability Today: What Waiting on the Patch Costs

Qasim Parray — Thu, 29 Oct 2026 16:39:13 +0000

Confession: when the PHP advisory landed last Wednesday, my first instinct was to schedule the update for the weekend. Critical bug, sure, but I'd read "high attack complexity" in the score and told myself I had time. Then I lined up the dates for the six days that followed, and the weekend plan looked a lot worse.

Short version for the impatient: waiting on CVE-2026-109618 and CVE-2026-109619 costs you more each day than the score suggests, because the attack side moved faster than the advisory implied. Below is the timeline as I can source it, what a late patch actually risks, and what I'd check if you already waited.

I'm a developer who runs PHP for clients, not an incident responder. Where I'm guessing, I'll say so.

The timeline, with sources

Here's what I can pin to a source, in order.

On October 20, a post about two critical PHP bugs appeared on Hacker News and was removed, but screenshots spread. According to Huntress, watchTowr confirmed the leak, and the planned Thursday release was pulled forward to Wednesday, October 21.

On the 21st, PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The same day, watchTowr says its honeypot network observed exploitation. Huntress, checking its own partner systems that afternoon, saw none. Both statements can be true. A honeypot sees the whole internet; a partner base sees a slice.

Datadog Security Labs notes that working public proofs of concept were circulating by October 23. Rapid7 tested them and found each one works only for a specific mix of OS, PHP version and web server. They had not seen confirmed exploitation themselves but did report multiple attempts.

On October 26, watchTowr updated its FAQ to say CISA added CVE-2026-109618 to the Known Exploited Vulnerabilities catalog. The page lists KEV status only for that CVE, not for 109619.

That's five days from fix to the government's "this is being used" list. I'd have bet on longer.

One claim I'd throw out

Palo Alto's Unit 42 published a brief on the 23rd linking some post-compromise activity to PHP2Shell, then retracted that link on October 25. Per their updated page, they had seen an attack on a European government agency running a vulnerable PHP application but could not confirm the initial access involved these CVEs.

I mention this because a lot of people screenshotted the first version. If someone tells you "attackers are dropping X after PHP2Shell", ask which source, and check whether it's the retracted one. The honest state of the evidence is: exploitation attempts, some observed exploitation per watchTowr, a KEV listing for one CVE, and no clean public case study of a full compromise tied to these bugs.

That's not comfort. It means we're early.

What a late patch actually risks

Let me be concrete about the downside, because "critical RCE" is abstract enough that it stops registering.

These are unauthenticated bugs. PHP's own description, passed along by Huntress, is that an exploit exists for mod_php where an unauthenticated request triggers the attack before any application code runs. There's no login to brute-force, no form to find, and your WAF rules written against your own routes sit in the wrong place.

Once someone has code execution inside a PHP worker, they have whatever that worker has. Database credentials from your .env. API keys. Write access to the web root. Wiz showed, again via Huntress's summary, that the memory disclosure side can expose passwords, tokens, API keys and certificates. So the cost of waiting is not only "they take the server". It's "they take everything the server can reach".

For a freelancer, that last part is the one that wakes me up. One compromised client box can hold the Stripe key, the mail credentials and the database for a business that never heard of CVSS. I keep thinking about how I'd write that email.

Also remember the shared-hosting case. If you run client sites on one box, one vulnerable pool puts them all in range together.

If you already waited, check this

Patching does not undo anything that happened before the patch. If your server was reachable on the 21st and ran an old build for days, spend twenty minutes on these.

Look for PHP workers spawning things they shouldn't. Florian Roth, quoted by Huntress, expects exploitation to show up as child processes of PHP such as sh, bash, python, curl, wget or nc. Huntress also flags reverse-shell strings like /dev/tcp/ and fsockopen, and quick recon commands such as whoami and id.

# PHP workers with suspicious children (rough check, run as root)
ps -eo pid,ppid,user,lstart,cmd --forest | grep -B1 -E 'sh -c|bash|curl|wget|nc ' | grep -A1 -E 'php-fpm|php-cgi|apache2|httpd'

# files changed in the web root since the fix shipped
find /var/www -type f -newermt '2026-10-20' -not -path '*/cache/*' -not -path '*/node_modules/*' | head -50

# cron entries and recently modified system accounts
ls -la /etc/cron.d /var/spool/cron* 2>/dev/null
lastlog | head

These are my rough versions of the checks Huntress describes: webshells, new files in the web root, new cron jobs, new accounts. A hit isn't proof and a clean result isn't proof. The Rapid7 advisory itself says the absence of relevant log entries does not prove an installation is safe, and there are no published indicators to match against.

If something does look off, Huntress's advice is to isolate the server and preserve the web server and PHP logs before touching anything. Then rotate every secret that box could read, not just the obvious ones.

Which servers I'd patch first when I can't do all of them

If you have ten servers and one evening, the order matters more than the speed. This is the order I'd use, and it's my own judgment, not vendor guidance.

First, anything running Apache with mod_php. The PHP team rates it highest risk because the demonstrated attack lands before application code runs. Second, anything public that accepts file uploads or large multipart posts, since the memory exhaustion path in the first bug starts with a crafted multipart request. Third, anything holding secrets for other systems: a box with payment keys, mail credentials or database admin passwords is worth more to an attacker than a brochure site.

Last, the internal tools and staging boxes. They matter, but nobody is spraying the internet for your staging server.

This is also where the weekend plan falls apart. A Saturday window sounds fine until you add up what the timeline above shows: fix released Wednesday, exploitation reported the same day by one source, public exploits by Friday. By Saturday you would have spent a day and a half on a bug with working public exploits and no log evidence either way, and the KEV listing was only two days further on.

What I'd do about the delay itself

Delays happen for boring reasons. A client is mid-launch. A deployment pipeline is flaky. The distro repo hasn't got the package yet; Huntress notes the Remi repository had no updated packages on release day.

When I can't patch, I narrow the exposure rather than shrug. Disable session upload progress in the main config, cut the upload size, and put a stricter limit on request bodies at the proxy. That's a partial step for one attack path, and per watchTowr's reading of the PHP statement, no configuration change fully mitigates these bugs. If the app is public and the stakes are real, a maintenance window tonight beats a perfect one on Saturday. My VPS hardening baseline has the proxy and firewall pieces I use to narrow things down.

If you want to see how I handle this kind of work for clients, my portfolio has the details.

Tonight, pick your most exposed server, run the first command above, and if anything unexpected shows up, isolate the box before you do anything else.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Kimi K3.1 Pro Pricing: The Per-Task Math Before You Switch

Qasim Parray — Thu, 29 Oct 2026 08:39:09 +0000

Sticker prices for LLM APIs have misled me enough times that my first move on any new model is to convert per-million-token prices into cost per finished task. Kimi K3.1 Pro showed up this week, and the sticker looks good, so here's that conversion.

Short version: at the listed rate, a coding-agent task I'd call typical costs about $3 uncached. That's real money saved against a pricier model if the quality holds on your workload, and it's a number you can only trust after you've read the caching rules and run your own tasks.

I haven't called the Kimi API myself. Everything below comes from Simon Willison's write-up and Moonshot's own pricing page, and I'll say which is which as I go.

What's actually on the page

Simon's post, dated 23 October, gives these facts. Kimi K3.1 Pro landed on the Kimi API that day. It isn't open weights yet, but Moonshot promise full model weights by 4 November 2026. There's a "Highspeed" version that's two to three times faster at twice the price, except that input tokens served from cache cost the same as on the standard version. The dollar pricing is $2.00 per million input tokens and $10 per million output tokens, which Simon says matches GPT-6.1 Sol and is half the price of Claude Opus 5.5.

Moonshot's pricing page adds a few details that matter more than the headline. All K3 series models support a context window of 1,048,576 tokens. Caching is automatic for repeated request prefixes with a default TTL of five minutes. For K3 models, cache writes are billed separately by TTL (five minutes or one hour), and cached input is billed at the cache-hit price only, with no extra charge for the write. Pricing is pay-as-you-go with no subscription, and the page says that differs from the Kimi membership and Kimi Code products.

The same page carries a migration notice. From 31 October 2026, K2 series models stop being available to newly registered users, and Moonshot plan to retire all K2 models by the end of December 2026. If you have anything still pointed at K2, that date is yours to deal with regardless of what you think of K3.1.

Cost per task, not cost per token

Per-million-token prices don't tell you what a job costs, because agents don't make one call. They loop. Every step re-sends the growing conversation, so input tokens pile up far faster than output tokens.

Here's a task shape I use for back-of-envelope work. An agent makes 40 model calls to finish a task. Each call sends about 30,000 tokens of context (files, tool output, history) and gets back about 1,500 tokens. Those numbers are made up, but they're close to what a medium coding task looks like, and you should replace them with measurements from your own logs.

def task_cost(calls, in_tok, out_tok, in_price, out_price,
              cached_share=0.0, cached_price=None):
    """Prices are dollars per million tokens. cached_share is the
    fraction of input tokens served from cache (0 to 1)."""
    total_in = calls * in_tok
    total_out = calls * out_tok
    if cached_price is None:
        cached_price = in_price  # unknown: assume no discount
    fresh = total_in * (1 - cached_share)
    cached = total_in * cached_share
    return (fresh * in_price + cached * cached_price
            + total_out * out_price) / 1_000_000

# Kimi K3.1 Pro at the listed standard rate, no cache discount assumed
print(task_cost(40, 30_000, 1_500, 2.00, 10.00))   # 3.0
# Highspeed at twice the price, same assumption
print(task_cost(40, 30_000, 1_500, 4.00, 20.00))   # 6.0

That's 1.2 million input tokens and 60,000 output tokens per task. Input costs $2.40 and output costs $0.60, so $3.00. If Simon's comparison holds and the Opus 5.5 rate is double, the same task comes to $6.00 there, and the Highspeed tier lands at the same $6.00. Multiply by 500 tasks a month and you get $1,500 against $3,000.

Two things to take from the arithmetic. First, input dominates. Output is 20 percent of the bill in this shape, so a model that talks less doesn't save you as much as one that re-reads less. Second, the 2x speed premium brings the cost to about what Opus 5.5 would be by Simon's comparison, so Highspeed is a latency purchase and a poor way to save money. Buy it for interactive use, where a person waits on the answer, and keep batch jobs on the standard tier.

I wrote a longer version of this sort of math, with cached-token pricing across several vendors, in my LLM pricing comparison. The shape is the same: model the loop, not the call.

Read the caching rules before you trust the number

The $3.00 above assumes zero cache benefit, and the real figure is probably lower. I say "probably" because I don't have the cache-hit price in front of me. Simon's post says Highspeed cache hits cost the same as standard, and Moonshot's billing text refers to a cache-hit price, but I haven't seen the number, and the Moonshot page I fetched didn't render its price table without JavaScript. Check the live table before you rely on any figure here.

What I can say from the billing text is how the mechanism behaves, and that matters because it decides whether your agent benefits at all. Caching applies to repeated request prefixes. An agent that appends to a conversation sends the same prefix on every step, so it should hit. An agent that rewrites a system prompt each step, injects a timestamp near the top, or reorders its tool list will miss every time. With a five-minute default TTL, a pipeline that pauses for human review longer than that likely pays full price again after the pause.

So the work is mechanical. Put stable content first and variable content last. Keep timestamps out of the prefix. If your tasks pause for long gaps, look at the one-hour TTL option and whether its write pricing is worth it for your pattern. Then send 20 real tasks and read the usage numbers the API returns, because the sticker never tells you your cache hit rate.

The open-weights promise is a date, not a model

The headline that will get shared is that a model near the top of the benchmarks is about to be open weights. Moonshot's own statement is that weights will be released by 4 November. That's a little over a week away, and a promise isn't a download.

Here's why it matters for planning. If you're thinking of self-hosting, you can't size hardware, pick an inference server, or check the licence until the files exist. The licence terms decide whether you can use the model commercially for a client, and those are not something I'd assume from the word "open". Context length matters here too. A 1,048,576-token window is great for the API and may cost a lot of memory to serve yourself, so the context you can actually afford on your own hardware may be far smaller than the number on the page.

My advice is dull: don't build anything that depends on self-hosting K3.1 Pro until the weights are public and you've read the licence. Using the hosted API in the meantime costs you nothing but the data-handling question, and that one is worth a conversation with the client before you send their code to a vendor.

One benchmark score isn't your workload

Simon reports that Moonshot's own benchmarks put Kimi roughly level with Opus 5.5 and GPT-6 Astra, and that Artificial Analysis scored it 55. By his account, that's ahead of Claude Fable 5.1, GPT-6 Astra and Gemini 4 Argon at 53 each, and behind Claude Opus 5.5 at 58. He also notes this is the first time a soon-to-be open-weight model has scored this high against the leaders.

I take that seriously, and I still wouldn't switch anything on a three-point gap on an aggregate index. An aggregate averages over tasks you may never run. A model that's two points lower overall can be better on your tool-calling format, your language, or your repo's size. The reverse is just as likely. It's also worth remembering that the pelican-on-a-bicycle test Simon uses is a fun smoke test of reasoning levels, and not a coding evaluation.

The check I trust is small and boring. Take 20 tasks from your real backlog, run them through the current model and the candidate with the same harness, and compare pass rate and cost per passing task. Cost per task divided by pass rate is the number that matters. At $3 per task and a 40 percent pass rate, a model costs $7.50 per success. At $6 and 90 percent, the pricier one costs $6.67. The cheaper sticker loses, and you'll only find that out by running it.

What I'd do this week

Pull usage logs from your current agent setup and compute your real average calls, input tokens and output tokens per task. Plug them into the function above with the standard rates. If the answer is a large saving, pick 20 representative tasks and run them on K3.1 Pro through the same harness you use today. Record pass rate, total cost and cache-hit rate, and decide from those.

Set a calendar reminder for 4 November to check whether the weights shipped, and read the licence the day they do. If you have anything on a K2 model, schedule that migration before the end of December. If you want to see how I wire agents into client workflows, my portfolio has the projects.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Alternatives to Tailwind CSS: Name the Complaint First

Qasim Parray — Wed, 28 Oct 2026 16:39:08 +0000

I defend Tailwind more than I probably should, which makes me a biased judge of its alternatives. So this post is me trying to write down the honest case for leaving, then checking which of the alternatives actually survive it.

Short version: most people who search for alternatives to Tailwind CSS don't need a different framework. They need to know which of four complaints they have, because each one has a different fix, and two of the fixes are plain CSS.

The complaints I'd take seriously

Tailwind complaints tend to come bundled together, and they shouldn't be. Pulled apart, I hear four of them.

The first is markup noise. A card with eleven classes on the wrapper and six on every child is hard to scan, and it's hard to review in a pull request when the real change is one class in the middle of a long string. This one is legitimate. Components help, but only if you actually extract them.

The second is the build step. Tailwind needs a toolchain, and some projects, a marketing page with one stylesheet, a server-rendered app with no bundler, don't have one and don't want one.

The third is team taste. Some teams read utility classes fluently and some never will. If half your team resents the syntax, "it's faster once you learn it" is a weak argument against a reviewer who is still not fluent two years in.

The fourth is lock-in to a vocabulary. px-4 means something in Tailwind and nothing anywhere else. Your design tokens live in Tailwind's theme, and moving them out takes real work.

Notice what's missing from that list: performance, and "it's not real CSS". Neither holds up well. The output is a stylesheet, and the theme variables in current versions are ordinary CSS custom properties you declare with @theme. I've already written about the CSS-first config I actually ship, so I won't repeat the setup here.

Native CSS has caught up with a lot of the pitch

Part of why Tailwind took over was that writing plain CSS used to hurt. No nesting without Sass, no scoping, no clean way to share values. Several of those problems got solved in the platform itself.

CSS nesting is the one that matters most for this comparison. The MDN guide to CSS nesting describes it as being parsed by the browser instead of compiled ahead of time by a preprocessor like Sass, and it lets you stop repeating the parent selector. Add custom properties for your tokens, @layer for ordering, and @container for component-level responsiveness, and a stylesheet with no toolchain starts to look reasonable again.

Here's the same card both ways. First, the Tailwind version:

<article class="rounded-xl border border-zinc-200 bg-white p-6 shadow-sm
                hover:shadow-md dark:border-zinc-800 dark:bg-zinc-900">
  <h3 class="text-lg font-semibold text-zinc-900 dark:text-zinc-50">Deploy log</h3>
  <p class="mt-2 text-sm text-zinc-600 dark:text-zinc-400">Last run finished clean.</p>
</article>

And native CSS with nesting and custom properties:

.card {
  --card-bg: #fff;
  --card-border: #e4e4e7;
  --card-title: #18181b;
  --card-text: #52525b;

  padding: 1.5rem;
  border: 1px solid var(--card-border);
  border-radius: 0.75rem;
  background: var(--card-bg);
  box-shadow: 0 1px 2px rgb(0 0 0 / 0.05);

  &:hover { box-shadow: 0 4px 6px -1px rgb(0 0 0 / 0.1); }
  & h3 { margin: 0; font-size: 1.125rem; font-weight: 600; color: var(--card-title); }
  & p  { margin: 0.5rem 0 0; font-size: 0.875rem; color: var(--card-text); }

  @media (prefers-color-scheme: dark) {
    --card-bg: #18181b;
    --card-border: #27272a;
    --card-title: #fafafa;
    --card-text: #a1a1aa;
  }
}

<article class="card">
  <h3>Deploy log</h3>
  <p>Last run finished clean.</p>
</article>

The markup is cleaner and the CSS is longer. That trade is the whole debate in one screen. I'd rather pay in CSS lines for a component I touch twice a year, and pay in class strings for the page I rearrange every week. Neither choice is a moral one.

One honest difference: the dark mode above follows the OS setting. A class-based toggle that a user can flip needs one more piece, a selector like :root[data-theme="dark"] that you maintain yourself. Tailwind gives you that with a variant. It's small, and you'll feel it the first time a client asks for a toggle button.

UnoCSS and Panda keep the idea and change the engine

If what you like is the speed of styling in the markup, but you dislike something about Tailwind specifically, two tools keep the approach.

UnoCSS describes itself as an instant atomic CSS engine with no opinions in the core, where all the utilities come from presets. You can define your own rule in a config file and it only generates CSS for classes it finds in your code. That flexibility is the pitch. If your team has strong views about utility names, you can write the vocabulary yourself. The cost is that you now own a vocabulary, and the next developer has to learn yours, because they didn't learn it anywhere else.

Panda CSS goes the other direction. You write styles in TypeScript, and it reads your source at build time to generate atomic CSS, so you get something like CSS-in-JS authoring without shipping a style engine to the browser. The same card looks like this:

import { css } from '../styled-system/css'

export function Card() {
  return (
    <article
      className={css({
        p: '6',
        rounded: 'xl',
        borderWidth: '1px',
        shadow: 'sm',
        _hover: { shadow: 'md' },
      })}
    >
      <h3 className={css({ fontSize: 'lg', fontWeight: 'semibold' })}>Deploy log</h3>
    </article>
  )
}

I'd pick Panda when type safety on style props is the thing the team wants, because a typo in a token name becomes a compile error instead of a card that quietly has no padding. I wouldn't pick it for a content site, because a code generation step and a generated styled-system folder are a lot of machinery for a blog.

I haven't shipped either one in production, so my opinion here is a reading of their docs, not a war story. If you've run UnoCSS on a large codebase, your experience is worth more than mine.

CSS Modules and vanilla-extract are the boring choice

When the complaint is markup noise and the team is already in a component framework, I'd look at the dullest option first. CSS Modules is a bundler feature: you write a normal stylesheet, import it, and class names become locally scoped. You get nesting from the browser, scoping from the bundler, and no new vocabulary.

/* card.module.css */
.card { padding: 1.5rem; border-radius: 0.75rem; }
.card:hover { box-shadow: 0 4px 6px -1px rgb(0 0 0 / 0.1); }

import styles from './card.module.css'

export const Card = () => <article className={styles.card}>Deploy log</article>

vanilla-extract takes that idea and puts it in TypeScript. You write styles in a .css.ts file, they compile to a static stylesheet, and you import class names like any other value:

// card.css.ts
import { style } from '@vanilla-extract/css'

export const card = style({
  padding: '1.5rem',
  borderRadius: '0.75rem',
  ':hover': { boxShadow: '0 4px 6px -1px rgb(0 0 0 / 0.1)' },
})

Both give you scoping, which is the thing Tailwind avoids needing in the first place, since utilities don't collide. If your pain is that global CSS leaks, scoping solves it directly. If your pain is that class strings are ugly, scoping does nothing for you and you've swapped one kind of ceremony for another.

When I'd stay put

Switching has a cost that the alternatives' docs never mention. Every project already on Tailwind has people who can read it, a design system that's expressed in it, and a pile of snippets, templates and component libraries that assume it. Leaving means you re-express all of that, and the savings only show up if the complaint was real.

I'd stay with Tailwind when the team is fast in it, when the project has a design system with many contributors, and when the markup noise is something extracted components could fix. I'd also stay when the real problem is that the design itself is inconsistent. A different styling tool doesn't make a team agree on spacing. Writing the spacing scale down as theme values does, and that's a one-afternoon job whichever tool you're using.

I'd leave, or at least not start, for a small content site with no bundler, for a team that's openly unhappy with the syntax, and for a library whose users shouldn't need your build setup to consume it. Those three have something in common: the cost of the toolchain or the vocabulary lands on someone who didn't choose it.

What I'd decide this week

Don't start by picking a tool. Start by naming the complaint, because the cheapest fix for each one is different.

If the complaint is markup noise, extract components before you change tools. Take the five most repeated class strings in your codebase and turn each into a component. If that isn't enough, the native CSS version above is the next thing to try.

If the complaint is the build step, use plain CSS with nesting and custom properties. For a small site, it's less code to maintain than a config you never touch.

If the complaint is team taste, ask the team what they'd write instead, and take that answer seriously. A styling system half the team resents will decay no matter how well it benchmarks.

If the complaint is token lock-in, move your tokens into CSS custom properties first. That's useful whichever tool you end up with, and it's the first step Tailwind's own theme variables already point toward.

This week, take one real component from your project, the card or the button, and rewrite it in native CSS next to the Tailwind version. Time how long it takes and look at which one you'd rather review. If you want to see how I structure client frontends before choosing a stack, my portfolio has examples.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Oracle to PostgreSQL Migration: The Residue Report I'd Price From

Qasim Parray — Wed, 28 Oct 2026 08:39:07 +0000

Short version for the impatient: before you pick an Oracle to PostgreSQL migration tool, ask it for the list of things it refuses to convert. That list is your quote. The converted DDL is the cheap part.

I read the pgrecon announcement on the PostgreSQL news page twice this week. The first read was for the feature list. The second was because the benchmark table made me suspicious, and I wanted to work out whether the suspicion was fair. I haven't run pgrecon against a real Oracle estate, so treat everything below as a reading of what the project claims plus my own habits from client migrations, not a test report.

If you quote fixed-price database moves for clients, or you're the person who gets handed one, this is the part of the problem I'd look at first.

Why the schema script is the cheap part

Every Oracle migration pitch starts with a demo where tables go in one side and come out the other. Tables are easy. A table is columns, types and constraints, and the mapping is mostly mechanical. The money disappears somewhere else: PL/SQL packages that keep state between calls, triggers that write audit rows in their own transaction, jobs scheduled inside the database, and application code that quietly depends on how Oracle treats empty strings.

That last one deserves a paragraph because it bites people who think they've finished. Oracle treats an empty string as NULL. PostgreSQL does not. A column that has always been "optional" in practice, with the application sending an empty string, behaves one way on Oracle and another on PostgreSQL. Your WHERE col IS NULL filters, your NOT NULL constraints and your unique indexes all change meaning without a single syntax error. No DDL converter can fix that. Only an assessment that goes looking for it can.

So the useful question for any tool is not "how much did it convert?" It's "how clearly did it tell me what it left behind?"

What pgrecon says it does

The project describes three stages. Your DBA runs one read-only SQL*Plus script and sends back the spool files. The tool loads them into a local SQLite inventory and never connects to either database. Then a rule engine of 80 rules runs over the inventory, and a converter emits PostgreSQL DDL for what it can prove equivalent.

Two design choices stood out to me.

The first is the offline dump. I like this more than I expected to. A lot of Oracle estates belong to companies where nobody will hand a contractor a connection string in week one. A short, auditable script that a DBA reads line by line and runs with a read-only account is a much easier yes. The project page says the script is short enough to audit, and that's the right claim to make, because it's the thing a security reviewer will actually check.

The second is the residue report. The page says everything the converter can't carry faithfully becomes a named line instead of emitted DDL. Their examples are the sort of thing I'd want to see: a view using JSON_TABLE that needs a hand rewrite because PostgreSQL 17 added it with different clause syntax, a trigger that runs an autonomous transaction, a compound trigger, an external file locator column with no counterpart.

Read those four lines again. Each one is a different kind of work. The view is an afternoon. The autonomous transaction is a design decision, because you're choosing between dblink, a queue, or changing what the audit table means. The compound trigger is a restructure. The file locator is a conversation with whoever owns the files. A flat list with reasons attached is how you turn "it's about six months" into a number you can defend.

What the conversions actually look like

Here's the flavour of what a converter has to get right. Take the classic Oracle top-N pattern:

-- Oracle
SELECT * FROM (
  SELECT employee_id, last_name
  FROM employees
  ORDER BY salary DESC
)
WHERE ROWNUM <= 10;

-- PostgreSQL
SELECT employee_id, last_name
FROM employees
ORDER BY salary DESC
LIMIT 10;

The announcement says the converter now turns ROWNUM top-N bounds into LIMIT. Fine, but notice what the tool has to prove. If somebody wrote the lazy version, WHERE ROWNUM <= 10 ORDER BY salary DESC with no subquery, Oracle applies the row limit before the sort and returns ten arbitrary rows. A mechanical conversion to LIMIT would silently start returning the real top ten. That's arguably the behaviour the author wanted, and it's still a change that someone should sign off on. I'd want to know whether the tool flags that shape or just rewrites it.

Hierarchies are the other one I always check, and the announcement says CONNECT BY becomes WITH RECURSIVE:

-- Oracle
SELECT employee_id, manager_id, LEVEL
FROM employees
START WITH manager_id IS NULL
CONNECT BY PRIOR employee_id = manager_id;

-- PostgreSQL
WITH RECURSIVE tree AS (
  SELECT employee_id, manager_id, 1 AS level
  FROM employees
  WHERE manager_id IS NULL
  UNION ALL
  SELECT e.employee_id, e.manager_id, t.level + 1
  FROM employees e
  JOIN tree t ON e.manager_id = t.employee_id
)
SELECT employee_id, manager_id, level FROM tree;

That one is mechanical for simple cases. It gets uglier with CONNECT_BY_ISCYCLE, SYS_CONNECT_BY_PATH and ORDER SIBLINGS BY, none of which the announcement mentions. Absence from a press release isn't evidence of absence from the tool. I'd test exactly those on a sample schema before believing any summary.

There's also a quieter item in the announcement: both extraction tiers capture character versus byte length semantics, so VARCHAR2(30 CHAR) maps to varchar(30). This matters because PostgreSQL's varchar(n) counts characters. A VARCHAR2(30 BYTE) column on a UTF-8 database holds fewer characters than the same number in PostgreSQL. Moving to the looser limit is usually harmless. Moving data the other direction later, if you keep Oracle as a fallback during cutover, is where it hurts.

Reading a benchmark the vendor ran

Now the part that made me suspicious. The project page has a table of apply errors against a live PostgreSQL 16 after converting nine schemas. pgrecon shows zero. The other tools show 40, 58, 77, 135 and 481, depending on the tool, and the page adds notes such as "PL/SQL out of scope by design" and "tables, indexes and sequences only".

I'm not saying the numbers are wrong. The page says the benchmark workflow lives in the repository and is re-run in CI, which is exactly how this should be published, and I'd rather see a reproducible vendor benchmark than none at all. But I'd hold three reservations.

One, the author picked the schemas. Oracle's HR, OE and CO samples plus a handful of open-source PL/SQL libraries are a sensible public set, and they're also a set the author could tune against for months. Your estate isn't in it.

Two, "apply errors" counts statements PostgreSQL rejected. It doesn't count statements PostgreSQL accepted that now behave differently. A tool that declines hard cases gets a perfect score on this metric by design, and the page is open about that. Declining is the honest behaviour, and it still isn't the same thing as converting.

Three, the comparison tools are measured at specific versions on specific dates, and some of the notes describe scope choices, not defects. The CYBERTEC and Dalibo notes say what they cover. Reading "40 errors" next to "0 errors" without those notes would be unfair to both.

The version of this that I do trust is the project's own statement of what it declines. A tool that publishes its residue is easier to audit than one that publishes a score.

How I'd run an assessment this week

If I had an Oracle estate on my desk tomorrow, this is the order I'd go in. It's the order that spends the least client money before the first real decision.

First, get the DBA to run the extraction script on a non-production copy with a read-only account, and read the script yourself before they do. If the client's security team balks at that, you've learned something about the schedule.

Second, install the tool with pip install pgrecon and run the report before the converter. Sort findings by severity and read the evidence lines. Don't skim the summary. A line-level hit on package-level state or on database links is worth more than a hundred green rows.

Third, take the residue report and price each line separately, in days, with a name next to it. If a line says "redesign with a queue", that's a design meeting and a test plan, not an hour.

Fourth, check the empty-string behaviour by hand. Grep the application code for comparisons against '' and for string concatenation over nullable columns. Oracle's || treats NULL as an empty string, and PostgreSQL's returns NULL, so first_name || ' ' || middle_name quietly starts blanking whole names. A schema dump can't show you that.

Fifth, apply the converted DDL to a scratch PostgreSQL instance yourself. Don't take the apply-error count from anyone's table, including mine. If you want the data-movement side of a database move, I wrote about a MySQL to PostgreSQL one in the row that kept my write freeze.

If you take on this kind of work, my portfolio lists the database and backend projects I do for clients. For partitioned tables in particular, read the PostgreSQL partitioning chapter before you accept any automatic mapping of Oracle interval partitions, because PostgreSQL's declarative partitioning needs partitions to exist up front.

This week, do one thing: ask whichever tool you're considering to produce its refusal list for a schema you own, and put a day estimate beside every line. If it can't produce the list, you have your answer about the quote.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Claude Agent Skills Move to the Linux Foundation: What Changes

Qasim Parray — Mon, 26 Oct 2026 08:39:02 +0000

I have a folder on my machine called skills, and until yesterday I thought of it as a Claude thing. Then Anthropic announced it is donating the Agent Skills standard to the Agentic AI Foundation, and I had to admit I'd never actually read the spec. I'd just copied the shape of the first skill I saw and kept going.

So I read it. It's short. That turns out to be the whole story, and it's also the reason I'm a little suspicious of the excitement around this news.

Here's what was announced, what a skill is at the file level, and what I'd do differently now that the standard has a neutral owner. If you want to know who's writing this, I build automation for clients, and you can see the kind of work on my portfolio.

What Anthropic actually announced

Per Anthropic's post from October 22, the company is donating the Agent Skills standard to the Agentic AI Foundation (AAIF), which sits under the Linux Foundation. Anthropic says it co-founded the AAIF with Block and OpenAI last year, and that it donated the Model Context Protocol to the same place.

The donation covers more than the text of the spec. Anthropic lists the Agent Skills name and logo, the GitHub organization, and the agentskills.io domain. It also says you can keep using the standard or contribute without joining the AAIF, which matters if you're a solo developer who doesn't want a membership form.

On the numbers, the post says more than 70 agent platforms have integrated skills since the standard was published in December 2025, and names ChatGPT, Cursor, GitHub Copilot and VS Code. It says 1 million skills have been published and nearly 280 million installed. Those are Anthropic's figures, and I can't verify them. A million skills sounds like a lot until you remember that a skill can be a folder with one short markdown file, so the count says more about how cheap they are to make than how good they are.

Maintenance goes to engineers from Anthropic, Google, OpenAI and other companies, acting as individuals, with David Soria Parra and Mahesh Murag as lead maintainers. Simon Willison's short note on the news points out he guessed this destination last December.

What a skill is, file by file

The specification says a skill is a directory with, at minimum, a SKILL.md file. Optional folders are scripts/, references/ and assets/. That's it. No manifest language, no build step, no registry you must publish to.

The SKILL.md starts with YAML frontmatter. Two fields are required. The name must be 1 to 64 characters, lowercase letters, numbers and hyphens, no leading or trailing hyphen, no double hyphens, and it has to match the parent directory name. The description must be 1 to 1024 characters and should say both what the skill does and when to use it. Optional fields are license, compatibility, metadata and an experimental allowed-tools.

Here is the smallest valid one, close to the spec's own example:

---
name: pdf-processing
description: "Extracts text and tables from PDF files, fills PDF forms, and merges multiple PDFs. Use when working with PDF documents or when the user mentions PDFs, forms, or document extraction."
---

# PDF processing

Steps go here, in plain markdown.

I want to underline the description field, because it's the part I'd have gotten wrong if I'd kept guessing. The agent doesn't read your whole skill up front. The spec describes progressive disclosure, so the agent sees the name and description first and loads the body when the task seems to match. A vague description like "Helps with PDFs" is, in the spec's own words, a poor example. If the description is lazy, the skill never fires, and you'll blame the model.

A description that fires, and one that doesn't

This is the part that pays back fastest, so here's a concrete pair. Say you wrote a skill that turns a client's raw invoice export into a clean CSV.

The lazy version of the description is "Helps with invoices." Ask yourself when an agent would load that. A user says "tidy up this spreadsheet", and nothing in the description mentions spreadsheets, exports or CSV. The skill sits there unused.

The better version names the input, the output and the trigger: "Converts a raw invoice export (CSV or XLSX) into a cleaned CSV with one row per line item. Use when the user mentions invoices, billing exports, line items or accounting spreadsheets." It's longer, and it gives the agent words to match against.

The spec's limit of 1024 characters is generous. I'd use maybe a third of it. Past two or three sentences you start describing the skill's steps, and those belong in the body, which only loads once the skill has been picked.

Names get less attention but deserve a minute. They must match the directory, so renaming a folder to tidy up your repo can silently break a skill. I'd keep names boring and literal, like invoice-cleanup, and resist the urge to be clever.

Reading the spec as a client-work person

Most of my day involves small teams who want one thing automated and don't care about standards bodies. For them, the useful fact is that a skill is a plain folder. It can live in git, get code reviewed, and be copied between machines without a package manager. That's a better story than most plugin systems I've dealt with.

It also means the same skill can, in principle, travel between tools. Anthropic's post lists several platforms that have integrated skills. I haven't tested portability across them, and I'd expect small differences in how each loader treats optional fields, so I'd test one skill in two tools before promising a client anything.

Why a neutral owner changes my planning

Until now, writing a skill felt like writing for one vendor's product that happened to be documented well. If the vendor changed direction, my folder of skills was a bet on their roadmap.

Moving the standard to a foundation doesn't make that risk vanish, but it changes the odds. The name, the repository and the domain no longer belong to the company with the most to gain from steering them. Anthropic has proposed a starting roadmap of versioned releases, a formal proposal process, and security guidance for people who write and install skills.

Versioned releases are the one I care about most. When I read the spec page, I didn't see a version number I could pin a skill against. If you have ever debugged a behaviour that changed because a loader quietly started parsing frontmatter differently, you know why a numbered spec is worth more than another feature.

I'm also holding the promise loosely. Foundation governance tends to be slower than one company shipping on its own schedule, and the post itself talks about process first: a proposal process, versioned releases, a Discord for feedback. I'd plan on stability, not on a burst of features.

The part nobody should skip: scripts are code you run

The spec allows a scripts/ directory with executable code. That's a feature, and it's also the sentence I'd highlight for any team installing skills from strangers. A skill isn't a prompt. A skill can ship a program, and your agent may be allowed to run it.

The proposed roadmap mentions security guidance for people who write and install skills, which tells me the maintainers know this. The allowed-tools field is marked experimental in the spec, so don't treat it as a security boundary yet.

My rule for now is boring. I read every file in a skill before I install it, scripts first, the same way I'd read an install script piped from curl. For anything that touches client data, I run the agent inside a container with no access to the host Docker socket, for reasons I wrote up in why I stopped mounting docker.sock into agent sandboxes. The same logic applies here: a skill from a stranger deserves the same suspicion as a package from a stranger.

The marketplace point is worth saying plainly. When 280 million installs are claimed and anyone can publish, some of that traffic will be people copying a skill they never opened. I would be surprised if nobody has already tried to hide something nasty in a scripts/ folder.

What I would do this week

Four small things, none of them heroic, and the first one is the cheapest.

Open the spec and read it. It takes ten minutes, and you'll find out whether your existing skills even validate. Check that each name matches its folder name and has no uppercase letters or double hyphens. Then rewrite your three worst descriptions so each says what the skill does and when to use it, in those words. Finally, audit anything in a scripts/ folder you didn't write yourself.

If you maintain skills for a team, add a one-line compatibility note to any skill that needs git, Docker or network access. The spec says most skills don't need that field, and it's there for exactly the ones that do. That small note saves a colleague from a confusing failure on a machine that lacks a dependency.

I'll revisit this when the first versioned release lands. If the spec gets a number I can pin, I'll move my own folder over and write down what broke.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

PHP 8.5.12 RCE Patch: The Checklist I Run on Every Server

Qasim Parray — Sat, 24 Oct 2026 16:39:00 +0000

I was halfway through a coffee yesterday evening when the PHP security advisory landed in my feed, and the coffee did not survive the next ten minutes. Two critical remote code execution bugs, unauthenticated, and the PHP team's own wording was "update immediately". No "consider upgrading when convenient". That phrasing is rare enough that I stopped what I was doing.

Short version for the impatient: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart your workers, and confirm with php -v. Everything below is the checklist I'm using, the stopgap settings if you can't patch yet, and a few places where I think people will get tripped up.

I'm not a security researcher. I'm a developer who deploys PHP apps for clients and runs a few boxes of my own, so this is written from the "I have to patch this today and prove it" side of the fence. Read the primary sources too. I link them as I go.

What the advisory actually says

The official advisory on php.net names two bugs. The first is CVE-2026-109618, which the team describes as RCE via out-of-memory corruption. When PHP runs out of memory at a bad moment, it can be interrupted while internal request data is only half initialized, and the cleanup code then trusts that invalid data. The second is CVE-2026-109619, RCE via stale global state. Some request-owned internal state survives after its memory has been freed, and the next request on the same worker can pick it up before normal initialization resets it.

Both are unauthenticated. The team says the risk is highest for mod_php, where they have a demonstrated exploit that fires before any application code runs. That last part matters for how you think about this. Your framework's middleware, your WAF rules written against your routes, your login page: none of it is in the path. The bug lives below your code.

The affected list is wide. PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are all named. If your PHP serves web requests, you're in scope. Laravel News covered the release with the platform-by-platform status, which is the quickest way to see where Forge, Vapor, Cloud and Envoyer stand.

I'm deliberately not going to describe exploitation details. I don't know them beyond what the advisory says, and guessing would be worse than silence.

Which version you're on decides the next hour

Here's where I'd sort yourself, because the work is different for each bucket.

If you're on 8.2 through 8.5, the fix is a normal package or image update. The 8.5.12 changelog lists the fix for both advisories under Core as "Avoid state corruption via bailout", alongside a long pile of other fixes, including use-after-free bugs in DOM and BZ2 and a file descriptor leak in the built-in server. So even if the RCE bugs somehow didn't apply to you, this is not a release to skip.

If you're on 8.1 or older, the PHP project no longer ships updates for you. The security team published minimal source backports for 7.4, 8.0 and 8.1 for people building from source, which is generous, but I wouldn't treat it as a plan. If you have a distribution or LTS vendor, ask them for their backport. If you don't, this is the week the "we'll upgrade PHP next quarter" ticket becomes this week's ticket. I wrote about how I plan those upgrade windows in my Laravel 13 support window post, and the short version is that waiting for a security release to force the issue is the expensive way to do it.

If you use the volunteer-maintained Remi repo, read the notice carefully. Per Laravel News, it won't have updates today, and the PHP team recommends distribution packages or building from source in the meantime. That one catches people because "apt upgrade says nothing to do" feels like good news.

The checklist I'm using

Order matters here, so I'm keeping it boring and sequential.

First, find out what you actually run. Not what you think you run. On each server:

php -v
php-fpm8.4 -v 2>/dev/null
apachectl -M 2>/dev/null | grep -i php
ps aux | grep -E 'php-fpm|php-cgi|frankenphp|lsphp' | grep -v grep

The CLI version and the FPM version can differ, and I've been bitten by that before. A box can show a patched php -v while the FPM pool still runs the old binary because nobody restarted it. Which brings me to the second step: patching the package does not patch the running process. Workers that were started before the update keep running the old code until they restart.

sudo apt update && sudo apt install --only-upgrade php8.4-fpm php8.4-cli
sudo systemctl restart php8.4-fpm
# containers: pull the new base image, rebuild, redeploy
docker compose pull && docker compose up -d --build

Third, verify against the running thing, not the package manager. For FPM, I check the master process's binary and start time. For containers, I check the image digest of what's actually up.

php-fpm8.4 -v
systemctl show php8.4-fpm --property=ActiveEnterTimestamp
docker compose exec app php -v

Fourth, remember the platforms that don't patch you automatically. According to Laravel's status notes, Cloud was patched in place, but Forge servers need you to click Update PHP on each one, and Vapor needs a redeploy (a new deployment, not just a redeploy, if you're on a custom or Docker image runtime). Laravel also says Forge has no patch for PHP 8.0 or 8.1 and that Ubuntu 20.04 or older servers can't get the update at all. For those you need a new server on a supported Ubuntu release. I'd power the old box down until you've moved.

Fifth, patch Node too if the same box runs it. The Laravel News piece mentions Node.js security releases shipped alongside, and Forge doesn't update Node for you. I haven't read the Node advisory closely enough to say more, so go read it yourself.

If you can't patch today

The advisory has a section for this, and I'd read it on php.net rather than from my summary, because the details matter. The PHP team is blunt that these measures reduce exposure to specific attack paths and do not make an installation safe. Treat them as a seatbelt on the way to the update, not a substitute.

For the OOM bug, the advisory suggests setting memory_limit=-1 in a place applications can't override it, and a low post_max_size. The counterintuitive part is the unlimited memory limit. I'd have bet money the safer move was a tighter limit. The reasoning is that a finite PHP memory limit is a controllable way to trigger the out-of-memory failure, so removing it takes away the lever. They also say an underlying allocation failure can still reach the vulnerable path, so this is partial at best. And they warn against using RLIMIT_AS or RLIMIT_DATA as a substitute, because those can themselves cause the vulnerable allocation failure.

Here's what that looks like in an FPM pool, where php_admin_value can't be overridden by app code:

; /etc/php/8.4/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[session.upload_progress.enabled] = 0

The 8M figure is the advisory's suggestion for apps without file uploads, and 32M for apps that need uploads, with upload_max_filesize kept below post_max_size. Adjust to your app.

For the stale global state bug, the advisory says to set session.upload_progress.enabled=0 and restart every worker, using php.ini, an FPM pool or server config that applies before request parsing. It specifically says not to rely on ini_set() or .user.ini, because they apply too late. There's also a PHP 8.5 item about fatal_error_backtraces=0. Read the full text, since I'm only summarizing part of it.

One thing I'd add from my own habits, and this is opinion rather than advisory: if unlimited memory makes you nervous on a small VPS, pair it with a cgroup or container memory limit that kills only the worker. The advisory itself recommends a container or cgroup limit as an availability boundary. On my own boxes that's a systemd drop-in with MemoryMax on the FPM unit, which I cover in my VPS hardening baseline.

What I'm still unsure about

I don't know yet how many installs are being probed. I haven't seen exploit traffic on my own servers, and absence of evidence on a handful of boxes means nothing. I also can't tell you whether the interim settings hold up, because the advisory itself hedges on them.

The other open question is logs. If an attacker got in before you patched, a clean php -v tells you nothing about the past. I'm checking web server access logs for oddly large or oddly shaped requests since the 21st and looking for unexpected files and processes under the web user. If you run anything with client data on it, assume you may want a proper incident review rather than my grep one-liners. For client work I'd rather write that email now than later.

Do these four things before you close the laptop

Check the PHP version on every server and container you own, then restart FPM or Apache and recheck against the running process. Move anything on PHP 8.1 or older onto a supported release, or get a written backport commitment from your vendor. If a box can't be patched tonight, apply the advisory's interim settings and put a calendar block on the patch. And if you maintain client sites, send each client a two-line note saying what you patched and when, because they will hear about this from somewhere else and it's better coming from you. If you want help with a patch sweep or the upgrade plan behind it, my work and contact details are at abrarqasim.com.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.