### Summary `has()`, `auth.protect()`, and related authorization predicates in `@clerk/shared`, `@clerk/nextjs`, `@clerk/backend`, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions. Sessions are not compromised and no existing user can be impersonated. The bypass is limited to the authorization decision returned by the predicate. `clerkMiddleware` continues to authenticate requests correctly, `auth()` reflects the real authentication state, and token verification is unaffected. ### Who is affected All apps that combine more than one authorization dimension in a single `has()` or `auth.protect()` call should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps developers understand whether their apps are potentially affected, but is not a reason to delay the upgrade. This call shape can be bypassed if certain conditions are met: a `has()` or `auth.protect()` call that combines a `reverification` check with any of `role`, `permission`, `feature`, or `plan`, or that combines a billing check (`feature` or `plan`) with a role or permission check. ```ts // Reverification combined with role / permission / feature / plan await auth.protect({ permission: 'org:settings:delete', reverification: 'strict' }); const canAct = has({ role: 'org:admin', reverification: 'strict' }); // Billing (feature / plan) combined with role / permission const canAct = has({ permission: 'org:admin', feature: 'premium' }); ``` Single-condition checks are not affected and continue to fail closed as expected: ```ts await auth.protect({ permission: 'org:settings:delete' }); has({ reverification: 'strict' }); ``` The callback form of `auth.protect` is not affected unless the callback itself invokes one of the affected shapes: ```ts await auth.protect(has => has({ permission: 'org:X' }) && has({ reverification: 'strict' })); ``` App patterns that rely only on single-condition checks, or that combine them via the callback form, are unaffected. Authentication, session state, and token verification continue to work correctly regardless of this bypass. `@clerk/shared` is usually not imported directly in application code, but the fix lives there and reaches an app through its framework package. If developers import `createCheckAuthorization` from `@clerk/shared` directly, their apps are also affected. Run `npm why @clerk/shared` (or the app's package manager's equivalent) to check the installed version. ### Additional `auth.protect()` bypass A second, related bypass lives in `@clerk/nextjs`: `auth.protect()` silently discarded authorization params (`role`, `permission`, `feature`, `plan`, `reverification`) whenever the same argument object also contained `unauthenticatedUrl`, `unauthorizedUrl`, or `token`. ### Recommended actions Upgrade to the latest patch release of the consuming app's framework package on its current major. Both Core 2 and Core 3 release lines have patches. See the "Affected packages" section above for the exact vulnerable ranges and patched versions per package. If a consuming app pins `@clerk/clerk-js` directly, upgrade it to the patched version. Most apps load `@clerk/clerk-js` from Clerk's CDN through their framework package and will receive the fix automatically, with no upgrade step required. ### Workaround If developers cannot upgrade immediately, split combined `has()` or `auth.protect()` calls into sequential single-condition checks: ```ts // Replace await auth.protect({ permission: 'org:X', reverification: 'strict' }); // With await auth.protect({ reverification: 'strict' }); await auth.protect({ permission: 'org:X' }); ``` Each single-condition check fails closed as expected, so evaluating them independently and denying if either fails produces the correct result. ### Timeline This issue was reported on 18 APR 2026, patched on 22 APR 2026, and publicly disclosed on 22 APR 2026. Thanks to AISafe for the responsible disclosure of this vulnerability.
### Summary `has()`, `auth.protect()`, and related authorization predicates in `@clerk/shared`, `@clerk/nextjs`, `@clerk/backend`, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions. Sessions are not compromised and no existing user can be impersonated. The bypass is limited to the authorization decision returned by the predicate. `clerkMiddleware` continues to authenticate requests correctly, `auth()` reflects the real authentication state, and token verification is unaffected. ### Who is affected All apps that combine more than one authorization dimension in a single `has()` or `auth.protect()` call should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps developers understand whether their apps are potentially affected, but is not a reason to delay the upgrade. This call shape can be bypassed if certain conditions are met: a `has()` or `auth.protect()` call that combines a `reverification` check with any of `role`, `permission`, `feature`, or `plan`, or that combines a billing check (`feature` or `plan`) with a role or permission check. ```ts // Reverification combined with role / permission / feature / plan await auth.protect({ permission: 'org:settings:delete', reverification: 'strict' }); const canAct = has({ role: 'org:admin', reverification: 'strict' }); // Billing (feature / plan) combined with role / permission const canAct = has({ permission: 'org:admin', feature: 'premium' }); ``` Single-condition checks are not affected and continue to fail closed as expected: ```ts await auth.protect({ permission: 'org:settings:delete' }); has({ reverification: 'strict' }); ``` The callback form of `auth.protect` is not affected unless the callback itself invokes one of the affected shapes: ```ts await auth.protect(has => has({ permission: 'org:X' }) && has({ reverification: 'strict' })); ``` App patterns that rely only on single-condition checks, or that combine them via the callback form, are unaffected. Authentication, session state, and token verification continue to work correctly regardless of this bypass. `@clerk/shared` is usually not imported directly in application code, but the fix lives there and reaches an app through its framework package. If developers import `createCheckAuthorization` from `@clerk/shared` directly, their apps are also affected. Run `npm why @clerk/shared` (or the app's package manager's equivalent) to check the installed version. ### Additional `auth.protect()` bypass A second, related bypass lives in `@clerk/nextjs`: `auth.protect()` silently discarded authorization params (`role`, `permission`, `feature`, `plan`, `reverification`) whenever the same argument object also contained `unauthenticatedUrl`, `unauthorizedUrl`, or `token`. ### Recommended actions Upgrade to the latest patch release of the consuming app's framework package on its current major. Both Core 2 and Core 3 release lines have patches. See the "Affected packages" section above for the exact vulnerable ranges and patched versions per package. If a consuming app pins `@clerk/clerk-js` directly, upgrade it to the patched version. Most apps load `@clerk/clerk-js` from Clerk's CDN through their framework package and will receive the fix automatically, with no upgrade step required. ### Workaround If developers cannot upgrade immediately, split combined `has()` or `auth.protect()` calls into sequential single-condition checks: ```ts // Replace await auth.protect({ permission: 'org:X', reverification: 'strict' }); // With await auth.protect({ reverification: 'strict' }); await auth.protect({ permission: 'org:X' }); ``` Each single-condition check fails closed as expected, so evaluating them independently and denying if either fails produces the correct result. ### Timeline This issue was reported on 18 APR 2026, patched on 22 APR 2026, and publicly disclosed on 22 APR 2026. Thanks to AISafe for the responsible disclosure of this vulnerability.
Update @clerk/astro to 2.17.11; @clerk/astro to 3.0.18; @clerk/backend to 2.33.3; @clerk/backend to 3.2.14; @clerk/chrome-extension to 2.9.15; @clerk/chrome-extension to 3.1.15; @clerk/clerk-expo to 2.19.36; @clerk/clerk-js to 5.125.10; @clerk/clerk-js to 6.7.5; @clerk/clerk-react to 5.61.6; @clerk/expo to 3.2.2; @clerk/express to 1.7.79; @clerk/express to 2.1.6; @clerk/fastify to 2.6.31; @clerk/fastify to 3.1.16; @clerk/hono to 0.1.16; @clerk/nextjs to 6.39.3; @clerk/nextjs to 7.2.4; @clerk/nuxt to 1.13.29; @clerk/nuxt to 2.2.5; @clerk/react to 6.4.3; @clerk/react-router to 2.4.13; @clerk/react-router to 3.1.4; @clerk/shared to 3.47.5; @clerk/shared to 4.8.3; @clerk/tanstack-react-start to 0.29.11; @clerk/tanstack-react-start to 1.1.4; @clerk/vue to 1.17.21; @clerk/vue to 2.0.16 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanClerk has an authorization bypass when combining organization, billing, or reverification checks affects @clerk/astro (npm), @clerk/astro (npm), @clerk/backend (npm), @clerk/backend (npm), @clerk/chrome-extension (npm), @clerk/chrome-extension (npm), @clerk/clerk-expo (npm), @clerk/clerk-js (npm), @clerk/clerk-js (npm), @clerk/clerk-react (npm), @clerk/expo (npm), @clerk/express (npm), @clerk/express (npm), @clerk/fastify (npm), @clerk/fastify (npm), @clerk/hono (npm), @clerk/nextjs (npm), @clerk/nextjs (npm), @clerk/nuxt (npm), @clerk/nuxt (npm), @clerk/react (npm), @clerk/react-router (npm), @clerk/react-router (npm), @clerk/shared (npm), @clerk/shared (npm), @clerk/tanstack-react-start (npm), @clerk/tanstack-react-start (npm), @clerk/vue (npm), @clerk/vue (npm). Severity is high. ### Summary `has()`, `auth.protect()`, and related authorization predicates in `@clerk/shared`, `@clerk/nextjs`, `@clerk/backend`, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions. Sessions are not compromised and no existing user can be impersonated. The bypass is limited to the authorization decision returned by the predicate. `clerkMiddleware` continues to authenticate requests correctly, `auth()` reflects the real authentication state, and token verification is unaffected. ### Who is affected All apps that combine more than one authorization dimension in a single `has()` or `auth.protect()` call should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps developers understand whether their apps are potentially affected, but is not a reason to delay the upgrade. This call shape can be bypassed if certain conditions are met: a `has()` or `auth.protect()` call that combines a `reverification` check with any of `role`, `permission`, `feature`, or `plan`, or that combines a billing check (`feature` or `plan`) with a role or permission check. ```ts // Reverification combined with role / permission / feature / plan await auth.protect({ permission: 'org:settings:delete', reverification: 'strict' }); const canAct = has({ role: 'org:admin', reverification: 'strict' }); // Billing (feature / plan) combined with role / permission const canAct = has({ permission: 'org:admin', feature: 'premium' }); ``` Single-condition checks are not affected and continue to fail closed as expected: ```ts await auth.protect({ permission: 'org:settings:delete' }); has({ reverification: 'strict' }); ``` The callback form of `auth.protect` is not affected unless the callback itself invokes one of the affected shapes: ```ts await auth.protect(has => has({ permission: 'org:X' }) && has({ reverification: 'strict' })); ``` App patterns that rely only on single-condition checks, or that combine them via the callback form, are unaffected. Authentication, session state, and token verification continue to work correctly regardless of this bypass. `@clerk/shared` is usually not imported directly in application code, but the fix lives there and reaches an app through its framework package. If developers import `createCheckAuthorization` from `@clerk/shared` directly, their apps are also affected. Run `npm why @clerk/shared` (or the app's package manager's equivalent) to check the installed version. ### Additional `auth.protect()` bypass A second, related bypass lives in `@clerk/nextjs`: `auth.protect()` silently discarded authorization params (`role`, `permission`, `feature`, `plan`, `reverification`) whenever the same argument object also contained `unauthenticatedUrl`, `unauthorizedUrl`, or `token`. ### Recommended actions Upgrade to the latest patch release of the consuming app's framework package on its current major. Both Core 2 and Core 3 release lines have patches. See the "Affected packages" section above for the exact vulnerable ranges and patched versions per package. If a consuming app pins `@clerk/clerk-js` directly, upgrade it to the patched version. Most apps load `@clerk/clerk-js` from Clerk's CDN through their framework package and will receive the fix automatically, with no upgrade step required. ### Workaround If developers cannot upgrade immediately, split combined `has()` or `auth.protect()` calls into sequential single-condition checks: ```ts // Replace await auth.protect({ permission: 'org:X', reverification: 'strict' }); // With await auth.protect({ reverification: 'strict' }); await auth.protect({ permission: 'org:X' }); ``` Each single-condition check fails closed as expected, so evaluating them independently and denying if either fails produces the correct result. ### Timeline This issue was reported on 18 APR 2026, patched on 22 APR 2026, and publicly disclosed on 22 APR 2026. Thanks to AISafe for the responsible disclosure of this vulnerability.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @clerk/astronpm | >=2.0.0,<=2.17.10 | 2.17.11 |
| @clerk/astronpm | >=3.0.0,<=3.0.17 | 3.0.18 |
| @clerk/backendnpm | >=2.0.0,<=2.33.2 | 2.33.3 |
| @clerk/backendnpm | >=3.0.0,<=3.2.13 | 3.2.14 |
| @clerk/chrome-extensionnpm | >=1.3.5,<=2.9.14 | 2.9.15 |
| @clerk/chrome-extensionnpm | >=3.0.0,<=3.1.14 | 3.1.15 |
| @clerk/clerk-exponpm | >=2.2.11,<=2.19.35 | 2.19.36 |
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate @clerk/astro to 2.17.11; @clerk/astro to 3.0.18; @clerk/backend to 2.33.3; @clerk/backend to 3.2.14; @clerk/chrome-extension to 2.9.15; @clerk/chrome-extension to 3.1.15; @clerk/clerk-expo to 2.19.36; @clerk/clerk-js to 5.125.10; @clerk/clerk-js to 6.7.5; @clerk/clerk-react to 5.61.6; @clerk/expo to 3.2.2; @clerk/express to 1.7.79; @clerk/express to 2.1.6; @clerk/fastify to 2.6.31; @clerk/fastify to 3.1.16; @clerk/hono to 0.1.16; @clerk/nextjs to 6.39.3; @clerk/nextjs to 7.2.4; @clerk/nuxt to 1.13.29; @clerk/nuxt to 2.2.5; @clerk/react to 6.4.3; @clerk/react-router to 2.4.13; @clerk/react-router to 3.1.4; @clerk/shared to 3.47.5; @clerk/shared to 4.8.3; @clerk/tanstack-react-start to 0.29.11; @clerk/tanstack-react-start to 1.1.4; @clerk/vue to 1.17.21; @clerk/vue to 2.0.16 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanClerk has an authorization bypass when combining organization, billing, or reverification checks affects @clerk/astro (npm), @clerk/astro (npm), @clerk/backend (npm), @clerk/backend (npm), @clerk/chrome-extension (npm), @clerk/chrome-extension (npm), @clerk/clerk-expo (npm), @clerk/clerk-js (npm), @clerk/clerk-js (npm), @clerk/clerk-react (npm), @clerk/expo (npm), @clerk/express (npm), @clerk/express (npm), @clerk/fastify (npm), @clerk/fastify (npm), @clerk/hono (npm), @clerk/nextjs (npm), @clerk/nextjs (npm), @clerk/nuxt (npm), @clerk/nuxt (npm), @clerk/react (npm), @clerk/react-router (npm), @clerk/react-router (npm), @clerk/shared (npm), @clerk/shared (npm), @clerk/tanstack-react-start (npm), @clerk/tanstack-react-start (npm), @clerk/vue (npm), @clerk/vue (npm). Severity is high. ### Summary `has()`, `auth.protect()`, and related authorization predicates in `@clerk/shared`, `@clerk/nextjs`, `@clerk/backend`, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions. Sessions are not compromised and no existing user can be impersonated. The bypass is limited to the authorization decision returned by the predicate. `clerkMiddleware` continues to authenticate requests correctly, `auth()` reflects the real authentication state, and token verification is unaffected. ### Who is affected All apps that combine more than one authorization dimension in a single `has()` or `auth.protect()` call should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps developers understand whether their apps are potentially affected, but is not a reason to delay the upgrade. This call shape can be bypassed if certain conditions are met: a `has()` or `auth.protect()` call that combines a `reverification` check with any of `role`, `permission`, `feature`, or `plan`, or that combines a billing check (`feature` or `plan`) with a role or permission check. ```ts // Reverification combined with role / permission / feature / plan await auth.protect({ permission: 'org:settings:delete', reverification: 'strict' }); const canAct = has({ role: 'org:admin', reverification: 'strict' }); // Billing (feature / plan) combined with role / permission const canAct = has({ permission: 'org:admin', feature: 'premium' }); ``` Single-condition checks are not affected and continue to fail closed as expected: ```ts await auth.protect({ permission: 'org:settings:delete' }); has({ reverification: 'strict' }); ``` The callback form of `auth.protect` is not affected unless the callback itself invokes one of the affected shapes: ```ts await auth.protect(has => has({ permission: 'org:X' }) && has({ reverification: 'strict' })); ``` App patterns that rely only on single-condition checks, or that combine them via the callback form, are unaffected. Authentication, session state, and token verification continue to work correctly regardless of this bypass. `@clerk/shared` is usually not imported directly in application code, but the fix lives there and reaches an app through its framework package. If developers import `createCheckAuthorization` from `@clerk/shared` directly, their apps are also affected. Run `npm why @clerk/shared` (or the app's package manager's equivalent) to check the installed version. ### Additional `auth.protect()` bypass A second, related bypass lives in `@clerk/nextjs`: `auth.protect()` silently discarded authorization params (`role`, `permission`, `feature`, `plan`, `reverification`) whenever the same argument object also contained `unauthenticatedUrl`, `unauthorizedUrl`, or `token`. ### Recommended actions Upgrade to the latest patch release of the consuming app's framework package on its current major. Both Core 2 and Core 3 release lines have patches. See the "Affected packages" section above for the exact vulnerable ranges and patched versions per package. If a consuming app pins `@clerk/clerk-js` directly, upgrade it to the patched version. Most apps load `@clerk/clerk-js` from Clerk's CDN through their framework package and will receive the fix automatically, with no upgrade step required. ### Workaround If developers cannot upgrade immediately, split combined `has()` or `auth.protect()` calls into sequential single-condition checks: ```ts // Replace await auth.protect({ permission: 'org:X', reverification: 'strict' }); // With await auth.protect({ reverification: 'strict' }); await auth.protect({ permission: 'org:X' }); ``` Each single-condition check fails closed as expected, so evaluating them independently and denying if either fails produces the correct result. ### Timeline This issue was reported on 18 APR 2026, patched on 22 APR 2026, and publicly disclosed on 22 APR 2026. Thanks to AISafe for the responsible disclosure of this vulnerability.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @clerk/astronpm | >=2.0.0,<=2.17.10 | 2.17.11 |
| @clerk/astronpm | >=3.0.0,<=3.0.17 | 3.0.18 |
| @clerk/backendnpm | >=2.0.0,<=2.33.2 | 2.33.3 |
| @clerk/backendnpm | >=3.0.0,<=3.2.13 | 3.2.14 |
| @clerk/chrome-extensionnpm | >=1.3.5,<=2.9.14 | 2.9.15 |
| @clerk/chrome-extensionnpm | >=3.0.0,<=3.1.14 | 3.1.15 |
| @clerk/clerk-exponpm | >=2.2.11,<=2.19.35 | 2.19.36 |
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard| @clerk/clerk-jsnpm | >=5.22.0,<=5.125.9 | 5.125.10 |
|---|
| @clerk/clerk-jsnpm | >=6.0.0,<=6.7.4 | 6.7.5 |
|---|
| @clerk/clerk-reactnpm | >=5.9.0,<=5.61.5 | 5.61.6 |
|---|
| @clerk/exponpm | >=3.0.0,<=3.2.1 | 3.2.2 |
|---|
| @clerk/expressnpm | >=0.1.0,<=1.7.78 | 1.7.79 |
|---|
| @clerk/expressnpm | >=2.0.0,<=2.1.5 | 2.1.6 |
|---|
| @clerk/fastifynpm | >=1.0.42,<=2.6.30 | 2.6.31 |
|---|
| @clerk/fastifynpm | >=3.0.0,<=3.1.15 | 3.1.16 |
|---|
| @clerk/hononpm | >=0.0.2,<=0.1.15 | 0.1.16 |
|---|
| @clerk/nextjsnpm | >=6.0.0,<=6.39.2 | 6.39.3 |
|---|
| @clerk/nextjsnpm | >=7.0.0,<=7.2.3 | 7.2.4 |
|---|
| @clerk/nuxtnpm | >=1.0.0,<=1.13.28 | 1.13.29 |
|---|
| @clerk/nuxtnpm | >=2.0.0,<=2.2.4 | 2.2.5 |
|---|
| @clerk/reactnpm | >=6.0.0,<=6.4.2 | 6.4.3 |
|---|
| @clerk/react-routernpm | >=0.0.1,<=2.4.12 | 2.4.13 |
|---|
| @clerk/react-routernpm | >=3.0.0,<=3.1.3 | 3.1.4 |
|---|
| @clerk/sharednpm | >=3.0.0,<=3.47.4 | 3.47.5 |
|---|
| @clerk/sharednpm | >=4.0.0,<=4.8.2 | 4.8.3 |
|---|
| @clerk/tanstack-react-startnpm | >=0.0.1,<=0.29.10 | 0.29.11 |
|---|
| @clerk/tanstack-react-startnpm | >=1.0.0,<=1.1.3 | 1.1.4 |
|---|
| @clerk/vuenpm | >=1.0.0,<=1.17.20 | 1.17.21 |
|---|
| @clerk/vuenpm | >=2.0.0,<=2.0.15 | 2.0.16 |
|---|
Fixed versions are reported by the source feed; confirm compatibility before updating.
| @clerk/clerk-jsnpm | >=5.22.0,<=5.125.9 | 5.125.10 |
|---|
| @clerk/clerk-jsnpm | >=6.0.0,<=6.7.4 | 6.7.5 |
|---|
| @clerk/clerk-reactnpm | >=5.9.0,<=5.61.5 | 5.61.6 |
|---|
| @clerk/exponpm | >=3.0.0,<=3.2.1 | 3.2.2 |
|---|
| @clerk/expressnpm | >=0.1.0,<=1.7.78 | 1.7.79 |
|---|
| @clerk/expressnpm | >=2.0.0,<=2.1.5 | 2.1.6 |
|---|
| @clerk/fastifynpm | >=1.0.42,<=2.6.30 | 2.6.31 |
|---|
| @clerk/fastifynpm | >=3.0.0,<=3.1.15 | 3.1.16 |
|---|
| @clerk/hononpm | >=0.0.2,<=0.1.15 | 0.1.16 |
|---|
| @clerk/nextjsnpm | >=6.0.0,<=6.39.2 | 6.39.3 |
|---|
| @clerk/nextjsnpm | >=7.0.0,<=7.2.3 | 7.2.4 |
|---|
| @clerk/nuxtnpm | >=1.0.0,<=1.13.28 | 1.13.29 |
|---|
| @clerk/nuxtnpm | >=2.0.0,<=2.2.4 | 2.2.5 |
|---|
| @clerk/reactnpm | >=6.0.0,<=6.4.2 | 6.4.3 |
|---|
| @clerk/react-routernpm | >=0.0.1,<=2.4.12 | 2.4.13 |
|---|
| @clerk/react-routernpm | >=3.0.0,<=3.1.3 | 3.1.4 |
|---|
| @clerk/sharednpm | >=3.0.0,<=3.47.4 | 3.47.5 |
|---|
| @clerk/sharednpm | >=4.0.0,<=4.8.2 | 4.8.3 |
|---|
| @clerk/tanstack-react-startnpm | >=0.0.1,<=0.29.10 | 0.29.11 |
|---|
| @clerk/tanstack-react-startnpm | >=1.0.0,<=1.1.3 | 1.1.4 |
|---|
| @clerk/vuenpm | >=1.0.0,<=1.17.20 | 1.17.21 |
|---|
| @clerk/vuenpm | >=2.0.0,<=2.0.15 | 2.0.16 |
|---|
Fixed versions are reported by the source feed; confirm compatibility before updating.