Lighthouse: findingsLighthouse watches the internet for what AI systems do there and what their activity leaves behind, and publishes what it finds, with the evidence and its limits.https://lighthouse.harbour.cat/feeds/findings.xml2026-11-09T00:00:00ZLighthouseWho watches the internet?https://lighthouse.harbour.cat/articles/short/who-watches-the-internet/2026-11-07T00:00:00Z2026-11-07T00:00:00ZWe read the public pages of 48 instruments that watch the internet itself and publish at least some data free, in November 2026. Every one of ten layers had at least one, by what we found, but none saw the whole of its layer, and 11 of the 48 build on another.Every layer of the internet had a public watcher in November 2026, by what we found, but none saw the whole of its layerhttps://lighthouse.harbour.cat/articles/who-watches-the-internet/2026-11-07T00:00:00Z2026-11-09T00:00:00ZWho watches the internet itself, and from where? We read the public pages of 48 instruments that publish at least some of their data free, from cable maps to vulnerability catalogues, in November 2026. By what we found, every one of ten layers had at least one. But none saw the whole of its layer: by a 2024 preprint's count, the two main routing archives listen from inside about 1.3 per cent of networks; traffic is seen one network, link or sensor fleet at a time, or in aggregate; and the evidence behind the exploit-prediction score we read is private. Eleven of the 48 build on another of them. A map made from documentation, not a census, and it measures nothing of the internet itself.A week after two fixes, every fixed line and branch had passed half in the two counts we followed daily, and more than half of the PHP services showing a version ran branches PHP no longer fixeshttps://lighthouse.harbour.cat/articles/a-week-after-two-fixes/2026-10-30T00:00:00Z2026-10-30T00:00:00ZA week after PHP's emergency fix and Node.js's security release of 21 October 2026, every fixed Node.js line and PHP branch had passed half in the two counts we followed each day. The counts measure different things: downloads from Node.js's own server, and PHP services a company scans from outside, which undercount patched ones. Beside them sat a tail the fixes do not touch: on 28 October, 24.4 million PHP services, more than half of those showing a version, ran branches PHP no longer fixes, as their versions report them; some may be patched by Linux distributions under the old number, which we have not measured. A first reading, to be revised a month after release.A week after two fixeshttps://lighthouse.harbour.cat/articles/short/a-week-after-two-fixes/2026-10-30T00:00:00Z2026-10-30T00:00:00ZA week after the PHP and Node.js fixes of 21 October 2026, every fixed Node.js line and PHP branch had passed half in the two counts we followed each day, while more than half of the PHP services showing a version ran branches PHP no longer fixes.A PHP emergency, from an early attack trace to published fixeshttps://lighthouse.harbour.cat/articles/php-emergency-first-reading/2026-10-22T00:00:00Z2026-10-30T00:00:00ZA first-party honeypot account dates a PHP exploit attempt to 17 October, before public disclosure on 21 October. AI helped find a flaw; people and organisations coordinated the response. By 22 October, public attack reports did not identify AI in the requests. The fix has reached selected published images, but their users and running sites remain outside this watch. On 23 October PHP described a further, separately numbered flaw, a route to running code that it calls unlikely, open by its account only in some unusually configured applications, which it is handling in its regular release cycle. On 26 October CISA, the US cybersecurity agency, listed both emergency flaws in its catalogue of known exploited vulnerabilities, a classification whose published criteria, as a web reader summarised them, count attempts as well as successes, not a count of attacks or proof that any succeeded. In pages updated on 29 October, Palo Alto Networks reported attacks exploiting the flaws in its firewalls' management software, and said it had confirmed the results reported by a security firm, which counts 25 servers taken over by 24 October and reports AI tools on the attacker's machines, without direct evidence that they wrote the exploit, though it says the scripts' style suggests AI-assisted development. The firewalls run their own copy of PHP, by the firm's account on a branch PHP's 21 October releases do not fix. Their evidence is not public and we have not checked it. Next revision: As reviewed fixed-source evidence changes.The PHP patch was public on Wednesday; one reported attack trace is olderhttps://lighthouse.harbour.cat/articles/short/php-emergency-first-reading/2026-10-22T00:00:00Z2026-10-30T00:00:00ZAmazon reports a pre-disclosure PHP exploit attempt against a honeypot. The early response has left visible traces in protection rules and published images, but not a count of affected or fixed sites.When a Python project pins a library, its test and build workflows almost always install what the pin nameshttps://lighthouse.harbour.cat/articles/short/tests-read-the-lockfile/2026-09-30T00:00:00Z2026-09-30T00:00:00ZIf a Python project keeps a pin or a lockfile, do its automated tests install from it? At 469 moments from April 2025 to August 2026 when one of 332 projects held an older version of a widely used library in a pin or lockfile, 395 kept test and build workflows, and where our rules could decide, some job installed the library from the pinned file at 282 of 291 of those moments. Where a lockfile held the version, a job read it at 164 of 188, though at 83 only through commands that can rewrite it. A workflow is not a run.When a Python project pins a library, its test and build workflows almost always install what the pin nameshttps://lighthouse.harbour.cat/articles/tests-read-the-lockfile/2026-09-30T00:00:00Z2026-09-30T00:00:00ZA pin or a lockfile holds software still only in the builds that read it, and a project's container recipe often does not. We read the automated test and build workflows that 332 Python projects kept at 469 moments, from April 2025 to August 2026, when each held an older version of a widely used library in a pin or lockfile. 395 kept such workflows, and where our rules could decide, some job installed the library from the pinned file at 282 of 291 of those moments; where a lockfile held the version, a job read the lockfile itself at 164 of 188, against 71 of 113 for the container recipes counted the same way, a comparison made after the counts, though for 83 of the 164 only through commands that can rewrite the lockfile. A workflow is not a run, and nothing here counts downloads.When a Python project pins a library, the container recipe it keeps mostly installs what the pin nameshttps://lighthouse.harbour.cat/articles/recipes-follow-the-pin/2026-09-29T00:00:00Z2026-09-29T00:00:00ZA pin or a lockfile holds software still, but only in the builds that read it. We read the container recipes that 332 Python projects kept at 469 moments, from April 2025 to August 2026, when each held an older version of a widely used library in a pin or lockfile as a new release came out. About half kept one. Where our rules could decide, the recipe installed from the pinned file for 129 of the 167 projects at those moments and did not for 38, a few of them leaving a lockfile in the build unread. More than a quarter could not be decided, and a recipe is not an image anyone built or ran.When a Python project pins a library, the container recipe it keeps mostly installs what the pin nameshttps://lighthouse.harbour.cat/articles/short/recipes-follow-the-pin/2026-09-29T00:00:00Z2026-09-29T00:00:00ZIf a Python project keeps a pin or a lockfile, does the recipe that builds its software read it? At 469 moments from April 2025 to August 2026 when one of 332 projects held an older version of a widely used library in a pin or lockfile, about half kept a container recipe, and where our rules could decide, the recipe installed from the pinned file for 129 of the 167 projects at those moments, but for 21 of 37 where only a lockfile held the version. More than a quarter could not be decided, and a recipe is not an image anyone built or ran.Further down Python's download rankings, fewer libraries' new versions take half the downloads in two dayshttps://lighthouse.harbour.cat/articles/rarer-further-down/2026-09-29T00:00:00Z2026-09-29T00:00:00ZOf the fifty most downloaded Python libraries, 37 put out new versions between April and August 2026, and for 26 of them most of those versions were half of the library's downloads within two days. We drew 160 libraries at random from further down the rankings and measured them the same way: it was so for about half of the libraries that released among those ranked 51 to 500, and about a quarter among those ranked 501 to 5,000. Further down, a typical new version held a smaller share from its first full day, which on a reading made after the counts was about the share the version it replaced had held. Mirrors copying each release made few of those downloads, and the log does not say what makes the difference.Further down Python's download rankings, fewer libraries' new versions take half the downloads in two dayshttps://lighthouse.harbour.cat/articles/short/rarer-further-down/2026-09-29T00:00:00Z2026-09-29T00:00:00ZOf the fifty most downloaded Python libraries, 37 put out new versions between April and August 2026, and for 26 of them most of those versions were half of the library's downloads within two days. Further down the rankings it was so for fewer libraries: about half of the 52 that released, of 80 drawn at random from ranks 51 to 500, and about a quarter of the 35 that released, of 80 drawn from ranks 501 to 5,000, for new versions released April to August 2026. A download counts fetches, not people or machines.Most downloads of old versions come from Pythons a newer version supportshttps://lighthouse.harbour.cat/articles/old-versions-new-pythons/2026-09-29T00:00:00Z2026-11-03T00:00:00ZIn one week of September 2026, the typical one of 37 heavily used Python libraries had 37 per cent of its downloads on versions older than its newest of a month before. We fixed three explanations before reading and tested the two the log can count. In 32 of the libraries, fewer than half of those older downloads came from Pythons too old for a newer version. In three, boto3, aiobotocore and numpy, most did, but in boto3 and aiobotocore few were of the last version such a Python can take, and their counts, read again after publication, look like versions an installer tried and discarded rather than installed. Other libraries' declared limits could account for most of them in four, if each download of a library that sets a limit brings one of the library it limits, which the log cannot check. For the rest the log cannot say. And two days after its release, a new version's share is within ten points of its share a month on: tested on 355 releases we had not read, that held for 28 of 32 libraries, though within those ten points the share went on rising in almost every release.Most downloads of old versions come from Pythons a newer version supportshttps://lighthouse.harbour.cat/articles/short/old-versions-new-pythons/2026-09-29T00:00:00Z2026-11-03T00:00:00ZWhy do old versions of a library keep getting downloaded after a new one is out? In one week of September 2026, for 32 of 37 heavily used Python libraries, fewer than half of those downloads came from Pythons too old for a newer version. For boto3, the most downloaded, most did, yet their counts look like versions an installer tried and threw away rather than installed.New releases arrive quickly. Older versions keep getting downloaded.https://lighthouse.harbour.cat/articles/short/two-days-for-most/2026-09-28T00:00:00Z2026-09-29T00:00:00ZA new version of a widely used Python library takes most of its share of the downloads on its first full day and gains only a few points more over the month, while older versions go on being downloaded: a pattern we saw in almost all of 37 big libraries, and only after the counts were in. For most of them that share passed half; for eleven, among them boto3, numpy and pandas, it did not. A download counts fetches, not people or machines.New releases arrive quickly. Older versions keep getting downloaded.https://lighthouse.harbour.cat/articles/two-days-for-most/2026-09-28T00:00:00Z2026-09-29T00:00:00ZWhen one of the most downloaded Python libraries puts out a new version, its share of the downloads jumps on the first full day and then creeps up by a few points over the month, while older versions go on being downloaded beside it: a pattern we saw in almost all of the 37 libraries we read, and noticed only after the counts were in. For most of them, that first jump took the new version past half; for eleven, among them boto3, numpy and pandas, it did not. What 424 releases show about how an update spreads, and what a download count cannot say.Where does a software update go once it is released?https://lighthouse.harbour.cat/articles/short/where-software-updates-go/2026-09-27T00:00:00Z2026-11-03T00:00:00ZWhen a library releases a new version, how fast does the software built on it take it up? Open version ranges took one release within days; pinned software took security fixes over weeks, and whether a fix that says it mends a security flaw is taken up sooner is still unsettled.Where does a software update go once it is released?https://lighthouse.harbour.cat/articles/where-software-updates-go/2026-09-27T00:00:00Z2026-11-03T00:00:00ZA new version of a widely used library reached half its downloads within two days, while software that pins its versions took weeks to move, and whether a fix that says it mends a security flaw is taken up sooner is still unsettled. What seven readings of public records show about where a software update goes, where each record stops, and what that means for a watch on AI.Does pinned software move sooner to a security fix that says so? Added up, it leans that way; library by library, we cannot tellhttps://lighthouse.harbour.cat/articles/short/the-lead-was-a-few-libraries/2026-09-27T00:00:00Z2026-09-27T00:00:00ZDoes software that pins a library move sooner to a security fix whose notes say what it is? Across thirty libraries it leans that way when every project is added up, but not when each library counts once, so the question is not settled.Does pinned software move sooner to a security fix that says so? Added up, it leans that way; library by library, we cannot tellhttps://lighthouse.harbour.cat/articles/the-lead-was-a-few-libraries/2026-09-27T00:00:00Z2026-09-27T00:00:00ZDoes software that pins a library move sooner to a security fix whose own notes say what it is? Added up across thirty libraries it leans that way, but counted one library at a time we could not tell, and the answer moves most with which public notice counts as the warning.Pinned software moved faster to security fixes that said so in their notes, mostly by people in the days after the release, but no larger share moved before the advisoryhttps://lighthouse.harbour.cat/articles/fixes-that-said-so/2026-09-27T00:00:00Z2026-09-27T00:00:00ZMany security fixes say so in their own notes before any advisory is published. Across fourteen libraries, pinned software moved to those fixes before the advisory at about 1.7 times the pace of silent ones, but two libraries carried much of it, and a later count of thirty could not settle it.Pinned software moved faster to security fixes that said so in their notes, mostly by people in the days after the release, but no larger share moved before the advisoryhttps://lighthouse.harbour.cat/articles/short/fixes-that-said-so/2026-09-27T00:00:00Z2026-09-27T00:00:00ZNineteen of 37 security fixes said so in their own notes, eleven naming advisories not yet published. Pinned software moved to them faster across fourteen libraries, but that could not be told apart from the libraries themselves.Pinned software moved to security fixes over weeks, a little faster after the release and again after the advisory, and neither drew most of the moveshttps://lighthouse.harbour.cat/articles/pins-move-over-weeks/2026-09-27T00:00:00Z2026-09-27T00:00:00ZAcross 102 pins on four widely used Python libraries, software moved to security fixes over weeks, a little faster just after each release and each advisory, and neither moment drew most of the moves. The burst after one library's advisory did not recur.Pinned software moved to security fixes over weeks, a little faster after the release and again after the advisory, and neither drew most of the moveshttps://lighthouse.harbour.cat/articles/short/pins-move-over-weeks/2026-09-27T00:00:00Z2026-09-27T00:00:00ZPinned software took security fixes over weeks, the typical move about nineteen days after the release, a little faster after the release and the advisory but with no burst. Every high or critical advisory we checked came after its fix was already out.Software built from open ranges took a new release within days; pinned software waited a month, and moved most often when a security advisory camehttps://lighthouse.harbour.cat/articles/short/what-moves-a-pin/2026-09-26T00:00:00Z2026-09-27T00:00:00ZImages built from open ranges took a new release within days; pinned ones waited for the pin, and in one library six of the thirteen projects whose first move we found made it within 28 hours of security advisories published a month later. A later reading of four libraries found no such burst.Software built from open ranges took a new release within days; pinned software waited a month, and moved most often when a security advisory camehttps://lighthouse.harbour.cat/articles/what-moves-a-pin/2026-09-26T00:00:00Z2026-09-27T00:00:00ZIn a sample of published images, software built from open ranges took a new release within days, while pinned software waited, and in this one library the largest group of pins moved within about a day of security advisories published a month later. Across four other libraries that burst did not recur.Published images show what software installed, and it was not always what its project had chosenhttps://lighthouse.harbour.cat/articles/short/what-an-image-holds/2026-09-26T00:00:00Z2026-09-26T00:00:00ZOne project's published images held a new release sixteen days before its lockfile did, because the image was built from a range. Few projects publish images, and an image is an installation, not a run.Published images show what software installed, and it was not always what its project had chosenhttps://lighthouse.harbour.cat/articles/what-an-image-holds/2026-09-26T00:00:00Z2026-09-26T00:00:00ZPublished container images record what an installer actually put in place, and one project's images held a new release sixteen days before its own lockfile named it. What a project asks for and what its software installs can differ, and how the software is built decides which.Downloads show a new release taken up within two days, but not where it was installed or whether anyone ran ithttps://lighthouse.harbour.cat/articles/short/what-a-download-shows/2026-09-26T00:00:00Z2026-09-28T00:00:00ZA new release reached half of a widely used library's downloads within two days, carried, we think, by installers taking the newest version that fits. The log that shows it cannot say what was installed or run.Downloads show a new release taken up within two days, but not where it was installed or whether anyone ran ithttps://lighthouse.harbour.cat/articles/what-a-download-shows/2026-09-26T00:00:00Z2026-09-28T00:00:00ZThe day after a new version of mcp, a Python library AI agents use, was released, it was already about half of all the library's downloads, and had been for five days before the first project we watched pinned it. The public download log shows how fast a release arrives, and stops at the download: never the installation, never a run.Public records show where a software update went, but not why, or whether anyone ran ithttps://lighthouse.harbour.cat/articles/where-a-software-update-went/2026-09-26T00:00:00Z2026-09-26T00:00:00ZWe followed one new release of a Python library into nine projects that depend on it: four took it up within four weeks, and one passed it a step further, but the public record could not say why any of them moved or whether anyone ran it.The xz backdoor sat in public for nearly five weeks until a slow login gave it awayhttps://lighthouse.harbour.cat/articles/short/the-xz-backdoor/2026-09-26T00:00:00Z2026-09-26T00:00:00ZA backdoor in the xz compression package was public for nearly five weeks and was found because one engineer noticed a slow login. No public source we surveyed watches the distribution pipelines it travelled through.We can see pieces of the internet's AI activity, but not how they fit togetherhttps://lighthouse.harbour.cat/articles/short/what-we-can-see/2026-09-26T00:00:00Z2026-09-26T00:00:00ZOne AI agent's small job can show up in four public counts with nothing to say they belong together. Every public view of AI activity is partial, and nobody has measured how the views overlap.The xz backdoor sat in public for nearly five weeks until a slow login gave it awayhttps://lighthouse.harbour.cat/articles/the-xz-backdoor/2026-09-26T00:00:00Z2026-09-26T00:00:00ZIn 2024 a backdoor sat in public releases of a compression library for about five weeks before one engineer followed a half-second delay in his logins to it. The evidence was there from the first day; the signs anyone noticed came from running code.We can see pieces of the internet's AI activity, but not how they fit togetherhttps://lighthouse.harbour.cat/articles/what-we-can-see/2026-09-26T00:00:00Z2026-11-09T00:00:00ZCould anyone count how much AI activity happens on the internet? Seventeen public sources each see one piece of it, and none says how its piece overlaps the others, so their counts cannot be added up.