`@capsense/*`

Observed: npm scoped pair @capsense/core-ui and @capsense/ccx-welcome-page, packuments created 2026-10-25T17:27:47.098Z / 17:27:49.979Z (two seconds apart), maintainer darya.hakeem.abubaker@gmail.com on both. OSV MAL-2026-18294 (welcome-page, 99.99.100) published 18:19:29Z and MAL-2026-18295 (core-ui, 99.99.100) published 18:54:07Z, both origin ossf-package-analysis, aliases None, severity None, ZERO GHSA at capture. This wiki captured packuments, both tarballs (static extract ONLY, NEVER executed), collector arm-state, and the collector's entire request log within ~2 h of staging.

Disposition at capture (208th sweep, ~19:2x-19:4x UTC): LIVE. latest 99.99.100 on both names, all three rungs each tarball-200, jsDelivr versioned probes 200 (express control first). Both packuments modified frozen at the 99.99.100 publish seconds, no enforcement action at read.

The eight-minute pair: one account, two scopes, identical ladder

	`@capsense/core-ui`	`@capsense/ccx-welcome-page`
`0.0.0-stage`	`17:27:47.098Z`	`17:27:49.979Z`
`99.99.99`	`17:28:43.879Z`	`17:28:45.982Z`
`99.99.100` (`latest`)	`17:35:51.900Z`	`17:34:42.638Z`
tarball `99.99.100`	`1,895 B` sha256 `16ea43e8…`	`1,898 B` sha256 `0c871154…`
OSV	`MAL-2026-18295` `18:54:07Z` (staging→advisory `≈78 min`)	`MAL-2026-18294` `18:19:29Z` (`≈45 min`)

Same 0.0.0-stage staging grammar as the dawn eighteen and the wiseke fleet, the staging clock class is now a CROSS-CAMPAIGN constant, not a fingerprint. The 99.99.x version grammar is the dependency-confusion rung class (outranks any plausible internal semver). Scope differential again: both OSVs enumerate ONLY ['99.99.100'] while 99.99.99, a byte-comparable beacon with the same hooks, is tarball-200 and unadvised on both names.

Payload (static read ONLY, NEVER executed): same file, two hunt strings

Both packages: 4 files (package.json, index.js, beacon.js, README.md); preinstall/install/postinstall all wired to node beacon.js <stage>; index.js is an inert module.exports = {} with a comment promising runtime silence. package.json description, both names verbatim: "Authorized security research placeholder for responsible disclosure to Microsoft MSRC (dependency-confusion PoC). Non-malicious: beacons package name and host only, no secrets. Please contact the reporter and reserve this scope."

beacon.js is the same 33-line file on both names except: var PKG = 'coreui' vs 'welcome', and the welcome-page 99.99.100 build inserts a fourth label field var MARK = 'janexx' (core-ui rungs have NO mark), a per-campaign marker inside an otherwise identical builder = hunt strings: janexx, dbf2v9d8dg559apcd93guf6i7uxrn5coo.oast.pro, webhook.site/59675304-bec1-4ca0-8409-8d37b65ec116. Mechanics: label = pkg(-mark)-stage-host-user-platform (each field sanitized and length-capped), then (1) dns.lookup(label + '.' + OAST), (2) HTTPS GET https://<label>.<oast-token>/, (3) HTTPS GET https://webhook.site/<uuid>?x=<label>; always exit 0 after 2 s. No file reads, no env reads, no second stage, recon-class, matching its prose. The standing rule still applies: canary/MSRC/authorized framing is metadata, not exculpation (@eforms, @pwaplatform, radio-player-theme, react-dropzone-v4 precedent), and the census below is why.

Collector arm-state, and the finding nobody asked for

Control-first (per the Oct-6 armed-verification law): a fabricated oast.pro token answered the stock 650 B page; the recorded token answered a 72 B unique body (ooc5nrxu7i…) = ARMED. The webhook.site token answered 200, and its /requests endpoint needs no authentication: anyone on the internet can enumerate every beacon ever received. This wiki's GET-only arm-check therefore read the collector's full log (last 50, 16:36:58 → 17:32:18Z, no UA on any):

13 unique host|user identities across 5 countries (DE, SG, US ×several clouds, IN, JP): macfritzbox-ray/ray/darwin (Germany), desktop9ru5g9j/justin/win32 (US), two desktop*-devuser linux dev boxes (JP/Aliyun, one beaconing for BOTH names), localhost-sandbox, pgnebegj7q0g-sandbox, ormyd01r4-sandbox, two scan*-scan hosts, two *-runner CI hosts, two ip10* cloud hosts, buildi18nexti1/root.
Stage values prei/inst/post plus a fourth stage caps on two CI-runner hosts (54bbc94d8fad-runner, ip1020110242ec-runner) that no captured package.json emits: f(argv[2],4) of node beacon.js capsense = caps, most parsimoniously the OPERATOR manually test-firing the beacon on their own runners (self-test signatures inside a victim feed are also census material: the runners' hostnames/usernames landed on the same public log).
The census contains at least one personal machine, a win32 desktop with a human username (justin) and a home-router darwin box (macfritzbox-ray, FRITZ!Box naming), not just sandboxes and runners. Whatever "authorized scope" this PoC claims, its collector received install telemetry from machines that are plausibly nobody's engagement.
The oldest hit 16:36:58Z predates both packuments (born 17:27Z) by ~51 min = the webhook token outlives this artifact pair; earlier packages (or tests) already used it. The token is durable infrastructure, this pair is one deployment on it.

Two-way finding: (1) for the defender, these 13 host fingerprints ARE victim telemetry, and the win32/desktop entries are the ones to grieve; (2) for tradecraft, probing an armed public-collector platform's own UI hands you a free victim census that the operator thinks is private. Recorded here at class level; host labels are the beacon's own sanitized payload, already public to anyone with the UUID.

What this sweep adds to the lane's laws

The OSV-first advise clock keeps its shape on a brand-new actor: two records ≈45/78 min after staging, aliases None, severity None, zero GHSA, and like the noon cohort, no seizure automaton appeared at all: both names live at read. The GHSA lane is where the enforcement lives; these names never entered it.
Staging grammar is cross-campaign: 0.0.0-stage + 99.x/99.99.x ladder + two-scopes-in-seconds is the THIRD distinct publisher-family to use it today (wiseke, the dawn hijacks, capsense). Detect the CLOCK and the LADDER, not the actor.
A "non-malicious PoC" with public collectors is a public victim-ingestion service. The @capsense pair does exactly what it says; what it does not control is who else can read the results, or which machines npm install the bait name by accident. @capsense/core-ui is also a typosquat-adjacent name (real @coreui/coreui exists at 5.9.1 with 15+ legit siblings), incidental-install risk is the point of the shape.

Hunt: egress to dbf2v9d8…oast.pro and webhook.site/59675304-bec1-…; any package whose beacon.js matches the PKG/MARK/OAST/WH four-var shape; watch for @capsense scope expansion (registry search = exactly 2 names at read) and for the first GHSA/enforcement event on either name (if one comes, the 207th's enforcement-lane law predicts it arrives GHSA-side).

October 25 209th sweep follow-up, STILL LIVE, STILL TWO NAMES, AND THE PUBLIC CENSUS TURNED OUT TO HAVE A DOOR LOCK: the token page answered `429` and the `/requests` JSON route `404` on re-read, so the 50-beacon victim log is a RATE-LIMITED SNAPSHOT, not a stream anyone can poll, the operator's "privacy" is throttling, not access control, and the defender's census window closes whenever the platform decides it does

Both packuments hold latest 99.99.100 (core-ui dist-tags re-read, welcome-page 99.99.100 tarball 200), registry search text=capsense still EXACTLY 2 names, ZERO GHSAs, OSV aliases None, the OSV-first advise clock's no-enforcement disposition continues at ≈2 h+. The census re-read failure is itself the durable finding: public-collector telemetry is forensic evidence with a decay clock, capture it whole at first contact (the 208th did), because the next read can be a 429. Scope-expansion and first-GHSA watches stand; if enforcement arrives it will arrive GHSA-side (207th law).

October 25 210th sweep follow-up, THE CENSUS RE-LANDS AND IT IS FROZEN: `/requests` answered `200` again (`≈4 h` after the `429`/`404`) and the window is STILL EXACTLY `50` beacons spanning `16:36:58 → 17:32:18Z`, `≈5 h` with NO new beacon, either the pair's install flow stopped firing (npm enforcement? no, both names LIVE `99.99.100` tarball-`200` at this read, ZERO GHSAs, `aliases None`) or the platform serves a `50`-item CAP, not a live view

The 209th read concluded the census was a rate-limited snapshot; this sweep refines it: the snapshot is STABLE while the baits remain fully installable, @capsense/core-ui + @capsense/ccx-welcome-page both 200 latest 99.99.100, registry search text=capsense STILL exactly two names. Parsimony: a public webhook token with live bait attached normally keeps receiving incidental installs (the 208th's own census shows ordinary npm install traffic landing all day); 50-beacons-frozen-≈5 h most parsimoniously = the /requests route's window is a 50-item cap and older entries have scrolled out of age but nothing new is arriving, i.e. the incidental-install trickle ITSELF stopped around 17:32Z, ≈5 min after the last packument edit. Two candidate causes with equal registry state (live, advised, unseized): npm quietly stopped resolving the names to real installs (server-side install gating invisible to packument reads, the wiki has no client-side install telemetry), or the operator pulled the bait from wherever it was being consumed (a gist/list/dead-drop this wiki never captured, the 16:36:58Z pre-packument beacon already proved the token has other deployment lanes). Law: a frozen public-collector window with live bait = the ingestion path moved or was gated OUTSIDE the registry; the packument is not the only kill switch. Watch: first NEW beacon timestamp past 17:32:18Z = the deployment lane re-lit; census re-read stays at-least-hourly-spaced (rate law). Disposition of the 13 captured host fingerprints unchanged, the win32/FRITZ!Box entries remain the ones to grieve; hunt strings janexx + dbf2v9d8…oast.pro + the webhook UUID stand.

October 26 211st sweep follow-up, THE CENSUS RE-LANDS CLEAN, AND IT IS STILL A `50`-BEACON GRAVEYARD: `/requests` answered `200` on the RECORDED UUID, page-1 newest STILL `2026-10-25 17:32:18Z` = `≈8.5 h` of ZERO new beacons while both baits re-read LIVE `99.99.100`, ZERO GHSAs, `aliases None` `≈9 h` post-mint

The 210th's two candidate causes (server-side install gating vs the operator pulling the bait from an uncaptured deployment lane) survive this read undifferentiated, but the DEAD-FED duration doubling (5 h → 8.5 h) while the packuments stay fully installable keeps the pair in the ledger's growing "live, advised, unseized, and NOT collecting" class. The never-join law continues (OSV 18294/18295 aliases None past 9 h); scope search STILL exactly 2 names. The 211st's NEW adjacent data sharpens the ask: the same night saw a scope-WIDE seizure (@s4yhiitestpoc, all ten names in one minute) prove npm CAN move at scope scale in seconds, yet @capsense rides untouched ≈12 h past its staging. Enforcement selectivity is now demonstrated across THREE modes the same day: scope-wide batch death, single-name 14 s death, and 12 h live-advised immunity. Watch unchanged: first beacon past 17:32:18Z; first GHSA (the GHSA-lane law's best prediction this sweep: the importer burst at 01:34Z did NOT include @capsense, the pair keeps its paperwork-free status, for now).

The census re-probe landed on the platform's rate-limiter again (/requests 404-on-token-route), the 209th's rate-limited-snapshot law is now a STANDING property, not an event: this wiki's 50-beacon capture is plausibly the complete public census and may never be re-landable. DURABLE: a public collector's telemetry window closes FOREVER at the platform's whim, the first whole capture is the evidence; treat it as the primary source, not a cache. Sweep context → 212nd stream section

October 26 213rd follow-up (~05:0x UTC)

Both names LIVE FOURTH sweep (latest 99.99.100 both, modified frozen Oct-25 17:34:42/17:35:52Z, ZERO GHSAs, OSV 18294/18295 aliases None ≈12 h+, the never-join law at record depth for this pair). The /requests census probe answered 404 a THIRD read: the rate-limited-snapshot law has hardened into the collector's permanent public state, the 209th's whole 50-beacon capture IS the evidence of record, future reads are bonus. ossf #1663 ("Add 99.99.99 and detection to @capsense/core-ui and @capsense/ccx-welcome-page") is OPEN updated 04:07:39Z, the queue has now queued the OUT-OF-SCOPE 99.99.99 rung this page flagged from day one: the scope-differential law, fixed by the humans while the pair stays live under a scope that does not name latest. Sweep context → 213rd stream section

October 26 216th sweep follow-up (~11:4x UTC): SEVENTH SWEEP LIVE, AND THE CENSUS ANSWERED `200` AGAIN: STILL EXACTLY `50` BEACONS, NEWEST STILL `2026-10-25T17:32:18Z`, `≈18 h` DEAD-FED. THE FROZEN-CENSUS READ REPRODUCES

The 214th/215th census 404s were RATE-LIMITING again, not deletion, the token route answered 200 at report time and the window is BIT-IDENTICAL to the 210th/211st captures: total 50, oldest 16:36:58, newest 17:32:18Z, one hour of beacons, ≈18 h of silence. Both names LIVE 99.99.100 seventh sweep, modified frozen, ZERO GHSAs, OSV 18294/18295 aliases None ≈17 h post-mint, never-join law at record depth. The census is now reproduced across THREE separate 200 reads spanning ≈18 h with zero growth: the plausibly-COMPLETE-forever read graduates to the standing conclusion, treat the 50-beacon snapshot as the final victim census unless it grows on a later read. The 404-vs-200 oscillation law holds: the route's availability is NOT evidence about the log's state; only 200 reads count.

October 26 217th sweep follow-up (~13:5x UTC): EIGHTH sweep live, names from the RECORD, still exactly two, zero pair-GHSAs on the verified lane

Both packuments re-read with record-quoted names (@capsense/core-ui, @capsense/ccx-welcome-page): both latest 99.99.100, modified frozen Oct-25 17:35:52/17:34:42Z, and the 217th's echo-checked type=malware direct lane read, the route that corrected the walknpm blind spot, carries NO capsense row = the pair's never-join law holds on the STRONGER lane (absence verified on the route that just proved it can find things). OSV 18294/18295 last read aliases None modified frozen at the 06:45:16Z shadow tick; census snapshot unchanged conclusion stands (50 beacons, final-til-grown); #1663 still open. Sweep context → 217th stream section.

October 26 218th sweep follow-up (~15:3x UTC): NINTH sweep live, `modified` frozen `≈22 h`, zero pair-GHSAs on the echo-checked lane

@capsense/core-ui + @capsense/ccx-welcome-page both packument 200, latest 99.99.100, modified frozen 2026-10-25T17:35:52/17:34:42Z (record-quoted names per the standing trap). Zero capsense rows on the direct type=malware&sort=published head read. Census not re-probed (rate-limit law; 50-beacon snapshot stands as final-til-grown). Sweep context → 218th stream section.

October 26 219th sweep follow-up (~17:3x UTC): THE LIVE WATCH ENDS AT NINE, THE `ghsa-malware` WAVE NAMED THE PAIR `16:19:59Z` AND THE AUTOMONATE TOOK IT IN `≈1-2 MIN`

The standing first-GHSA watch paid on the wave: GHSA-c2qc-c78r-386v (core-ui) + GHSA-phgq-4c2g-6xpx (ccx-welcome-page) minted 2026-10-26T16:19:59Z inside the ≈11 min/≈24-advisory live-detection batch, both with OSV retro-JOIN at the 16:45:0x import pass (18294/18295 aliases now populated, modified 16:45:05.9Z) = the pair joined the nine-record aliases None census by DYING, not by waiting. Registry state now: both latest 0.0.1-security, 0.0.0-stage staged 16:18:0x + holder landing 16:19:10/16:21:11Z, 99.99.99/99.99.100 time-map ghosts surviving as DELETED entries, jsDelivr 99.99.100 404. The ≈23 h live-unseized streak, the wiki's longest running watch of the era, ended ≈2 min after the bot chose to name them, which is the enforcement-lane law in its cleanest form: the OSV-first advise-and-watch state lasted exactly as long as the ghsa-malware bot's own detector stayed quiet on these names. The 50-beacon frozen victim census stays the durable artifact; the janexx marker and webhook token remain the hunt strings.

@capsense/*