No Fix for the Apex Backslashes, npm Acted Before We Did, and the Predecessor Is Still Live
The actor behind the Apex Accelerator npm malware never shipped a fix for the broken backslashes we described yesterday. They stopped shipping entirely. npm deprecated @apexacc/cli on October 13, three days before we reported it, so we did not cause that. But the actor's earlier package, @apexscore/cli, is still live on npm with no OSV record, and as of this morning our check-package blocks it.
Did they fix the backslashes?
No. Yesterday we showed that @apexacc/cli versions 1.5.122 through 1.6.2 try to add a Windows Defender exclusion and turn off Smart App Control from an elevated PowerShell, and that unescaped backslashes in a JavaScript template literal break both commands. The UAC prompt still appears. The full read is in our post on the backslash bug.
We checked the registry this morning. The latest version is still 1.6.2, from September 27. The package record was last modified on October 13 at 02:58 UTC, and every version now carries npm's deprecation notice. The companion @apexacc/audit no longer exists on the registry. None of the three npm accounts tied to the campaign (apexaccelerator, buildtools and apex-fdn) has published anything new.
If they come back, we expect a new account and a new name, not a version 1.6.3. Watching for a fixed release is the wrong test. Watching for the same launcher under another name is the right one, and we are doing it.
Did we have anything to do with npm's action?
No. Elastic Security Labs published REF8801 on October 12. npm deprecated the package about 15 hours later. Our report to npm and our two OpenSSF pull requests went out on October 16, and our own report noted that @apexacc/audit was already gone. The credit for the takedown belongs to Elastic's research and to npm's response.
There are two gaps we are filling. A deprecation is a warning, not a removal, so the 1.6.2 tarball still downloads. And OSV has no record for @apexacc/cli, @apexacc/audit or @apexscore/cli as of this morning, so tools that read OSV still say nothing. Our OpenSSF pull request #1644 would fix that for the first two. It is open, with no review yet.
The predecessor nobody had recorded
@apexscore/cli was published by an npm account called buildtools, with a support address at apexfdn.xyz, a domain in Elastic's REF8801 indicators. It shipped 33 versions between July 30 and August 9, the day @apexacc/cli was created. It was downloaded 216 times in the week of October 6 to 12. Elastic's report does not name it.
We read the latest version, 1.1.1, without running it, straight from the registry tarball in memory. Here is what it does and does not do.
It downloads a roughly 150 MB native binary from the GitHub releases of Apex-Accelerator/apexcli into a hidden folder in your home directory and runs it. On macOS it also fetches a helper called apex-verify. On Windows it fetches a native add-on. Versions of @apexacc/cli point to that same repository, which now returns 404.
Its integrity check downloads the expected hash from the same release as the binary, so it proves nothing.
An install script sits in the package but is not wired to run in any of the 33 versions. It quietly exits if it sees an AI coding agent or a sandbox, checking for Claude Code, Cursor, Windsurf, and Anthropic or OpenAI API keys in the environment. Whether that was ever live, we cannot say from the packages alone.
It does not contain the Defender or Smart App Control commands. The homepage moved from arena.apexfdn.xyz to arena.apexaccs.org in the last version. Both are in Elastic's indicators.
The package carries npm provenance, a signed statement that it was built from Apex-Accelerator/apexcli. That proves where it was built. It does not prove it is safe.
Our verdict is by lineage. We did not examine the binary it downloads, and we will not fetch it. That is why we ingested it at confidence 80 rather than 90. 80 still blocks.
If npm or OSV acts on @apexscore/cli after our report, that one is ours to point to. We will say so either way.
The PhantomSub family, finished
Yesterday we promised a hunt for siblings of the Baileys forks that OX Security named in its PhantomSub research on September 28. The family is now on our deny-list in three tiers.
We block 94 packages, where a WhatsApp channel ID is bound directly to the call that subscribes your account to it. That was checked by a strict code pass and then by hand on a seeded random sample. We mark 96 as review, not block: 3 announce the auto-follow in a banner, and 93 have IDs we found only by decoding obfuscated strings. We hold out 49 that failed the strict pass, including one where the follow code is commented out.
All 190 records were written and read back by primary key. None of these packages had an OSV record when we checked. Yesterday morning check-package said ALLOW for every one.
Our own miss, by the numbers
Yesterday's post said our deny-list had stored only the versions OSV listed at sync time, so newer versions of known-malicious packages got "review" instead of "block." We projected about 11,200 affected entries from a sample.
Update, 15:20 UTC: the re-sync finished. It paused overnight when the search database timed out on one 91-record write, held its place as designed, and resumed this morning. It scanned all 35,541 candidates and rewrote 11,718 records, each one read back, with zero errors. 11,469 entries now block every version where they used to block only the versions listed at sync time, against our projection of about 11,200. Another 242 were marked withdrawn by OSV, and withdrawn records no longer decide a verdict.
We promised an exposure count too, and here is the honest version. Since July 11, check-package has answered 301 successful calls, and 60 of them came back "review." We cannot say how many of those 60 should have been "block," because we deliberately do not log which package was asked about. So the exposure is at most 60 answers, many of them our own tests. We also found that our own test calls from the command line are counted as external callers. That inflates the outside interest we have been reporting, and we are fixing it.
Corrections carried forward
Yesterday's status post first said 9 blocked packages. The right number was 8, and the post was corrected that night, but its diagram and our LinkedIn status post still say 9. This post supersedes both.
Before publishing we rechecked this post against today's registry, OSV and our own records, and corrected 2 claims: when @apexacc/audit disappeared, and the confidence we gave @apexscore/cli. At least 5% of what remains is still wrong, and we don't know which.
If this was useful, or if it wasn't, rate it at the bottom of the page. It is the only direct signal we get.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=no-fix-for-the-apex-backslashes-npm-acted-before-we-did-and-the-predecessor-is-still-live
Comments