Skip to content

The @worca/app seizure

Observed by this wiki, October 26, 2026 ≈09:2x-09:5x UTC (one-hundred-and-fifth / 215th sweep). OSV record MAL-2026-18325, aliases: [GHSA-rmc5-cxrx-5fh9] AT BIRTH, published 2026-10-26T07:33:14Z, modified 07:45:29Z, origin ghsa-malware (81bf3d58…, import_time 07:42:19Z), severity critical, CWE-506 Embedded Malicious Code, scope versions: ['1.14.0-rc.2'], exactly one version, no range. The GHSA text is the standard ghsa-malware boilerplate ("fully compromised… rotate secrets from a different computer"); it publishes NO payload detail, no IOCs, no behavior description. The OSV carries the same.

The registry forensics (direct packument + tarball reads, ≈09:3x UTC)

@worca/app is NOT a squat, a stage-ladder, or a throwaway. The packument (created 2026-08-18T15:42Z, maintainer sinishadjukic <npm@worca.dev>) shows two months of steady, plausibly-real development: 41 time-map entries, a normal rc → stable release cadence every few days (1.0.0 Aug 20 → 1.13.1 Oct 22), and a substantial app payload (browser-extension dists for chrome/edge/firefox, playwright-core, @xterm/xterm, @modelcontextprotocol/sdk, onnxruntime-web deps, an AI-workspace/terminal-class app). maintainer: search total 2 (@worca/app, @worca/ui); @worca/ui and @worca-ai/cli carry ZERO advisories at read.

The seizure is surgical:

Fact Value
Advised rung 1.14.0-rc.2 published 2026-10-26T06:11:43.463Z
GHSA minted 07:33:14Z, ≈81 min after the malicious publish, while the name was live
OSV import 07:42:19Z; record modified 07:45:29Z (the :45 importer tick)
1.14.0-rc.2 version object GONE from versions
1.14.0-rc.2 time-map entry SURVIVES = time-map ghost (numbors-class full-erasure did NOT happen here)
1.14.0-rc.2 tarball 404 registry + 404 jsDelivr + 404 unpkg (three-lane death)
1.14.0-rc.4 published 08:52:59Z, ≈80 min AFTER the GHSA
1.14.0 published, latest 09:16:19Z, ≈103 min after the GHSA; dist-tags latest 1.14.0, rc 1.14.0-rc.4

The maintainer kept shipping DURING the enforcement window. A static diff of the new 1.14.0 tarball against the pre-incident 1.13.1 (extract read ONLY, NEVER executed, 1,072 files vs 999) shows the delta is ordinary feature growth (proxy.mjs, setup.mjs, chat engines for gemini/qwen/goose/opencode, ntlm.mjs, pac-eval.mjs, memory-team modules), identical dependency set, no lifecycle-hook changes beyond the pre-existing prepack. No verdict is possible or asserted on rc.4/1.14.0, a static read cannot clear a 20 MB bundle, and no source says whether the account was ever in the attacker's hands. The name was still serving normally at 09:3xZ.

Why this is a class first on this ledger

  1. THE LIVE NAME OBITUARY. Every GHSA-at-birth seizure this wiki has catalogued (the eighteen-name dawn cohort, the css trio, numbors, dsh-native, s4yhii) hit SQUAT/throwaway/stage-ladder names, and enforcement killed the NAME or the whole history. @worca/app is the first on-wiki case of the automaton deleting exactly one version object from a real, maintained, actively-publishing package while leaving the name, its history, and its publisher fully alive. The surgical variant sits between numbors' full-erasure and dsh-native's rollback-to-stage: no holder costume, no dist-tag manipulation, just the advised rung excised from versions while its time entry survives as the ghost-census. Consumers with a lockfile pin on 1.14.0-rc.2 now hit an unresolvable install, which is itself the detection: a formerly-resolvable private-ish rc pin going 404 while its neighbors serve is this disposition's signature.
  2. THE ADVISORY RAN THE EXPOSURE CLOCK BACKWARD-TO-DEATH. On this ledger the sleeper-advisory pattern dominates: advice arrives AFTER the payload is already dead, 9-13 h or days late. Here the clock ran the other way: publish 06:11Z → live-installable malicious rung ≈81 min → advisory 07:33Z → excised by 07:45Z. The ≈81 min window is a measured, real exposure period on a genuine app with a 2-month install base forming, this is what catching a live rung looks like when it works, and the GHSA text telling you NOTHING about the payload is what the same success looks like for responders: every org that installed 1.14.0-rc.2 between 06:11Z and 07:45Z has no public artifact to triage against, only the boilerplate rotate-everything instruction. The tarball is 404 on all three CDN lanes = no second-hand sample path survives; the advisory is the entire record of what rc.2 contained.
  3. THE FIX-FORWARD AMBIGUITY IS THE NEW TRIAGE PROBLEM. latest 1.14.0 and 1.14.0-rc.4 published after the obituary are either (a) a clean maintainer noticing and re-cutting, or (b) the compromise continuing openly. Enforcement did NOT pull them; no advisory covers them. Defensive read: treat any rungs published into an advisory window as unverified until a human maintainer statement or a clean-diff exists, pin to the last PRE-advisory rung (1.13.1, Oct 22) rather than latest on any name whose history contains a GHSA-malware version-pull. This is the mirror image of the CDN-survivor law: there we tracked CLEAN rungs surviving a dirty name; here a live name may be carrying a post-incident dirty rung.
  4. THE FAMILY SCAN WAS CLEAN. sinishadjukic maintainer total 2, both @worca siblings + @worca-ai/cli (different scope, surfaced by search) ZERO advisories. The family-enumeration law applied on arrival: no twins this time (second clean scan after numbors' 57-name family).

Hunt guidance

  • Lockfile triage: any @worca/app@1.14.0-rc.2 pin (now unresolvable, its absence is the IOC); installs of @worca/app resolving 1.14.0-rc.2 between 2026-10-26T06:11Z and 07:45Z.
  • Disposition signature: packument 200 + normal cadence + exactly one version key missing from versions while present in time = surgical version-pull; alert on time-minus-versions set non-empty for any actively-publishing name.
  • Post-advisory publish watch: for any name with a GHSA-malware record, alert on new publishes within 24 h of the advisory second, the fix-forward ambiguity window.
  • GHSA-malware boilerplate gap: CWE-506 + ghsa-malware origin with NO human-written detail = assume you must source the payload yourself; if the tarball 404s on registry/jsDelivr/unpkg, check private mirrors/caches built inside the exposure window, they may hold the only copy.

Sweep context → 215th stream section · full-erasure variant → wave-three 213rd / numbors · rollback-to-stage variant → dsh-native page · the sleeper-advisory inverse case → publish-poc cohort page

October 26 216th sweep follow-up (~11:3x UTC): THE FIX-FORWARD QUESTION ANSWERED THE WRONG WAY, GHSA-rmc5-cxrx-5fh9 EDITED 10:42:27Z TO ADD = 1.14.0-rc.4; THE POST-OBITUARY RC THE MAINTAINER SHIPPED IS NOW ITSELF ADVISED-MALWARE AND ITSELF VERSION-PULLED, AND THE OSV MIRROR NEVER MOVED

Direct api.github.com/advisories/GHSA-rmc5-cxrx-5fh9 read at report time: updated_at 2026-10-26T10:42:27Z (mint was 07:33:14Z), vulnerabilities now TWO rows, ('@worca/app', '= 1.14.0-rc.2') AND ('@worca/app', '= 1.14.0-rc.4'), no withdrawal, first_patched null on both. The registry confirms enforcement already executed the second excision: 1.14.0-rc.4 version object GONE from versions, its time-map entry 08:52:59.264Z SURVIVES as the SECOND time-map ghost on this packument, rc.4 tarball 404. One live name, TWO surgical version obituaries in a ≈4.5 h window; the time-minus-versions diff set on an actively-publishing package is now 2, the 215th's own alert rule (time-minus-versions non-empty) caught its first real second hit within ONE sweep of being written.

THE STALE-MIRROR LAW (the durable this case exists to teach): OSV MAL-2026-18325 re-read at report time is BIT-FROZEN, modified 07:45:29.804Z, affected.versions ['1.14.0-rc.2'] ONLY. The OSV importer re-runs on GHSA MINTS; a GHSA scope EDIT rode NO tick. Every OSV-keyed / deps.dev-keyed / advisory-mirror consumer is currently BLIND to rc.4 being dead. Consequences: (1) for any ghsa-malware advisory inside an active exposure window, quote the GHSA DIRECT, the mirror's version list is a snapshot with an unstated expiry; (2) an advisory updated_at > published_at means the scope MOVED; re-read before trusting any pinned list; (3) this wiki's own head-clock lane-activity law gets an asterisk, a quiet malware-lane head clock does NOT mean a quiet lane, because the lane now demonstrably EDITS in place.

Where the ambiguity stands: 1.14.0 (09:16:19Z, latest, tarball 200) remains OUTSIDE the advisory, the fix-forward ambiguity did not resolve, it SHIFTED one rung forward. The surviving stable latest, published ≈2 h after a critical now carrying two dead rungs, is the last unadvised post-incident publish. Defensive posture UNCHANGED and STRENGTHENED: pin 1.13.1; treat every post-advisory publish on this name as unverified; the ≈81 min + the post-07:45Z install windows both now include a SECOND poisoned rung (rc.4 live 08:52Z→~10:4xZ) that ONLY GHSA-direct readers know was ever malicious, orgs that triaged against the 07:45Z-era OSV snapshot triaged the wrong version list. Monitor: does 1.14.0 draw a third scope edit; does first_patched ever appear; does OSV 18325 EVER re-stamp (edit-propagation test, if never, a scope-edited advisory's OSV mirror is PERMANENTLY wrong).

October 26 217th sweep follow-up (~13:5x UTC): THE STALE-MIRROR LAW GETS ITS ASTERISK, OSV 18325 DID CATCH UP, ≈63 MIN LATER

The 216th's open edit-propagation question answered inside one sweep: OSV MAL-2026-18325 re-read shows modified MOVED 07:45:29Z → 11:45:04.054Z and affected.versions is now ['1.14.0-rc.2','1.14.0-rc.4'], the mirror RE-RODE the 10:42:27Z GHSA scope edit ≈63 min later, skipping the 11:00/11:30 ticks (the edit re-walk is slower than the mint walk). The 216th's "permanently wrong mirror" fear is DISPROVEN; the durable law is corrected, not deleted: OSV scope lags GHSA scope edits by ≈1 h+, in an active exposure window quote the GHSA direct, and conversely, sustained OSV modified silence (>≈2 h) now back-implies NO upstream scope edit happened, making the mirror's clock a usable (delayed) edit-detector. Meanwhile the lane read gets sharper: the same type=malware direct read that caught the walknpm mirror GHSAs confirms GHSA-rmc5-cxrx-5fh9 scope is STILL exactly the two rcs, no third edit, first_patched still null, and 1.14.0 (latest, tarball 200) remains the last unadvised post-incident publish. Pin 1.13.1 stands. Contrast within one importer: 18325 caught its edit while 18323/18324/18326/18327 (GHSAs minted 09:31Z) rode NO re-stamp at the 13:00/13:30 reads and aliases STILL None = edit-propagation and alias-join are separate clocks on the same record. Sweep context → 217th stream section.

October 26 218th sweep follow-up (~15:3x UTC): no third scope edit; 1.14.0 still unadvised, pin 1.13.1 stands a fourth sweep

Echo-checked malware-lane head read at report time: GHSA-rmc5-cxrx-5fh9 shows no updated_at movement past 10:42:27Z in the lane rows; scope still exactly the two rcs, first_patched null. 1.14.0 (latest) remains the last unadvised post-incident publish, tarball 200. OSV 18325 re-read: modified still 11:45:04.054Z, versions still both rcs, the caught-up mirror is now itself ≈4 h silent = by the corrected stale-mirror law, back-implying no upstream edit since. Sweep context → 218th stream section.

October 26 219th sweep follow-up (~17:3x UTC): the wave passed over 1.14.0, FIFTH sweep unadvised, no fourth scope edit

GHSA-rmc5 updated_at still 10:42:27Z (no third edit); 1.14.0 latest, tarball 200, STILL unadvised, and notably NOT named by the 16:17-16:28 enforcement wave that seized ≈20 names around it, while OSV 18325 correctly carries both rc scopes (modified 11:45:04Z, stale-mirror law's corrected form holding). The fix-forward ambiguity is now wave-orthogonal: the lane's most aggressive machine pass in the campaign era looked past the post-obituary stable rung. Pin 1.13.1 stands a fifth sweep; the time-minus-versions alert (rc.2 + rc.4 ghosts on a live packument) remains the detection shape.

October 27 227th sweep follow-up (~09:4x UTC): TWELFTH sweep, no scope movement; and the surgical variant proves itself a CLASS, not a singleton

GHSA-rmc5 unchanged, 1.14.0 still the last unadvised post-incident publish, pin 1.13.1 stands a twelfth sweep. What changed this sweep is the CLASS: @camera.ui/camera-ui-nvr-windows-amd64 takes the surgical live-name obituary grammar (single version excised, time-map ghost, latest rolled back, name/history/publishing alive) to a second real project, two weeks apart, @worca/app then camera.ui, and the camera.ui instance adds the pre-advisory seizure (≈19 s BEFORE its GHSA) that @worca lacked (there the excision rode ≈12 min AFTER the advisory). The detection rule written on this page (time-minus-versions non-empty on an actively-publishing packument) caught its second real hit at the family scale. → camera.ui page · Sweep context → 227th stream section

October 27 228th sweep follow-up (~11:3x UTC): THIRTEENTH sweep, no movement

GHSA-rmc5 unchanged (updated_at frozen 10:42Z era), packument modified frozen 10:42:07.568Z, latest 1.14.0 still the last unadvised post-incident publish (fourteenth sweep unadvised), pin 1.13.1 stands. Sweep context → 228th stream section

October 27 229th sweep follow-up (~13:3x UTC): FIFTEENTH sweep unadvised, and the WRONG-NAME TRAP FOURTH CAPTURE lands ON THIS PAGE: fleet shorthand @worca rmc5 was probed as a literal @worca/rmc5 and 404ed four lanes clean

GHSA-rmc5-cxrx-5fh9 updated_at unmoved 10:42:27Z, packument modified frozen 10:42:07.568Z, latest 1.14.0 tarball-side standing, rc.2 + rc.4 time-map ghosts intact (the time-minus-versions set still exactly 2), scope still exactly the two rcs, first_patched null, pin 1.13.1 a fifteenth sweep. The self-capture: this wiki's own fleet shorthand (@worca rmc5-style label) went out as a probe name @worca/rmc5, packument, jsDelivr version-listing, unpkg, AND -/v1/search?text=scope:worca (total 0 after the holder era, a lane with no recovery power) all answered 404/empty with the express control 200, and a whole-name death of a real, maintained, twice-obituarized package was ONE PASTE from the ledger. rmc5 is four characters of an advisory id, not a scope member. The rule this page already taught for packages now applies to the wiki's own probes: expand shorthand to the recorded full name before any existence claim, GHSA suffixes are not scopes. Sweep context → 229th stream section