chore(security): pin @asyncapi/specs to 6.11.1 (Miasma RAT supply-chain compromise)

[gyancr7]

Fixes #2641

Why

On 2026-07-14, several AsyncAPI npm packages were compromised via malicious commits and CI/CD publication. @asyncapi/specs@6.11.2 was published with obfuscated malware (Miasma RAT — a credential stealer targeting browsers, SSH keys, npm tokens, and crypto wallets). @asyncapi/specs has ~2.7M weekly downloads.

Reference: https://safedep.io/asyncapi-generator-supply-chain-attack-miasma-rat/

This repo pulls in @asyncapi/specs transitively (it is not a direct dependency):

packages/api  ->  @stoplight/spectral-cli@^6.15.0   (devDependency, used by the `lint:openapi` script)
              ->  @stoplight/spectral-rulesets@>=1
              ->  @asyncapi/specs@^6.8.0

The committed yarn.lock currently resolves the safe 6.11.1, so existing installs are fine. However, the declared range ^6.8.0 means any fresh resolve / lockfile regeneration could silently pull the compromised 6.11.2.

What

• Add "@asyncapi/specs": "6.11.1" to the root resolutions block.
• yarn install updated the lockfile descriptor from ^6.8.0 to a pinned 6.11.1. The resolved version and checksum are unchanged — same known-safe artifact, just made explicit and immutable.

Scope

Minimal: package.json (+1 resolution) and yarn.lock (descriptor key only). No source or runtime behavior change; I did not add a changeset since this only affects dev-tooling dependency resolution — happy to add one if preferred.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 9dac4d1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

@gyancr7 is attempting to deploy a commit to the HyperDX Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR pins a transitive AsyncAPI package to a known-safe release. The main changes are:

• Adds an exact @asyncapi/specs@6.11.1 root resolution.
• Updates the lockfile descriptor to match the exact pin.
• Preserves the existing resolved artifact and checksum.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.
• The exact resolution is consistent with the repository's Yarn 4 setup.
• The lockfile contains one matching entry with the existing safe artifact.

Important Files Changed

Filename	Overview
package.json	Adds a valid root-level Yarn resolution for @asyncapi/specs@6.11.1.
yarn.lock	Changes the descriptor to the exact version while preserving the resolved package and checksum.

_{Reviews (1): Last reviewed commit: "chore(security): pin @asyncapi/specs to ..." | Re-trigger Greptile}

[github-actions]

Deep Review

✅ No critical issues found. This is a correct, minimal, and effective supply-chain pin. The core risk — that re-keying the lockfile descriptor from ^6.8.0 to 6.11.1 while the dependent @stoplight/spectral-rulesets keeps requesting ^6.8.0 (yarn.lock:8933) would break yarn install --immutable in CI — was investigated and disproven. The existing unscoped cookie resolution demonstrates the exact same shape: a single lockfile entry keyed cookie@npm:^0.7.0 (yarn.lock:13554) absorbs dependents that keep divergent ranges (^0.5.0, 0.4.2, ~0.7.1), and that lockfile passes CI today. Yarn Berry's unscoped resolutions overrides every descriptor for the package name at install time, so ^6.8.0 is forced to the single 6.11.1 entry and cannot float to the compromised 6.11.2.

Verified during review:

• @asyncapi/specs is the only requester of that package in the tree (^6.8.0), which 6.11.1 satisfies — the exact pin cannot break an incompatible consumer.
• The resolved version and checksum are unchanged from the pre-incident lockfile; no 6.11.2 descriptor, resolution, or checksum appears anywhere in yarn.lock.
• @asyncapi/specs is the only @asyncapi/* package in the tree, so sibling packages from the same incident require no additional pin.
• Exact-pinning (not ^6.11.1) is the security-correct choice, since a caret range would re-admit 6.11.2.

🔵 P3 nitpicks (2)

• package.json:84 — no changeset accompanies the dependency pin, which AGENTS.md calls for on release-worthy changes.
  • Fix: Leave as-is, or add a patch changeset only if maintainers consider a transitive-pin release-worthy; the root is "private": true and this publishes no new dependency to consumers, so the skip is defensible.
• package.json:84 — the security rationale for the exact pin lives only in the commit message, so a future maintainer could "clean up" the odd exact pin and reintroduce the compromised version (pre-existing pattern: the resolutions block already holds several undocumented security pins, and JSON cannot carry inline comments).
  • Fix: Optionally track the pin in a docs or security note so it can be relaxed once a fixed 6.11.3+ is published, since the exact pin will otherwise silently block future patch upgrades with no reminder.

---

Reviewers (4): correctness, security, project-standards, maintainability.

Testing gaps: None applicable to a dependency-manifest pin. Verification note: confirm CI runs yarn install --immutable so the pinned lockfile cannot be silently regenerated (the resolutions field enforces 6.11.1 on any resolve regardless, so this is defense-in-depth, not a gap).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
hyperdx-oss	Ignored	Preview	Jul 14, 2026 1:05pm
hyperdx-storybook	Ignored	Preview	Jul 14, 2026 1:05pm