Desk briefing: Gatekeeper cleared it, and that is the story

Tuesday. Here is the honest patch list from overnight, in the order I would actually work it.

Gatekeeper cleared it — that is the story

Jamf Threat Labs flagged CrashStealer on Sunday: a native-C++ macOS infostealer arriving inside Werkbit.app, a signed disk image on an Apple Developer ID (WWB7JA7AQV) whose current notarization Gatekeeper honors. The download is gated behind a meeting PIN, so this is a targeted delivery pattern — not a spray. That framing is the entire reason this belongs above every other Mac malware writeup this quarter.

The trust chain most Mac fleets rely on — if Gatekeeper cleared it, right-click-open — was doing what it advertised. Apple had signed the dropper’s Developer ID. The notarization service had inspected the disk image and returned a valid ticket. CrashStealer is not defeating any of that. It is being carried by it.

If you have a formal macOS policy, the honest work this week is short:

• Assume notarization tells you Apple has not yet decided to distrust a Developer ID. It does not tell you the file behind it is safe.
• If your fleet management supports allow-listing Developer IDs, use it. Apple’s revocation posture is a lagging control, not a leading one — a compromised or throwaway Developer ID stays valid until Apple catches up.
• If you run EDR, confirm its post-execution telemetry is actually landing in your SIEM. Notarization is going to get walked past again. This is not the last one.

I am not going to walk through the payload. Jamf’s writeup, as summarized by The Hacker News, has the technical shape. The action is the policy conversation, not the reverse-engineering.

ModHeader: pull it, then have the conversation with your users

ModHeader is out of both stores — Edge pulled it July 3, Chrome pulled it July 10. About 900,000 Chrome installs and 700,000 Edge installs. Stripe OLT found a dormant browsing-history collector in versions 7.0.17 and 7.0.18, sitting inside the same code both stores’ review pipelines had signed. The allow-list gating the collector ships empty; no exfil is on record; the pipeline never fires. The pipeline is in the code both platforms distributed.

The honest job:

1. Query your endpoint fleet for extension ID idgpnmonknjnojddfkpgkljpfnnfcklj. If you have EDR with browser-extension inventory, this is a saved-search job. If you don’t, an MDM policy that walks the browser’s local extension store will get you there.
2. Force-remove where you find it. Not “recommend uninstall” — force-remove. The dormant pipeline is not the point. The lesson your endpoint policy should learn is.
3. Tell your users why. ModHeader is a legitimate developer tool with an active user base. “We pulled a tool you used” without an explanation lands badly and slowly convinces people to sideload the replacement they find on GitHub.

The broader point I keep making internally: an extension review pipeline is a detection control, not a prevention control. Both stores cleared this build. That is not going to change quickly. Your policy is what changes.

Jscrambler update: it was not just 8.14.0

Loop’s post-mortem coverage overnight widens the picture from Monday’s briefing. Jscrambler’s own writeup says the compromised releases were not one but four — jscrambler 8.14, 8.16, 8.17, and 8.20 on npm, all pushed by an attacker in possession of the vendor’s publish credentials. The next clean version is 8.22. Publish credentials have been revoked. Four dependent packages that resolved against the malicious releases were deprecated and republished under new versions in the same window.

The Monday action list still applies. The version net just widened:

1. Search your lockfiles for any of jscrambler@8.14, 8.16, 8.17, or 8.20. Not just 8.14.0.
2. If a CI job installed any of those between the push and the yank, rotate every credential that job had access to. NPM tokens, cloud-provider keys, repo-scoped GitHub tokens. All of them.
3. Pin to 8.22 or later. Do not skip the pin because the yanked versions cannot be re-installed — a lockfile committed before the yank still pins them, and npm ci against it will still try.

The root cause Jscrambler names is the plain one — a token belonging to an account with publish rights on jscrambler was in somebody else’s hands. Not a build-system compromise. Not a co-maintainer social-engineering chain. A publish token. This is the tenth time this year the shape has been exactly that. It will be the eleventh next month.

The CISA leak is a mirror

Kilobaud has the CISA postmortem — worth reading in full — and the load-bearing sentence is Guillaume Valadon’s, quoted in Krebs’ writeup: letting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure.

The specific case is a CISA contractor who dropped 844 MB of internal material into a public GitHub repository, including AWS GovCloud administrative keys and a CSV titled AWS-Workspace-Firefox-Passwords.csv. GitGuardian’s scanner fired nine automated alerts into an unread inbox. Krebs personally called it in. Only then did the clock start.

If you run a security program at an organization with a public GitHub surface, the mirror is this: your security@ alias exists to receive reports about your products. It does not exist to receive reports about your organization itself. That routing gap is the CISA gap, and it lives at almost every large org. Fix it this week if you can — a lightweight page saying “report a credential leak affecting our organization here” that routes to a real human, not the same abuse queue that fields spam. It costs an afternoon and it closes a category the CISA postmortem admits nobody has been closing.

Also on the desk

Airgap on the Lidl disclosure — customer data from the online shops in Germany, Belgium, and the Netherlands went out through a service-provider incident. This is a vendor-risk item, not a patch item. If your program has a third-party inventory, use this week’s incident to test whether your intake would have flagged the affected provider. If you don’t have that inventory, this is the case study to hand to whoever owns procurement.

Nihon Kotsu — Japan’s largest taxi operator — is heading into day three with dispatch, web booking, and reservation systems still offline after Saturday’s malware incident. No group has claimed. The operator has framed it as malware rather than ransomware. No restoration timeline. Watch for either an extortion post or a company update; either would change what class of incident this is.

Also, briefly, from Monday’s late queue: Loop on MemGhost — the arXiv paper on persistent false-memory injection against AI agents; the Huntress finding on AI-generated PowerShell for AD enumeration — an intrusion where the enumeration tooling itself was clearly vibe-coded; and Kilobaud’s Lexfo Evilginx writeup — three phishing operations lifted off one misconfigured public server. All three worth a read; none change your patch list.

What to watch

1. Whether Apple revokes the WWB7JA7AQV Developer ID and how long it takes. The notarization ticket for a specific build stays valid until Apple invalidates it; the population of Mac fleets that check for revocation on execute is not the population of Mac fleets that exist.
2. A second browser-extension pipeline story this week. ModHeader was a dormant collector both stores signed. The substrate — a review pipeline that greenlights code paths dependent on a runtime flag — has not changed.
3. Jscrambler’s disclosure of how the publish credential was obtained. The vendor writeup says “compromised credential” and does not say phishing, token exfil from a build box, or reuse of a leaked secret. Any of those narrows the shape of the next one.
4. Nihon Kotsu day-four status. A restoration announcement would suggest a smaller incident; an extortion-site listing would put this squarely in the ransomware column regardless of what the operator called it publicly.

Tip the desk

Source, document, or context on any story we’re tracking? Reach the desk at contact@0daynews.com, or for coordinated-disclosure matters, takedown@0daynews.com.

— Fuse