DEV Community: Iain

Your reverse proxy makes the internet look like localhost

Iain — Fri, 13 Nov 2026 21:33:20 +0000

You've got Transmission or Ollama on your home server, bound to 127.0.0.1 so nothing else on the network can touch it. Now you want it from your phone, so you put Cloudflare Tunnel or an nginx reverse proxy in front. Feels like another layer between the internet and the app.

It's the opposite. The proxy runs on the same box, and when it forwards a request it opens a fresh connection to 127.0.0.1. The app never sees your phone, or the internet. It sees a connection from loopback, the one address it was told only this machine could use. "Only this machine can reach it" quietly became "anyone who can reach the proxy can reach it", and the proxy is on the internet.

Try it on the blog

I put three of them behind a Caddy proxy on the same box, all on their shipped defaults, and sent requests from outside with no password. Versions are from Alpine's packages on 13 November: Transmission 4.1.4, Syncthing 2.1.7, Ollama 0.17.7.

They see it coming, then tell you to turn it off

Here's the bit that makes this worth a post. These apps aren't naive about loopback trust. All three ship a defence against exactly this, built for a related attack called DNS rebinding, where a web page you're visiting quietly points a name at 127.0.0.1 and talks to your local services through your browser. The defence is to check the Host header and refuse anything that isn't localhost or on a whitelist.

So out of the box, through a proxy that forwards your real hostname, all three say no:

Transmission  421 Misdirected Request
Syncthing     403 Host check error
Ollama        403

Transmission's 421 even explains itself, and points you at the fix:

421: Misdirected Request. Transmission received your request, but the
hostname was unrecognized. To fix this, choose one of the following options:
 - Enable password authentication, then any hostname is allowed.
 - Add the hostname you want to use to the whitelist in settings.
   [...]
This requirement has been added to help prevent DNS Rebinding attacks.

Fair enough. So you go and read the reverse-proxy guide. Ollama's FAQ tells you to set Host to localhost:11434 for nginx, ngrok and Cloudflare. For Syncthing it's the top answer in a years-old docs issue. Either way it's the natural fix, because otherwise the app blocks your shiny new proxy. One line in the config:

proxy_set_header Host localhost;

And that's the Host-check gone. Every request now arrives claiming to be localhost, from 127.0.0.1, with no password. Here's what each one hands over.

Transmission: the whole RPC, read and write

Transmission's RPC is the interface Tavis Ormandy turned into remote code execution in 2018 through DNS rebinding. Out of the box it wants no password (rpc-authentication-required is false), just the Host-check you've now removed.

The first request back a 409 with a session id. That looks like a login, but it isn't - it's an anti-CSRF nonce, handed to anyone who asks. Send it straight back and the RPC answers:

$ curl proxy/transmission/rpc -d '{"method":"session-get"}'
409 Conflict   X-Transmission-Session-Id: gn2cIH...

$ curl proxy/transmission/rpc -H 'X-Transmission-Session-Id: gn2cIH...' \
    -d '{"method":"session-get"}'
{"result":"success","arguments":{"version":"4.1.4",
 "download-dir":"/root/Downloads", ...}}

That's read. session-set works the same way, so an outside request can change where Transmission writes files too - the first half of Ormandy's trick. No credentials anywhere.

Syncthing: the admin API, and its master key

Syncthing ships with no GUI password. Its REST API wants a CSRF token for writes, but it hands one out to anyone who loads the page, since the page has no password either. Grab the token, then read the config:

$ curl proxy/rest/system/config
{"gui":{"user":"","password":"","apiKey":"..."}, "devices":[...]}

No user, no password, and apiKey right there in the response. That key is Syncthing's all-access credential - with it you can rewrite the whole config, add your own device, redirect folders. Even if you later set a GUI password, the key you leaked still works.

Ollama: your models, and the GPU behind them

Ollama's the plainest. With the Host rewrite its API just answers:

$ curl proxy/api/tags
{"models":[ ... ]}

/api/tags lists your models. There's no auth in front of any of it, so /api/pull, /api/delete and /api/generate answer the same way - an outsider can pull a model onto your disk, delete the ones you have, or run prompts on your GPU. Ollama's had no auth of its own for most of its life, on the assumption it's only ever reachable from the machine it runs on. Which was true until you tunnelled it.

Not everything falls over

qBittorrent 5.3.0 is the counter-example. Through the same proxy it returns 403 Forbidden, because it now prints a random one-time WebUI password on first start and its old "bypass auth for localhost" toggle ships off. So this isn't a law of reverse proxies - it's three apps whose "localhost is safe" assumption the proxy quietly breaks, and one that stopped making it.

The difference is just whether the app has real auth that doesn't lean on where the request came from. A password, an API key you actually have to send, a token at the edge - any of those and the proxy's loopback address buys an attacker nothing.

And it's not a lab toy. GPUStack, a server for running models across GPUs, had the same bug: any request from loopback was handed admin, and a same-box reverse proxy made every outside request look like loopback. It was exploited in the wild and added to CISA's known-exploited list last week. Same shape, a bigger blast radius.

So before you tunnel anything, the one rule: a tunnel is not a password.

Turn on the app's own auth, or put a password or SSO layer at the proxy, before it's reachable.
Never "fix" a Host-check error by whitelisting your public hostname or rewriting Host to localhost without also setting auth. That error is the rebinding defence doing its job.
Check any "trusted networks", "bypass for local addresses" or "no auth on localhost" toggle. Behind a same-box proxy, local means everyone.

What gets me is the shape of it. These apps saw loopback abuse coming and shipped a defence against it, and then the standard way to get them working behind a proxy is the one thing that switches it back off.

Chrome's dark mode stops flipping logos at 65 pixels

Iain — Thu, 12 Nov 2026 16:47:24 +0000

Here's Chrome's forced dark mode drawing six favicons, first at 64 pixels and then at 65.

Chromium 156 with forced dark mode on. The "Normal" row is how they look on a white page, kept out
of dark mode, so the see-through corners show white there and dark below.

At 64 it turned Uber's and Medium's black tiles white, gave Apple a dark version, and left OpenAI and Wikipedia as bright white squares on a dark page. At 65 it didn't touch any of them.

Forced dark is the "Auto Dark Mode for Web Contents" flag on desktop, and the "Apply dark theme to sites, when possible" box in Chrome's theme settings on Android. It repaints light pages dark unless the site says it has a dark mode of its own. Hardly anyone has it on, about one Chrome page load in 1,850 by Chrome's own count. But Safari announced its own version last week, and I wanted to know how a browser decides which of your pictures to flip.

It gets a ruler out first

Chrome only considers flipping a picture if it's drawn at 64 CSS pixels or less each way. Anything bigger counts as a photo and is left alone, whatever's in it. Screen resolution and page zoom are taken back out first, so 64 is 64 on a phone or a 4K monitor. It does go by the size in the layout rather than what you see, though, so a 40px icon blown up with transform: scale(2) is 80 pixels on screen and still flips. (The one side door is for images 8 pixels thin or less, which Chrome treats as separator lines and considers at any size.)

The 64 is new. Until Chrome 151 in July, a picture counted as an icon if it took up no more than 13% of the screen each way, so on a 1080p monitor anything up to about 250 by 140 pixels was fair game, and less on a smaller screen. The change that replaced it is pretty frank about why:

The previous ratio-based threshold scaled with the screen size and device scale factor, so the
same image could be classified differently depending on the display it was shown on.

Chromium commit 2c0b79c

Then it counts the greys

A picture that gets past the ruler goes to a classifier that samples up to 1,000 of its pixels. Pictures that are mostly strong colour are left alone, which is why Google, Spotify, Slack and ten other logos I tried that are mostly colour didn't flip. Grey ones get sorted into 16 shades of grey, and Chrome counts how many shades turn up. Fewer than 13 and it flips the picture, unless it's light marks on a see-through background. 13 or more and it can't make its mind up, so it asks a neural net.

I copied the classifier into Python, the net's weights and all, and it agrees with Chrome on all 35 pictures I'd tried. Here's how the grey favicons went, with the shades as my copy counted them:

Favicon	Shades of grey	Decided by	Flipped
Vercel	8	Count	Yes
Medium	11	Count	Yes
Apple	12	Count	Yes
Uber	12	Count	Yes
X	13	Net	No
Notion	13	Net	No
Wikipedia	13	Net	No
OpenAI	15	Net	No

Uber's and X's are the same idea, a white mark on a black tile. The smoothing round Uber's letters comes to 12 shades, and X's diagonals make 13. One more shade, and it's the net's problem.

The net itself is four inputs, ten neurons and one output, 61 numbers in all, compiled straight into Chrome as a block of hex. Its inputs are whether the picture's in colour, how many shades it found, how much of it is see-through, and how much is background. When I ran it over a spread of made-up inputs, that last one decided most of the answers. Chrome works that out by going through the picture from the top left and counting see-through patches until it hits a solid one, so a solid square favicon has no background at all, and the net said no to every one of them. OpenAI's logo is all curves, which means lots of greys, which means it stays a white square.

So Chrome turned two black tiles white and left two white squares white. It did get Apple's right.

Keeping out of it

If your site has a dark mode of its own, say so, and Chrome leaves the whole page alone:

:root {
  color-scheme: light dark;
}

The <meta name="color-scheme" content="light dark"> tag does the same. That only helps if you've actually written dark styles, mind, since the browser hands you a dark background and expects you to do the rest. It also only worked when Chrome's own theme was dark. With a light theme and the flag on, it flipped the logo anyway. For one picture that should never change, color-scheme: only light on the img keeps it as it is. Plain color-scheme: light, without the only, didn't.

Your header logo can take the big one with it

SVG files in an <img> get the same ruler, so a big SVG logo on its own is left alone. But if the same file has already been drawn small further up the page, say as the logo in your header, the big copy gets whatever the small one got. Here's a black circle on a white square, drawn at 32 pixels and then at 120, once as a PNG and once as an SVG:

The same logo as a PNG and as an SVG file, each drawn at 32px and then 120px, in Chromium 156 with
forced dark mode on.

The PNG copies are judged one at a time, so only the small one flips. The SVG's circle and its square both turn white at 32 pixels, and the 120 pixel one goes the same way, so the logo's just gone, twice. Swap the order round so the big one's drawn first and neither changes. color-scheme: only light on the big copy saves it, too.

Which is a bit awkward, as WebKit's advice for getting your site ready for Safari's version is to swap your bitmap logos for SVG.

Linux thinks Ireland is on daylight saving all winter

Iain — Thu, 12 Nov 2026 16:46:54 +0000

Ireland's clocks do exactly what the UK's do: GMT in winter, an hour ahead in summer. Ask most computers, though, and Ireland's on daylight saving time right now, in November.

Which is why Robot Framework, the test automation tool, can't tell the time in UTC from Dublin. I asked it at 16:07 UTC this afternoon, with the clock set to Dublin and then to London:

$ TZ=Europe/Dublin robot clocks.robot
NOW 2026-11-12 16:07:44
UTC 2026-11-12 15:07:44
$ TZ=Europe/London robot clocks.robot
NOW 2026-11-12 16:07:45
UTC 2026-11-12 16:07:45

London's right. Dublin's an hour early, and from the end of March it'll be an hour late instead. It's been like that since 2018.

Irish law makes winter the exception

In Ireland, summer time is the standard. The Standard Time Act 1968 put the clocks an hour ahead of GMT "throughout the year", and the 1971 amendment added a "period of winter time" when they're on GMT. So legally, the Irish clocks go back for winter rather than forward for summer.

The tz database, which nearly every computer gets its time zones from, took that literally in 2018 after Derick Rethans (who looks after PHP's dates) pointed it out. Dublin's winter is now daylight saving time of minus one hour. Some software couldn't cope with a negative one, so there's also a "rearguard" copy of the data, done the old way round.

The offsets and the names, GMT and IST, are the same either way. Only one flag changes, tm_isdst. Here's zdump on two Linux distros at the moment the clocks went back last month (trimmed):

debian:trixie  Oct 25 01:00 GMT isdst=1
rockylinux:9   Oct 25 01:00 GMT isdst=0

Rocky, like Red Hat, ships the rearguard copy. Debian, Ubuntu, Fedora, Arch and openSUSE all ship the main one. I asked Python, Go, Ruby, Perl, PHP, .NET, Rust and Postgres whether a winter's day in Dublin is daylight saving, and they all said yes. Java said no, as it turns the negative one back into an ordinary summer time when it builds its own copy of the data.

Python's snippet mixes two answers

The top answer to "Getting computer's UTC offset in Python" on Stack Overflow, from 2010 and with 111 votes, is this:

is_dst = time.daylight and time.localtime().tm_isdst > 0
utc_offset = - (time.altzone if is_dst else time.timezone)

time.timezone is meant to be your standard offset and time.altzone the daylight saving one, both in seconds west of UTC (hence the minus). On Linux, Python doesn't get those from the C library. It looks at the clocks in January and July and calls whichever is further ahead daylight saving, which is right nearly everywhere and backwards in Ireland.

So in Dublin, Python's timezone is 0 (GMT) and its altzone is -3600 (IST). But tm_isdst comes straight from the C library, which calls winter daylight saving. Mix the two and you get it backwards every day of the year:

In Dublin	Real offset	`tm_isdst`	The snippet says
January	+0	1	+1
July	+1	0	+0

time.daylight is 1 in Dublin, so the guard doesn't help. The same trick for the zone's name, time.tzname[tm_isdst], says IST all winter and GMT all summer.

Python's docs do warn that those constants "may be incorrect for times in the past". In Dublin, the present too. They say to use tm_gmtoff and tm_zone instead, which come straight from the C library:

lt = time.localtime()
lt.tm_gmtoff  # 0, in seconds
lt.tm_zone    # 'GMT'

Or this, if you'd rather have a timedelta:

datetime.now().astimezone().utcoffset()

A CPython PR from Neil Schemenauer would make Python on Linux read the C library's values, and its tests expect that to put Dublin right. It's still waiting for a review.

It's in llm, and a few hundred other places

GitHub's code search finds time.altzone if time.localtime().tm_isdst in about 270 Python files, and there are plenty more written other ways. Robot Framework's is the one above.

llm, Simon Willison's command line tool for language models, has a built-in llm_time tool that a model can call to find out the time. It uses both tricks, so in Dublin today it tells the model this (trimmed):

{
  "utc_time": "2026-11-12 16:07:51 UTC",
  "local_timezone": "IST",
  "local_time": "2026-11-12 16:07:51",
  "timezone_offset": "UTC+01:00",
  "is_dst": true
}

The local time and UTC match, then it says they're an hour apart, in the summer zone. Good luck to the model.

It's also in AWS's date functions macro for CloudFormation, which gets away with it on Lambda, where the clock's UTC unless you change it. And in Stockfish's fishtest worker, which logs a local offset of +01:00 all through an Irish winter.

Morocco's an hour out until January

Ireland's at least wrong the same way every year. Morocco moved to GMT for good on 20 September (it's in tz release 2026c). Python works its constants out from this January, when Morocco was on +1, so the same snippet has said +1 there ever since, against a real +0.

A Python started in 2027 looks at the new January and gets it right. Anything started before then stays an hour out until it's restarted.

Self-hosted Mattermost sends your DMs via Google and Apple

Iain — Wed, 11 Nov 2026 18:59:05 +0000

Mattermost's mobile FAQ has a line for anyone who self-hosts it to keep their chat to themselves:

Default server settings have message contents turned off.

Here's what a brand-new Mattermost 12.1 server sent when alice DMed bob, who has the Android app. (it's trimmed, but nothing's changed)

{
  "message": "the spare key is under the blue plant pot, code 4417",
  "sender_name": "@alice",
  "channel_name": "@alice",
  "type": "message",
  "platform": "android_rn-v2",
  "device_id": "FAKE-FCM-TOKEN-0001"
}

That goes to push-test.mattermost.com, Mattermost's free Test Push Notification Service (TPNS), which passes it to Google's Firebase for Android phones or Apple's push service for iPhones, and they then put it on bob's lock screen. An @mention in a channel works the same way, as "@alice: @bob the wifi password is now otter-pancake-91".

I ran the server in Docker on a network with no way out. The only setting I touched was the relay's address, so the push came to a little listener of mine instead, and everything else was how the server came. The hop from the relay to Google or Apple is from the relay's source, which copies message straight into what it sends them.

By default it does this for every DM and @mention, unless you're actually looking at that conversation at the time or you're on Do Not Disturb. If your server was set up since mid-2020 and nobody's changed Push Notification Contents, yours does it too. You can see it in the System Console, under Site Configuration, Notifications, or on the server if local mode's on (it is in the Docker image):

mmctl --local config get EmailSettings.PushNotificationContents

"full" means the message goes in the push.

Generic, according to the docs

The settings docs mark "Generic description with sender and channel names" as the default, which only says who sent it and where. A few lines further down that FAQ, it also says push notifications are disabled by default. My new server had them on, pointed at the test relay.

The server's own default is full, and has been since a pull request in May 2020 that made it full "to improve user experience in Mattermost for new installs". It's still there in 12.1:

if s.PushNotificationContents == nil {
    s.PushNotificationContents = new(FullNotification)
}

That only fills in a setting the config file hasn't got. A server from before 5.24 already had generic written into its config, so it kept it, and anything newer got full. The Helm chart and Mattermost's own Docker setup don't change it, and the docs still say generic today.

To be fair, the System Console tells you if you go and look. Its help text says full content "is relayed through Apple's Push Notification Service (APNS) or Google's Firebase Cloud Messaging (FCM)". But you'd only go and look if you didn't believe the docs.

Three companies in the middle

The connection to the relay is HTTPS, but the relay itself gets the message as plain JSON, and Mattermost's terms say "messages sent via the TPNS will not be encrypted" and "You assume all risk". The relay's open source code doesn't log the message, but I can't see what push-test.mattermost.com actually runs. Mattermost's own docs say TPNS isn't recommended for production, which is a funny thing for every new server to point at.

Then Google or Apple, who get the text, who sent it and the channel name. In December 2023 Senator Wyden said foreign governments had been asking both of them for push notification data.

The other messaging apps don't do this

Push always goes via Google or Apple, but what's in it is up to the server and the app. Here's what each one sends by default:

Server	What's in the push
Mattermost 12	The message, who sent it and the channel
Rocket.Chat	The message, who sent it and the room
Matrix, with Element X	An event ID, and the app fetches the message itself
Prosody (XMPP)	No message or sender, at most a placeholder "New Message!"
Zulip 12	Only ciphertext the app can read, if the app's up to date

Only the Mattermost row is from my capture. The rest are from each project's source and docs, and Rocket.Chat's has been known for years. Its staff said on its forum in 2021 that the message would "STILL be in plain text" even through a European gateway.

Mattermost and Rocket.Chat can both do it the Element X way, where the push only carries an ID and the app fetches the rest, and both want a licence for it. Mattermost calls it "Full message content fetched from the server on receipt". I picked it on the free Team Edition anyway, and the server quietly sent the generic version instead.

Switching it off

Set Push Notification Contents to "Generic description with sender and channel names", or "Generic description with only sender name". The setting lives under EmailSettings, for some reason, so with mmctl or Docker it's:

mmctl --local config set EmailSettings.PushNotificationContents generic
MM_EMAILSETTINGS_PUSHNOTIFICATIONCONTENTS=generic

Then bob's phone just says alice sent him a message, and he has to open the app to find out where the key is. Running your own relay is the other way, but only Mattermost's relay holds the Apple and Google keys for the store apps, so that means building your own apps too.

Mattermost's admin onboarding checklist has a step for this setting as well. Number 4 is "Enable full content push notifications".

jsDelivr handed out the hijacked axios 940,000 times

Iain — Mon, 09 Nov 2026 16:49:50 +0000

cdn.jsdelivr.net/npm/axios@1

Put that in a script tag and the @1 means "whatever the newest 1.x is right now". For about three hours on 31 March, the newest 1.x was 1.14.1, the version an attacker published from the lead maintainer's npm account. jsDelivr's public stats count 941,960 requests for it, and 98.5% of them were for dist/axios.min.js, the browser build.

None of that did any harm. The malware was in a new dependency, plain-crypto-js, which dropped a remote access trojan when you ran npm install (Snyk has the details). A script tag doesn't install anything, so the browser build was clean, and the advice at the time said so:

If you are loading axios via a CDN such as unpkg, none of this executes.

iblue.team

Which is true, but only because the attacker was after developers' laptops. Their release still went out to all those script tags, it just had nothing in it for them.

The ones that did go after browsers

Two earlier hijacks did aim their malware at browsers, and reached a tiny fraction of that.

Hijack	Aimed at browsers?	Requests for the bad versions
lottie-player, Oct 2024	Yes	3,965
chalk, debug and co, Sep 2025	Yes	884
axios, Mar 2026	No	941,960

chalk, debug and the rest carried exactly the right sort of malware for a web page, code that swapped crypto wallet addresses, but almost nobody loads chalk from a CDN. lottie-player is an animation player that people really do drop into pages with a script tag, and about 125,000 requests a day followed its newest version. Its three bad versions asked visitors to connect their crypto wallets, were replaced the same day, and still got nearly 4,000 requests. At least one person lost 10 bitcoin.

Put lottie's payload on axios's crowd for three hours and it's a very different write-up.

How it got there so fast

The release before the hijack shows how quickly that @1 moves. axios 1.14.0 came out at 19:01 UTC on 27 March. Through that week, 1.13.6 had been getting 17 to 20 million jsDelivr requests a day. The day after, it got 750,000.

Daily jsDelivr requests for two axios versions, in millions (the data)

1.14.0 came out on the evening of 27 March. The hijacked 1.14.1 was out for three hours on 31
March, too few requests to see at this scale.

So about 17 million of axios's 25 million daily jsDelivr requests take whatever's newest, and they all move over within a day. Three hours of that would be about two million, and 1.14.1 got under half. I'm not sure why. My guess is jsDelivr's edge servers, which hang on to what @1 means for up to 12 hours (s-maxage=43200), so plenty of them never noticed 1.14.1 before it was gone.

That cache works the other way round in your visitors' browsers. They're told they can keep the answer for a week (max-age=604800), so anyone who caught a bad release could keep running it for days after npm pulled it.

Nobody has to do anything daft to end up floating. hls.js's README says hls.js@1, Alpine's starts you on alpinejs@3.x.x (it does say to pin for production, further down), and the first example on Chart.js's getting started page is cdn.jsdelivr.net/npm/chart.js, with no version at all. Copy the snippet and you're on the newest release forever.

Pinning yours

Put the exact version in the URL, and an integrity hash so the browser refuses the file if it ever changes. jsDelivr's page for each package will copy you the tag with the hash already in:

<script
  src="https://cdn.jsdelivr.net/npm/axios@1.21.0/dist/axios.min.js"
  integrity="sha384-p5EwRuz37ylAY9QrjGGIs9ngKVaIwppUFSourks9EIRp1CzoIDWoQkXrHxaAUhEB"
  crossorigin="anonymous"
></script>

An integrity hash on a floating URL doesn't pin anything. The next release changes the file, the hash stops matching, and the browser won't run it. That beats running a hijacked release, but you'll hear about it from your users first. Or serve the file yourself, which is what a bundler's been doing for you all along.

To find the floating ones in a page you've already got:

curl -s https://your.site \
  | grep -oE '(cdn\.jsdelivr\.net/npm|unpkg\.com)/[^"]+' \
  | grep -vE '@[0-9]+\.[0-9]+\.[0-9]+'

Anything it prints doesn't name an exact version. It only sees tags in the HTML though, not ones a script adds later, so open the Network tab, filter on jsdelivr, and click about a bit. If the URL's got @1, @latest or no @ at all, somebody else picks what runs there.

The ones you can't pin

Of jsDelivr's 200 busiest npm packages, 71 put out a new release in the last month, and at least 22 of those had half their jsDelivr traffic on it within two days.

Share of jsDelivr requests on a package's newest release, two days in (the data)

Swiper, three.js, KaTeX and Video.js barely move, so most of their users seem to pin. hls.js is the big one. About 140 million requests a day sit on its newest release, nearly ten times what axios's floaters get these days, and they aren't all hobby pages: urlscan.io has public scans of Amazon product pages fetching hls.js@1.

A lot of the other fast movers are companies' own browser SDKs, there to be loaded straight off jsDelivr by a snippet the company gives you. GrowthBook's feature flags are at 94% after two days, Zonos's checkout at nearly all of it, SheerID's ID checks at 84%. Meta's Conversions API helper, at 85% of 90 million requests a day, says why in its README:

The unversioned URL follows the latest npm release so integrations receive SDK updates
automatically.

Meta's capi-param-builder

Which is handy. It also means whoever gets into their npm account gets a script tag on your site.

Why the Wayback keeps saving Anubis's bot check

Iain — Sun, 08 Nov 2026 16:29:09 +0000

Haiku's bug tracker is fine in the Wayback Machine, according to a check on Anubis's issue tracker. Someone tried 22 sites that use Anubis in the Wayback at the start of October, and ticked off the 16 that came out as the real page, Haiku's included. Here's the newest copy the Wayback has of it, from ten days after that:

The Wayback's newest copy of dev.haiku-os.org, as of 8 November.

Anubis is the proof-of-work page a lot of open source sites put up in 2025 to keep AI scrapers off: GNOME's GitLab, FFmpeg, the Arch wiki, Haiku and plenty more. Its default settings let the Internet Archive straight through, and the check above was done the way everyone does it, with the Wayback's save button. So why's that copy a wall?

It wasn't the Internet Archive's crawler

Click "About this capture" on that copy's banner and it says who collected it: ArchiveTeam, the volunteer group that runs its own crawlers on volunteers' machines and hands what they grab to the Internet Archive. It all goes in the Wayback, next to the Archive's own copies, and you can't tell them apart unless you click.

Anubis lets the Internet Archive in by its IP addresses. This is the whole rule:

- name: internet-archive
  action: ALLOW
  remote_addresses:
    ["207.241.224.0/20", "208.70.24.0/21", "2620:0:9c0::/48"]

ArchiveTeam's crawlers don't come from those addresses. Their URLs project runs on volunteers' own connections and sends a browser's user agent. Since this spring it passes itself off as Firefox, down to the way it sets up the TLS connection:

'--impersonate', 'firefox148-h1',

Anubis's default policy gives anything that says it's a browser a proof-of-work challenge, which needs JavaScript to solve. The crawler doesn't run JavaScript, so it saves the challenge page as the page. It came back with a 200, so the Wayback files it as a good copy, and the calendar marks the day blue like any other.

The save button always gets in

That's why the check in the issue came out so well. Save Page Now is the Internet Archive's own crawler, from the Archive's own addresses, so it's on the allow list. ArchiveTeam's own wiki page on Anubis says as much, "IA SPN is not blocked". So when someone running Anubis checks whether the archive can get in, it can. The broken copies people have reported on Anubis's tracker (#34, #1781) got put down to the Archive's addresses being missing from that rule, or out of date, and nobody there has mentioned ArchiveTeam.

Who gets the wall

I went through the sites on Anubis's list of known users, front pages plus a few deep ones, and opened up to five Wayback copies of each from June 2025 on. Of 345 copies, 140 were Anubis. That gives every address the same five, though, and the busier ones get walled less, so across everything the Wayback holds for them it's more like a quarter. Here's who collected them:

Wayback copies that are an Anubis page, by who collected them (the data)

Copies from June 2025 to November 2026. ArchiveTeam's URLs project 83 of 100, ArchiveBot 33 of 43, Common Crawl 16 of 33, the Internet Archive's own crawlers 8 of 169.

It isn't down to which sites each one happened to visit. Taking just the 50 addresses that have copies from both ArchiveTeam's crawlers and the Archive's, ArchiveTeam's were the wall 95 times in 121, and the Archive's twice in 98. And it's still happening. Since July, 17 of the 18 ArchiveTeam copies I opened were the wall.

Common Crawl gets walled a lot too, and half of those are Anubis's "Oh noes!" page, the one it shows when a rule turns you away, so I think some of those sites block it on purpose.

An undated Wayback link, the sort people paste around, opens the newest copy, and for 21 of the addresses that was the wall. I followed an undated link to each of them today, and 11 still land right on it, among them FFmpeg's git, FreeBSD's Subversion browser and the Azur Lane wiki, another one the October check had ticked. The rest have something newer now, like a redirect, or the Wayback wouldn't answer me.

Is there a fix?

Not a clean one that I can see. The URLs project looks exactly like Firefox, so there's nothing for a rule to match. ArchiveBot, ArchiveTeam's crawler for whole sites, does say who it is. Its user agent starts ArchiveTeam ArchiveBot/ and goes on and not Mozilla/5.0, which Anubis's browser rule catches, because it's looking for the word Mozilla. You could let that user agent through, but so could any scraper that copies it. ArchiveTeam talked to Anubis's author about signed crawler identity last year, which would sort it properly, but it isn't there yet.

If you run Anubis, look your site up in the Wayback and check who collected the last few copies. And if you're digging through the Wayback for a project's history since 2025, a copy titled "Making sure you're not a bot!" doesn't mean the site was down. Step back a day or two and find one the Internet Archive collected.

npm's worms ride a few big accounts, not your dependencies

Iain — Sat, 07 Nov 2026 17:34:26 +0000

At 10:41 UTC on 4 August, one npm account published poisoned versions of 132 packages. It took two and a half seconds. Another company's scope had lost 140 the same way two minutes earlier, in three.

That was ChainDrop, the worm that started with keyv, and the latest of the six big npm worm outbreaks since the first Shai-Hulud in September last year. They all work in roughly the same way. A poisoned package runs a script when you install it, finds an npm token on your machine or in your CI, and uses it to publish poisoned versions of your packages, so whoever installs one of those is next. The write-ups count the damage in hundreds of packages, which makes it sound like it's tearing through everyone.

I wanted to know who actually published them.

Poisoned npm packages in each outbreak, by the account that published them (the data)

Each block is one account, as wide as the number of packages it poisoned. Packages created less
than 30 days before their bad version are left out, since those are mostly the attackers' own
throwaways. Mini Shai-Hulud's bar starts from its return in May.

That's about 2,000 packages from 175 accounts. Apart from Shai-Hulud 2, each outbreak involved between 5 and 26 accounts, and in four of the six the five busiest accounts put out 94% or more of the packages.

npm keeps a version's publish time even after it's been pulled, so I grouped the packages by who maintains them and counted each group as one account. ecosyste.ms kept a record of who actually published about a third of the bad versions, 230 packages across nearly 70 groups, and every group came back with one publisher. Where there's no record, a group with several maintainers could hide a few more accounts, but even counting every one of them separately, it's 263 accounts rather than 175.

The worm takes whatever the account can publish

One account is worth 132 packages because the worm publishes everything the stolen token can reach, up to a limit its author picked. The first two asked npm for the account's packages by searching for maintainer: and its name. The first Shai-Hulud asked for 20, Shai-Hulud 2 asked for 100, and ChainDrop goes for every package the account can publish.

You can see the limits in the counts. The first Shai-Hulud's busiest account poisoned exactly 20 packages within a few minutes, then nine more later that day, and the next four did between 15 and 22 at a time. Shai-Hulud 2's busiest did 98 in ten minutes, and five more after that. ChainDrop's two biggest did 140 and 132, all at once.

With a cap of 100, Shai-Hulud 2 had to reach a lot of accounts to get big, and it did. Without one, an account that looks after a few hundred packages is an outbreak on its own.

You can run the same search the first two worms did, and it doesn't need a login:

curl -s 'https://registry.npmjs.org/-/v1/search?text=maintainer:YOUR_NAME&size=250' | jq .total

Mine says 1, which is the one upside of not having written much.

The day Shai-Hulud 2 spread

Shai-Hulud 2 is the one that behaved like the worm you'd picture. It started with AsyncAPI's packages at 03:10 UTC on Monday 24 November 2025, with PostHog's and Postman's among the first after it, and reached 101 accounts by 17:54.

New accounts publishing Shai-Hulud 2, by hour (the data)

24 November 2025, in UTC. Each account counts once, in the hour it published its first poisoned
package.

The first packages were all gone by lunchtime. PostHog had deleted its by 9:30, Postman by 11:30, and npm pulled AsyncAPI's at 11:46 (Wiz collected the times). But 9:00 till noon was still the busiest stretch for new accounts. By then it was in other people's packages too, like the account that put out 98 of them just after ten.

After 17:54, nothing. Nobody's said why. Datadog saw the same cut-off and guessed that npm may have stepped in, which is as good a guess as any.

It didn't go down the dependency tree

This is the bit that surprised me. You'd picture the worm working its way down the dependency tree: my package depends on a poisoned one, I install it, my token goes, and my packages are next.

So for every account after the first in each outbreak, I took the last clean release it published before its first bad one, and checked whether that depended on anything that was already poisoned, in a version range that would've picked up the bad release. 139 accounts had a clean release to check. If that's how the worm travelled, most of them should've had one.

Two did. As a placebo, I ran the same check on the same 139 against packages that only went bad later, which can't have caused anything, and got four. For Shai-Hulud 2 I also went a level further down, to the dependencies of those dependencies, and found two more, against none for the placebo. That's chance.

So whatever got these people, it wasn't the packages they publish depending on a poisoned one. My guess is it was something else they installed, like a dev tool, a CLI installed globally, or an app that never goes on npm, none of which shows up in the published dependency tree. Either way, whether your package depends on something poisoned doesn't tell you if you're next.

This year's look like fresh starts

The 2026 outbreaks don't come in one burst. Mini Shai-Hulud hit four SAP packages on 29 April, went quiet, then came back on 11 May with TanStack's and reached 14 accounts in about five hours. A week after that, a single account published 310 AntV packages in six seconds, which SafeDep says the attacker did with a stolen token. Miasma came in three waves, the last three weeks after the first. Each wave starts with one big account, which looks more like someone kicking it off again than the worm finding its own way there.

Trusted publishing didn't stop it

TanStack's 42 packages went out in five seconds, published from GitHub Actions through npm's trusted publishing, which swaps a stored npm token for a short-lived one the release workflow gets each time it runs. According to TanStack's postmortem, no npm token was stolen. The attacker poisoned the Actions cache from a pull request, and when the release workflow next ran, the payload read the workflow's token out of the runner's memory. Miasma's biggest account, 49 packages, also published through trusted publishing, going by ecosyste.ms's records.

So trusted publishing gets rid of stored npm tokens, like the one in ~/.npmrc, which is what the first two worms lived on. But anyone who can run code in your release workflow can still publish as you, and everything that workflow can publish goes out at once.

What makes you a dead end

Two settings make you a dead end for some of these. ChainDrop only spread when the stolen token could publish without 2FA, so a token that can't skip 2FA was no use to it. And Shai-Hulud 2 and ChainDrop both started from a preinstall script, which npm 12 no longer runs for your dependencies until you say so. I tried it with npm 12.0.2 and a package whose preinstall just creates a file. The file never turned up:

npm warn install-scripts 1 package had install scripts blocked because they are not covered by allowScripts:
npm warn install-scripts   hooky@1.0.0 (preinstall: touch ./RAN)

Ubuntu 24.04 gets kernel fixes two months after Debian

Iain — Thu, 05 Nov 2026 16:33:47 +0000

Ubuntu 24.04 still hasn't got the fix for CVE-2026-98432, a bug in how IPv4 hands over a new TCP connection, which Canonical rates critical and says can lead to remote code execution. It went public on 15 October. Debian 13 shipped the fix the next day. On 24.04 it's listed as pending, in a kernel that's been in -proposed since 26 October.

It got a couple of angry blog posts, chalmovsky's (1,600 points on Hacker News) and Ariadne's, both about this one CVE. It's not a one-off. I took all 7,823 CVEs the kernel's CVE team has published since 1 March, and for each one found when the fix reached Ubuntu 24.04's security updates (from its security notices) and Debian's (from its security tracker, dated by when the fixed kernel turned up in Debian's security archive).

Kernel CVEs fixed, by how long after they went public (the data)

CVEs published from March to July 2026, so each has had at least three months. Each line is the share of the CVEs affecting that release which it had fixed by then.

For CVEs from March to July, Debian 13 had already fixed 68% by the day they went public. That's because the kernel's CVE team only automatically assigns a CVE once the fix is in a stable kernel, and Debian 13 ships those stable kernels, so the fix is often out before the CVE has a number. Ubuntu 24.04 had fixed hardly any by then, and only 14% after six weeks.

Across everything since March, Ubuntu 24.04's median wait is 64 days, counting the CVEs it's fixed so far. On the 2,574 CVEs both have fixed, Debian 13 got there first on 2,558, by a median of 74 days.

The bad ones don't jump the queue, either. CVEs Canonical itself rates high or critical took a bit longer than the rest. 24.04's default kernel is the slowest Ubuntu one I checked, but not by much: 22.04, 26.04 and the 7.0 HWE kernel you can run on 24.04 have medians of 47 to 53 days.

Where the weeks go

Ubuntu 24.04 runs Linux 6.8, which upstream stopped looking after in May 2024. So Canonical maintains it itself, by taking the fixes going into the upstream 6.12 and 6.6 longterm kernels and porting them back in batches, each one tracked as a Launchpad ticket. From March to September, the newest upstream release in each batch was a median 55 days old by the time Canonical opened that ticket. The batch then goes through Canonical's own build-and-test cycle, which took another 20 to 60 days per kernel.

The old 6.8 base isn't the whole story, though. 22.04 is on 5.15, which upstream still maintains, and Canonical opens a ticket for each 5.15 release within days of it coming out. 22.04 still waits a median of 53 days, so the cycle after the ticket is slow too. Its 5.15.0-198 kernel went into -proposed on 7 September and reached the security updates on 5 October.

Here's one batch, the one that brought 6.12.101's fixes to 24.04:

3 August 6.12.101 comes out upstream.
6 August Debian 13, which runs 6.12, ships it as a security update.
23 September Seven weeks later, Canonical opens the ticket to port it (and 6.6.148) to 24.04.
30 September The kernel with it, 6.8.0-147, goes into -proposed.
13 October It reaches 24.04's security updates, 71 days after upstream.

The fixes arrive in lumps, too. The 13 October update alone brought 1,039 kernel CVEs to 24.04 for the first time, and it's still the newest default kernel 24.04 gets from apt.

Debian doesn't queue them. Roughly every two weeks Debian 13 ships the latest upstream 6.12 release, usually within days of it coming out. Debian 12, on the 6.1 longterm kernel, is slower (a median of 11 days) but nowhere near two months.

It's been worse

The kernel CVEs from August to November last year that 24.04 has fixed took a median of 160 days, so this year's a big improvement. Canonical moved to a two-week kernel cycle on 28 September, and October's kernel looks different. 6.8.0-149 ports everything up to 6.12.113, which was only five days old when Canonical opened its ticket.

That doesn't clear the backlog, though. The 1,566 kernel CVEs that 149 fixes for the first time on the default kernel had been public for a median of 39 days by the time it reached -proposed, and they're still waiting.

So if you run 24.04 on something exposed, don't take apt upgrade saying there's nothing to do as meaning you're covered. The CVE's page on ubuntu.com/security says whether your kernel's actually got the fix, and sometimes there's a stopgap. 98432's is an nftables rule that drops incoming IPv4 TCP packets carrying IP options, which Canonical says cuts the risk without closing it.

There's a quicker kernel on 24.04 right now, too. The 7.0 HWE one (linux-generic-hwe-24.04) got an update on 2 November with fixes for over 2,300 kernel CVEs published since 8 September, which the default 6.8 kernel is still waiting for. 98432 is pending on that one as well, mind. And if you want kernel fixes the week they're out, you want a distro that ships upstream's releases as they come, like Debian 13.

I'll run all this again in December, when the CVEs from after the switch have had two months. If the kernel after 149 keeps that five-day queue, half of this post will be out of date, which I'd be fine with.

Can the server you SSH into read your screen?

Iain — Thu, 05 Nov 2026 02:11:40 +0000

If you're using Git Bash, WezTerm or the xterm that comes with Debian or Ubuntu 24.04, then yes, it can. Any server you SSH into can read what was on your screen before you connected, and the last file you had open in nano or vim, without you typing a thing.

Here's a Debian server doing it to Git Bash. The secrets are fake, and everything under the first ssh line is what the server read back:

Git Bash's own window on Windows, SSHing into a Debian box on 4 November.

6.3m downloads of the Git for Windows installer since 28 September, and Git Bash opens in this window unless you pick otherwise
77s for a 50-line bash script to read a whole screen over SSH
0 settings in Git Bash's window that turn it off

What's going on

Terminals understand special codes that programs print to change colours or move the cursor. One of them, from DEC's old VT420 terminals, asks the terminal to add up the characters in a box on the screen and send back the total. It's meant for test suites, so they can check the terminal drew things properly.

But if the box is one character big, the total is just that character. So a program can ask about each spot on the screen in turn and rebuild the whole thing. Over SSH, the question travels down to your terminal like any other output, and the terminal's reply goes back up as though you'd typed it.

nano and vim also draw on a second, hidden screen, which stays in memory after you quit, and clear doesn't wipe it. The server can switch to that screen and read it too, which is how it got the .pgpass in the picture. You'd see your old file come back up while it's being read, and that's the only sign.

How it got here

2018 xterm puts the code on its list of "dangerous" features that are switched off. Debian builds xterm with an older list of its own, so it's still on in Debian 12, Debian 13 and Ubuntu 24.04.
2019 WezTerm, and then mintty (the window Git Bash opens in), add the code so they can pass a terminal test suite.
2023 dgl writes up this exact attack: reading someone's screen as they SSH in.
2024 WezTerm's last stable release comes out, with the code still on. Homebrew, Scoop and Chocolatey still install that one.
2026 WezTerm switches it off in March, but only in nightly builds. Git Bash still does it.

Why it matters

It's only a problem with servers you don't fully trust. But that's a long list: a shared box, a client's server, or anything that's been broken into, where an attacker can just wait for the next person to log in. And what they get comes from your laptop, not the server: the tokens, passwords and config files you had on screen before you connected.

Checking yours

Here's who does it:

Can the server read your screen? (the data)

I tested the first three over SSH on 4 November. The rest are from each project's source code.

To check yours, paste this into bash. It clears the screen, prints an X, and asks the terminal what's in the top-left corner:

clear; echo X; s=$(stty -g); stty -echo -icanon; printf '\e[1;1;1;1;1;1*y'; read -rs -t 1 -d '\' r; stty "$s"; echo "${r:5:4}"

If it prints FFA8 or 0058, your terminal just read the X back, and a server could do the same. If it prints nothing or 0000, you're fine.

If yours read it back:

In Git Bash, use it inside Windows Terminal instead of its own window (the installer can add a profile for it). Otherwise, open a fresh window before you SSH anywhere you don't trust, because clear doesn't reach that hidden screen.
On WezTerm, switch to a nightly build.
On Debian's or Ubuntu's xterm, add this line to ~/.Xresources and run xrdb -merge ~/.Xresources:

XTerm*disallowedWindowOps: *

Wikipedia dropped this UUID in 2014. Now it's everywhere

Iain — Tue, 03 Nov 2026 16:38:59 +0000

550e8400-e29b-41d4-a716-446655440000

Recognise it? GitHub's code search reckons it's in about 303,000 files. That's twice as many as 123e4567-e89b-12d3-a456-426614174000, the other example UUID you've probably seen, and more than any other I tried apart from the all-zeros one. A fresh random one turns up in 0. One app with 2,000 stars even used it as the key that signs its logins.

It was Wikipedia's example. The UUID article used it from 2006 until 2014, when someone swapped it for the 123e4567 one, which MDN uses too. It isn't only Wikipedia's (an OVSDB RFC and Rust's uuid crate use it as well), but it's the sort of thing you'd expect to be quietly fading out by now. Wikipedia isn't helping, mind. Someone put it back on the page in 2023 for the URN example, and 123e4567 came off in 2024.

Nearly all of it is new

I picked 150 repos at random that have it and went back through each file's history to the commit that added it. 147 of them added it in 2025 or 2026, and 113 this year alone.

Issues and PRs show when it happened:

GitHub issues and PRs mentioning each UUID, by month (the data)

These are GitHub's issue search counts for each full string, by the month the issue or PR was opened, from January 2024 to October 2026.

Through 2024 it trailed 123e4567. Then it crossed over in mid-2025, peaked in March this year at 470 a month, and has nearly halved since. Something started handing it out again.

So I asked them

I gave Claude and Codex the same three requests, three times each: an example UUID, a JSON order object with a UUID id, and a Python test fixture with a hardcoded UUID. That's nine answers per model, on 3 November, with Codex running gpt-5.6-sol:

Model	What it gave me
Claude Sonnet 4.5	`550e8400` 8 times, something else once
Claude Haiku 4.5	`550e8400` all 9 times
Codex	`550e8400` for the examples, `123e4567` for tests
Claude Opus 5.5	a made-up `3f...` one all 9 times
Claude Sonnet 5.5	a made-up `3f...` one 6 times, `f47ac10b...` 3 times
Claude Haiku 5.5	a made-up `3f...` one 5 times, `123e4567` 3 times

The 4.5 models hand out Wikipedia's old one nearly every time. But the curve crossed over before either of them came out, so I'd guess the Claude 4 models had the habit too. Sonnet 4 has been retired, so I can't ask it. Of the 150 commits I dated, 22 had Claude Code's co-author line on them, against 12 of 150 for 123e4567. That's a lean rather than proof, since Claude Code adds that line by default, so its work is easy to spot and other tools' might not be.

Why that one and not 123e4567, I can't tell you. It wasn't the more common of the two in code before 2025, so it's not just that there was more of it to learn from. Its return to Wikipedia in 2023 might have helped, but that's a guess.

Claude's moved on

The newer Claude models never gave me 550e8400 at all. They mostly make one up, and they make up much the same one. 20 of their 27 answers started with 3f, and 12 with exactly 3f2b8c1e or 3f8a2c1e:

3f2b8c1e-9a4d-4e7b-8c21-5d6f0a9b7e43
3f2b8c1e-9a4d-4e7b-8e2a-6c5d0b1a9f47
3f2b8c1e-7a4d-4e9b-9c15-2d6f0a8b4e71
3f8a2c1e-7b4d-4e9a-a6c2-91d5e0b7f348

The start sticks, more or less, and the end wanders off. The first 18 characters of the top one, 3f2b8c1e-9a4d-4e7b, are already in about 370 files on GitHub, across at least 124 repos. I dated 50 of those, and every one added it in 2026, 21 of them with Claude Code's co-author line.

So if you find a 550e8400 in a repo you've inherited, it was probably written in the last couple of years, quite possibly by a 4.5 model or Codex, and a 3f2b8c1e-9a4d points at a newer Claude. More of a tell than I expected a UUID to be.

The other one I'd learn is 3fa85f64-5717-4562-b3fc-2c963f66afa6, in about 40,000 files. It comes from Swagger UI's example generator, which fills in example requests in API docs, so if it turns up in your logs, it's usually someone sending the example from your docs as it was.

When the example is the secret

Aix-DB, an app for asking your database questions in plain English, used this for its login tokens:

os.getenv("JWT_SECRET_KEY", "550e8400-e29b-41d4-a716-446655440000")

From release 1.2.0 its example config suggested this as the key, and from 1.2.2 the code fell back to it whenever JWT_SECRET_KEY wasn't set, which its Docker Compose file didn't do. So a default install signed its tokens with a key that's in 300,000 public files, and anyone could have made their own token with the admin role in it.

An automated security PR took the fallback out on 10 October, and the Compose file now refuses to start without a key. There hasn't been a release since, though, so 1.2.4 is still the latest. I found a couple more, in tiny repos and still live, so no names.

Opus 5.5's own answer, when I asked it for an example UUID, came with a warning:

I made it up by hand rather than generating it, so don't use it anywhere uniqueness matters - for that, run uuidgen.

Fair enough, coming from the family that's spreading 3f2b8c1e round GitHub.

Whoever takes your old GitHub name gets your MCP namespace

Iain — Mon, 02 Nov 2026 18:48:35 +0000

Rename your GitHub account and your MCP servers stay in the official registry under your old name. Whoever registers that name next can publish new versions of them, and the registry can't tell it isn't you.

On 2 November I checked every io.github name in the registry against GitHub. At least 111 names that published servers have since been renamed or deleted, and don't belong to any account now. Between them:

145 live servers are still listed
17,000 or so times a week, their npm and PyPI packages get downloaded
49 of them only have a remote URL, so there's no package to check at all

They're not toys, either. Here are the busiest:

Weekly downloads of the busiest servers under unclaimed names (the data)

These are npm and PyPI downloads over the last week, as of 2 November. Each one is listed in the registry under a GitHub name that nobody holds now.

aiterm-mcp lets your coding agent drive terminals, agents-fleet reaches every machine you've got over SSH, the Shodan and VirusTotal ones run with your API keys for those services, and azure-board-mcp wants a personal access token. Further down the list, four more handle crypto wallets, payments or transactions.

Why it works

The registry hands out io.github.<login>/* based on your GitHub login, not your account's ID, which is the bit that never changes (github_at.go):

permissions := h.buildPermissions(user.Login, orgs)

When you rename, GitHub's docs say your old name becomes available for anyone else to claim. Whoever claims it gets your namespace, and from there:

a new version is always active, and the highest one becomes latest
deprecating your old entry doesn't stop it (a maintainer said as much in October)
the package check only asks for a package that carries the server's name, and it doesn't have to be the one you published
a remote server has no package to check, so its next version can point at any URL

What a bad version gets

A local MCP server runs as you, with whatever keys you put in its config. A remote one sees every tool call your agent makes to it, and gets to write the answers.

If you installed the npm or PyPI package directly, a new registry version doesn't touch you. It's the clients and galleries that pick servers from the registry by name that would follow it, and the registry tells aggregators to copy it and keep their own copy.

Names are already changing hands

22 namespaces in the registry now belong to a GitHub account that was created after they were published. io.github.facebook is one, since Meta became meta on 28 October. So far most of them look like owners holding on to their old name, and none has published anything.

The other half has bitten for real. About twenty publishers have filed tickets since April because they're locked out of their own old entries, like PaidSync, whose old listing kept advertising an address they'd switched off until a maintainer stepped in.

If you've renamed

Register your old name again today. An empty org costs nothing. Once you hold the name, nobody else can publish there, and you can deprecate the old entries yourself.

If you install MCP servers, pin the package and version rather than trusting the registry name, and treat a change of package or URL between versions like a new server.

VS Code remembers the commands you hid with a space

Iain — Sun, 01 Nov 2026 20:04:02 +0000

VS Code's Run Recent Command list, in a new window on my laptop. Note the space before export. The token's a fake.

The top four were typed on a different machine. I'd opened a Debian server with Remote-SSH and put a space in front of the export, so the server's bash would skip it, and it did. The server's ~/.bash_history has cd /var/log, ls -lh and uptime, and no token. My laptop has it, and it's offering to run it again.

The space trick

If you've ever pasted a token into a terminal, someone's probably told you to stick a space in front. bash won't save a line that starts with one when HISTCONTROL has ignorespace or ignoreboth in it, which Debian and Ubuntu set up for you, and zsh does the same with setopt HIST_IGNORE_SPACE. It's the accepted answer on unix.SE, along with history -d for when you forgot.

Both of those only change what the shell writes down, though, and VS Code keeps its own list.

Where it goes instead

VS Code injects a shell integration script into bash and zsh, on by default. Among other things it reads each command as it runs, and a leading space doesn't stop it. When the command finishes, anything that isn't blank goes into a list of your last 100, which VS Code keeps in a SQLite file in its user folder:

~/.config/Code/User
- globalStorage
- state.vscdb commands
- state.vscdb.backup
- workspaceStorage
- 1d6fb3dd...
  - state.vscdb scrollback
  - state.vscdb.backup

That's Linux. On a Mac the user folder is ~/Library/Application Support/Code/User and on Windows it's %APPDATA%\Code\User, but I only ran it on Linux. Cursor and Windsurf (which now ships as Devin) are built on VS Code and keep the same list in their own user folders. I read their code rather than running them, so don't quote me, but the only difference I spotted is that Cursor's bash check doesn't know ignorespace on its own. There, only ignoreboth and zsh get caught.

I tried bash with ignoreboth and zsh with HIST_IGNORE_SPACE on VS Code 1.144.0 on 1 November. Both times the shell's history file was clean and state.vscdb wasn't. A line I'd taken out with history -d was still in VS Code's list too, since that only edits bash's.

To see your own list:

sqlite3 ~/.config/Code/User/globalStorage/state.vscdb \
  "select value from ItemTable where key = 'terminal.history.entries.commands'" | jq -r '.entries[].key'

The second copy is the scrollback. VS Code saves each local terminal's contents so it can bring them back after a restart, which is the command plus whatever it printed. It saves the environment that terminal started with as well, so if VS Code itself was started from a shell where you'd exported a token, the token's in that file too, space or no space.

Over SSH, it comes home

Nothing in the command list says which machine a command ran on, so with Remote-SSH, what you type on the server is saved on your laptop, hidden ones included. I searched the whole home folder on the server afterwards, VS Code's own ~/.vscode-server included, and the token wasn't anywhere.

So the copy ends up on your laptop, the one that gets backed up. It shouldn't go any further with Settings Sync, at least: the code saves the list as machine-only, which Sync skips.

Deleting it

Every entry in Run Recent Command has an X, and there's a Terminal: Clear Previous Session History command. Both take it off the list, and neither takes it off the disk. SQLite marks the space as free and leaves the bytes alone, so grep -a still found the token in state.vscdb and its .backup afterwards. Clear doesn't touch the scrollback copy at all.

With VS Code closed, sqlite3 state.vscdb VACUUM rewrites the file, and the leftovers went with it. If it was a real token though, rotate it. That's quicker than chasing every backup it's been copied into since.

Keeping it out

Two settings, the first for the command list and the second for the scrollback:

"terminal.integrated.shellIntegration.history":
  0,
"terminal.integrated.enablePersistentSessions":
  false

The second one means your terminals don't come back after a restart. With both on a fresh profile, the token wasn't anywhere in VS Code's folder. Setting the first empties the list you've already got, but turning the second off leaves any scrollback that's already saved.

Better still, keep secrets off the command line. read -rs GITHUB_TOKEN asks for it without echoing, so VS Code's list gets read -rs GITHUB_TOKEN and never the token.

VS Code does know the trick, for what it's worth. The same shell integration script sets HISTCONTROL=ignorespace for a special case, under the comment # Prevent AI-executed commands from polluting shell history.