Where does a software update go?

How the inquiry developed

We started by following one release of mcp, a Python library AI agents use, into nine projects built on it (where a software update went); the histories showed where it went but not why, or whether anyone ran it. The download log extended the trail past the projects and showed the new version at half of all downloads within two days, stopping at the download (what a download shows). Published images extended it again, to the installation, and showed a project's software holding a version its own lockfile did not name (what an image holds). A sample of images around a later release confirmed two paces, ranges within days and pins waiting, and branched into what moves a pin, where a security advisory seemed to (what moves a pin). Four libraries revised that: pins moved over weeks, after both release and advisory, with no burst (pins move over weeks). Fixes' own notes then narrowed the question to whether a fix that says so draws pins sooner, which fourteen libraries suggested (fixes that said so). Thirty libraries revised that to unsettled: pooled it leans that way, library by library we could not tell (the lead was a few libraries). Back on the fast half of the road, 37 of the most downloaded Python libraries tested the two-day pace: for 26 a new release was half of the downloads within two days, and for eleven no release was, but in almost all a new version took most of its share on its first full day and older versions kept the rest (the reading of the pace). One week of September 2026 then tested what keeps those older versions downloaded: downloads from Pythons too old for a newer version were most of it in three of the 37 libraries and fewer than half in 32, though an old Python does not say which older version is fetched, and for boto3 and aiobotocore most of those downloads look, on a reading made after the counts, like versions an installer tried and discarded; other libraries' version limits could account for most of it in four, if each download of a library that sets a limit brings one of the library it limits, which the log cannot check; and for the rest the log could not say. That a new version's share two days after release is within ten points of its share a month on held as a tested result on releases we had not read, though within that band it went on rising in almost every release (the reading of what stays behind). While the next reading waited for its weeks, 160 libraries drawn at random from further down the rankings bounded the two-day pace: most new versions reached half of the downloads within two days for 25 of the 52 that released, of 80 drawn from those ranked 51 to 500, and 9 of the 35 that released, of 80 drawn from those ranked 501 to 5,000, against 26 of 37 at the top, and further down a typical new version held a smaller share from its first full day (the reading below the top fifty). Back on the slow road, the container recipes that 332 projects kept at 469 moments when they held an older version of a library in a pin or lockfile then tested whether a project's own build reads the pin we had timed: about half kept a recipe, and where our rules could decide, the recipe installed from the pinned file for 129 of the 167 projects at those moments, while more than a quarter could not be decided and a lockfile alone was followed less often than an exact pin (the reading of the recipes). The same moments' test and build workflows then extended that to the builds a project runs at every change: where our rules could decide, some job installed the library from the pinned file at 282 of 291 moments, and where a lockfile held the version a job read it at 164 of 188, against 71 of 113 recipes counted the same way, a comparison made after the counts, though at 83 of those only through commands that can rewrite the lockfile (the latest reading). Where does a software update go once it is released? draws the whole together, and is the place to start.

The reading order above puts that account first and then the pieces in the order they were written, so that a reader who starts with the whole is led on through the steps that built it, and the last piece is the latest reading.

Where it changed direction

• From projects to downloads: the histories stopped at what projects asked for, so we looked for a record on the far side of the release.
• From downloads to images: the log could not say what was installed, so we read the installations some projects publish.
• From installation to what moves a pin: images showed that pinned software waits, so the question became what ends the wait.
• From advisories to the fix's own notes: fixes came out before their advisories, so a move "before the advisory" was not a move before anyone knew.
• From fourteen libraries to thirty: two libraries carried the lead, so each library had to count once.
• From the notes back to downloads: five months of advisories held too few libraries, so the next reading returned to how fast releases reach downloads.
• From the pace to what stays behind: in almost every library a new version took most of its share on the first day and older versions kept the rest, so the question became what keeps older versions downloaded.
• From the top fifty to the rest of the rankings: the pace had been measured only for the libraries almost everything depends on, so while the next reading waited for its weeks, it was measured on libraries drawn from further down.
• From the downloads back to the pins: while the weekly reading waited, and because a lockfile holds only the builds that read it, we asked whether the pins we had timed decide what a project's own container recipe would install.
• From recipes to tests: a container recipe read its lockfile only half the time, and test runs are the installs a build server repeats, so we asked whether the same projects' workflows read the pin.
• From what stays behind to whether it holds: old Pythons and other libraries' limits could account for the older downloads of few libraries, and downloads reporting one Python made nearly two thirds of boto3's in the week read, so the question became whether what stays behind is steady from week to week.

Where the evidence stands

Attention says where we are looking; this says how firm the findings are. That a new release reaches half of a library's downloads within two days held for most of the most downloaded Python libraries, 26 of the 37 that released between April and August 2026 (70 per cent, and anywhere from 54 to 84 per cent when the libraries are resampled), and for eleven no release did. On 8 November 2026 a fresh agent on a different model, which hadn't read the record, its tables, its scripts or its pieces, rebuilt that result from the retained data and the brief alone, and every figure came out the same (the note). Below the top fifty it was not the rule: of 80 libraries drawn at random from those ranked 51 to 500, 52 released and 25 of them had most new versions reach half within two days (48 per cent, anywhere from 35 to 62 when resampled), and of 80 drawn from those ranked 501 to 5,000, 35 released and 9 of them did (26 per cent, 11 to 40), on new versions of the same months. A typical new version's share on its first full day was smaller further down, and on a reading made after the counts, for new versions that replaced one at least two weeks old, it was about the share the version it replaced had held the day before, in every group, so what differs down the rankings seems to be how much of a library's downloads follow its newest version at all; mirror programs made few of those downloads, and why the share is smaller was not measured. That a new version's share is mostly set early was first seen after the counts were read, from the first full day; measured from the second day to the thirtieth, it then held as a tested result on 355 releases not read before, for 28 of 32 libraries, within a ten-point band inside which the share went on rising in 339 of the 355 releases, by about three points for the typical library, and which is lenient where shares are small: for boto3 and aiobotocore the typical new version's share still grew by about two thirds after the second day. Further down the rankings it held for 39 of the 50 libraries with a known result among those drawn from ranks 51 to 500, and 23 of 35 among those drawn from ranks 501 to 5,000. In one week of September 2026, a median 37 per cent of each library's downloads were of versions older than its newest of a month before. Downloads from Pythons that no newer version supports were most of those in three libraries and fewer than half in 32, so old Pythons could not be the main reason there; where they were most, the old Python rules out the new version for those downloads without saying which older one is fetched, and for boto3 and aiobotocore few were where a fresh install would land: read again after publication, their counts by version are nearly the same for long runs of versions in a row, the mark of an installer trying one version after another and fetching each, so most of them may never have been installed. Other libraries' declared limits could account for most in four, as an estimate that assumes each download of a library that sets a limit brings one of the library it limits, which the log does not record and its own numbers strain for two of the four; they could not be settled in 26. Environments rebuilt from old lists, which fit what remains, cannot be counted in the download log, and downloads that share the details they report are not thereby one machine or one population. A download counts fetches, so a low share is not by itself a slow spread. In those releases' first three days, downloads flagged as builds were a smaller share of the new version's than of the replaced version's, in every library's typical release; the flag is a floor on builds. That software built from open ranges took a release within days while pinned software waited showed in the published images of one library's dependents, and that pins move to security fixes over weeks held across four libraries. Whether a project's own container recipe reads the pin it keeps was read at 469 moments when a project held an older version in a pin or lockfile: about half kept a recipe, and where our rules could decide, the recipe installed from the pinned file for 129 of the 167 projects at those moments (77 per cent, 70 counting each project once, and between 55 and 84 per cent however the undecided ones fall), but for 21 of 37 where a lockfile alone held the version; a lockfile left in the build unread while the versions were worked out afresh, as one program's images had shown, was 7 of the 90 decided cases where a lockfile held the version; and a recipe is not an image anyone built or ran. The same projects' automated test and build workflows read the pin somewhat more often and the lockfile itself much more often: 395 of the 469 kept such workflows, and where our rules could decide, some job installed the library from the pinned file at 282 of 291 moments (97 per cent, against 85 per cent for the recipes counted the same way, one build being enough, a comparison made after the counts), and where a lockfile held the version, a job read the lockfile itself at 164 of 188 (87 per cent, against 63 per cent for the recipes), though at 83 of those only through commands that can rewrite the lockfile if the project's own requirements change, and among those holding the version only in a lockfile almost a quarter could not be decided; a workflow is not a run, and nothing here says how many downloads the tests make. Whether a fix whose own notes say so draws pins sooner is not settled. No reading checked whether any project was exposed, and none can see software run.

Beside it

• How far a compromised bee-js release travelled on npm, from 10 November 2026: a release of a small JavaScript library, published on 9 November through the project's own trusted-publishing workflow with genuine provenance and, as StepSecurity and Socket report, a malicious install hook, removed after about 75 minutes. Daily reads of npm's seven-day per-version counts to 17 November, then one more on 24 November, count its fetches on its day and after, beside the same days' ordinary traffic; the counterpart, on a second registry, of the LiteLLM study (LH040). A download is a fetch, not an install or a victim. Brief fixed before any count was read.

• A PHP emergency, from an early attack trace to published fixes, dated 22 October 2026, puts this event's public source clocks beside the selected image snapshots. Amazon reports a 17 October honeypot attempt retrospectively; OpenAI documents AI-assisted defensive discovery; the fixed panels show network-provider claims, agency advice and published fixed-version images. Neither attack success nor deployment uptake is measured. The short form and two diagrams give the same boundaries. Further source reads are intended every six hours through 24 October, alongside daily image and response panels; missed slots and later changes will be dated. A later-evidence notice of 23 October adds PHP's own notice of a further, separately numbered flaw: by PHP's account an unlikely route to running code that arises only where an application configured to store session data in one of two named formats switches to a third at runtime, with upload progress on, for which PHP suggests switching that feature off until its next regular release; PHP names no version, but its advice implies the 21 October releases do not close it, as Cloudflare's revised page says outright. A second notice, of 27 October, records that CISA's catalogue of known exploited vulnerabilities listed both emergency flaws on 26 October, an agency's classification by criteria the catalogue does not state, published without its evidence or a count and linking no exploitation report we could read, so it does not show that any attempt succeeded (the catalogue reads). A later-evidence notice of 30 October adds Palo Alto Networks' report, updated 29 October, of attacks exploiting the flaws in its firewalls' management software, and its confirmation of the results reported by Dream Research, which counts 25 servers taken over, three in what it calls a US government-affiliated environment, through firewalls that carry their own copy of PHP, by Dream's account on a branch PHP's 21 October releases do not fix. These are the companies' claims, read at their sources and not checked by us, beside a researcher's 35 shell starts on decoys and CISA's criteria, which, as a web reader summarised them, count attempts as well as successes (leads).

• A week after two fixes, 30 October 2026: how far PHP's emergency fix had spread a week on, by Censys's count of internet-facing services, beside Node.js's security release of the same day on nodejs.org's download counts and the Python releases of this investigation, with the tail on branches no fix reaches. Different units drawn apart; Censys's patched shares are floors; to be revised after the day-30 reads (PHP study, Node.js study).

• PHP's own notice of a related issue, 23 October 2026: one retained read of PHP's news page at 17:00 UTC, under a protocol committed beforehand that disclosed what a web reader had already shown. The notice's conditions, advice and promised advisory are PHP's claims; how many applications meet the conditions is not measured, and the page's 10:12 UTC stamp on the entry is not proof of when the text became public.

• The first snapshot of the emergency PHP fix, 21 October 2026: a bounded reading of three distribution package paths and four official PHP image tags. This is another ecosystem and a selected emergency, not a replication of the Python pace. Vendor fix records and image declarations were visible by the first reading; none reaches a running deployment. The protocol and evidence sit with the study, and a later reading needs a separate window.

• The first moving-tag baseline, 21 October 2026: four official PHP moving tags already named the same linux/amd64 digests as their fixed-version counterparts at first observation. Their earlier pointer states are unknown. Later checkpoints can bound a change between readings, but cannot measure deployments.

• The PHP official-image publisher chain, 21 October 2026: a selected public issue, two linked PRs and a successful official-images CI rerun precede the registry observations. The records separate communication, review, CI and image publication; intermediate production builds and consumer use remain unmeasured.

• A first consumer CI feasibility slice, 21 October 2026: selected public image projects show base-image instructions and runs at sampled commits, but neither resolved base digests nor deployments. The small deterministic file cap misses Nextcloud's main recipes; it cannot produce an uptake rate.

• GH Archive, which keeps hourly files of GitHub's public events and which we read for one hour of April 2026, held every event type in that hour. Later in 2026 its files changed: in a sample of four hours a day, pushes, new branches and deleted branches or tags were absent from 90 of 272 hours from 1 September to 7 November, 64 of 96 from 15 October, and in the hours read at 12:00 UTC from January to August, its other event types thinned until pushes were 98 in every 100 events in the two August hours (the record, version 0.3, reviewed). These are counts of what the files held, not of GitHub's activity, and if GitHub had the events, whether its public events feed or GH Archive's collection lost them is unknown. The April hour is unchanged; any further reading of the archive here should first count what each hour holds. On 9 November 2026 "Later evidence" notices saying so were added to the map of who watches the internet and the survey of what we can see.

• The xz backdoor sat in public for nearly five weeks until a slow login gave it away: a historical case of a compromise travelling the same kind of distribution roads, unseen by the public sources we surveyed.

• We can see pieces of the internet's AI activity, but not how they fit together: the survey of public sources whose edges this investigation keeps meeting.

What is next

The question of fixes that say so rests unsettled: five months of advisories against the 500 most downloaded Python projects did not hold enough libraries to press it further, and a longer window may one day. What keeps older versions downloaded has been read as far as the download log reaches (the reading of what stays behind): old Pythons are most of it for a few libraries without saying which older versions are fetched, other libraries' limits could account for a few more on an assumption the log cannot check, and for most a remainder fits environments rebuilt from old lists, which only a count of public lockfiles could test, once a reader for public code at that scale can be used; such a count should read the install commands beside the lockfiles, in container recipes and in the workflows that build and test a project, since where we could tell, a project's own container recipe read a lockfile that held the older version in half the cases (the reading of the recipes), while its test and build workflows read it in most, about half of those through commands that can rewrite it (the latest reading). Whether those workflows' runs make a visible share of the older downloads is not something repository files can say. Whether what stays behind is steady from one week to the next was then read on the two weeks that followed, 28 September to 11 October 2026, for the same 37 libraries, with tests fixed before reading (the record). Over those three adjacent weeks it held: the typical library's share on older versions was about 37 per cent in each week and within five points of the first week's for 32 of the 37, old Pythons were most of the older downloads in the same three libraries, and the four boto3 patterns noticed after the first week's counts held in both weeks (the notice on the reading of what stays behind). Holding is not explanation: that most of boto3's old-Python downloads are an installer's search stays a reading made after release, which the installer's own version, recorded in the package index's full log but not in the public copy we read, could help test, and no study yet reads it. A watch can call a change unusual only against a baseline that holds, and this is three weeks of one set of libraries, not months. Below the top fifty, where new versions took half of the downloads within two days for fewer libraries (the reading below the top fifty), a reading made after the counts points at how much of a library's downloads follow its newest version at all; the libraries drawn there could be read the same way. The programme weighs what comes next.