Outdated broadcast-channel dependency introduces vulnerable @babel/runtime transient dependency

[RyanW02]

Describe the bug

115be54 downgraded the version of broadcast-channel, which has a transient dependency on @babel/runtime v7.22.10, which is vulnerable CVE-2025-27789.

Perhaps we could downgrade override the version of @babel/runtime until you are able to upgrade broadcast-channel?

Reproduction Steps?

N/A

SDK Versions

7.14.0

Additional Information?

No response

[jaredperreault-okta]

Perhaps we could downgrade override the version of @babel/runtime

I'm not sure I fully understand your question, but we are overriding the version of @babel/runtime here: https://github.com/okta/okta-auth-js/blob/master/package.json#L238. 7.27.0 contains the CVE fixes, which were released in 7.26.10

[christopherschroer]

@jaredperreault-okta The override does not seem to be propagating to repos that depend on okta-auth-js. Here is my output when I run pnpm why @babel/runtime@7.22.10

[jaredperreault-okta]

We will look into this internally

In the meantime, I suggest using pnpm overrides (useful guide) to force the non-vulnerable @babel/runtime version to unblock yourself

[WeihanLi]

Any update?

[hokiepokedad2]

Hello, we are seeing the same issue. We are not using pnpm but npm with package overrides. Even with our overrides defined, our vulnerability scanner still picks up @babel/runtime@7.22.10. Any progress?

[richardowen]

@hokiepokedad2 this is working for me in NPM with this package.json:

{
  "dependencies": {
    "@okta/okta-auth-js": "^7.14.0"
  },
  "overrides": {
    "@babel/runtime": "^7.26.10"
  }
}

Without the override, @babel/runtime version 7.22.10 is present in the package-lock.json, and gets picked up by the GitHub dependency graph and Dependabot alerts. But with the override, that version is no longer present in the package-lock.json, and the Dependabot alert is resolved.

[jaredperreault-okta]

This is something I am working on resolving, however this does require a major version bump, so it will take some time.

I can't speak to specific vulnerability scans, but reviewing your lockfiles or running yarn why @babel/runtime, you should be able to confirm the vulnerable version of @babel/runtime is not included