Insufficient Verification of Data Authenticity Affecting langfuse-3 package, versions <3.224.3-r0
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-WOLFILATEST-LANGFUSE3-18759487
- published13 Aug 2026
- disclosed12 Aug 2026
Introduced: 12 Aug 2026
NewCVE-2026-73419 (opens in a new tab)How to fix?
Upgrade Wolfi langfuse-3 to version 3.224.3-r0 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream langfuse-3 package and not the langfuse-3 package as distributed by Wolfi.
See How to fix? for Wolfi relevant fixed versions and status.
NextAuth.js provides authentication for Next.js. Prior to@auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, Auth.js stores the OAuth/OIDC anti-CSRF checks state, nonce, and the PKCE verifier in global cookies that are not bound to the provider that created them. On callback, a check value minted during a sign-in started with one provider can satisfy the callback for a different provider because the stored cookie is not verified against the callback provider's identity, including the provider ID, issuer, client ID, or redirect URI. In a multi-provider application that permits account linking while logged in, when one provider's authorization request is observable and a target provider callback can be satisfied without a PKCE verifier, an attacker can lure a victim into starting a legitimate same-origin flow and link the attacker's target-provider account to the victim's Auth.js user. The linked provider grants the attacker persistent sign-in to the victim's account, while cross-site request forgery alone is insufficient. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.
References
- https://github.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05
- https://github.com/nextauthjs/next-auth/commit/9f7a97fade9b1319bb9ac19fc9828d62e0a2a852
- https://github.com/nextauthjs/next-auth/pull/13469
- https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3
- https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15
- https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32
- https://github.com/nextauthjs/next-auth/security/advisories/GHSA-x445-f3h2-j279