CVE-2024-7401 is an authentication weakness in how the Netskope Client (NSClient) enrolls with a tenant. It is rated High (CVSS 7.5). Enrollment uses a static token called Orgkey that cannot be rotated or revoked if leaked. Netskope documents it in advisory NSKPSA-2024-001.
What's affected
The record says Netskope was notified about a gap in the Netskope Client enrollment process, where the client uses a static token, the "Orgkey", as an authentication parameter. Because the token is static, a leaked one cannot be rotated or revoked. A malicious actor can use it to enroll an NSClient into a customer's tenant and impersonate a user.
The record lists the Netskope product with no version range, and its references are the vendor advisory NSKPSA-2024-001, the vendor's secure enrollment documentation at docs.netskope.com, and a third party site, quickskope.com. I tried to read the vendor advisory, but the page did not load for me, so I cannot give you affected or fixed client builds. That detail has to come from the advisory itself. Do not assume a version is safe because it is recent, and do not assume a specific one is vulnerable, until you read the vendor text.
On severity, the vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. That means network reachable, low complexity, no privileges, no user interaction, with the impact limited to integrity. The score of 7.5 follows from that, and I found no conflicting rating in the pages I read.
How to check if you're exposed
This is a configuration and tenant question as much as a version question. Work through these checks with your Netskope administrators.
- Read NSKPSA-2024-001 and the secure enrollment documentation to see which client builds and which enrollment settings the vendor covers.
- Check the NSClient build deployed on your endpoints, using your device management inventory.
- Review the list of enrolled devices and users in your tenant for ones you do not recognize, and look at the dates they enrolled.
- Find out where your Orgkey or enrollment configuration has been stored or shared, such as in packaging scripts, wikis, tickets or chat.
What to do now
- Read the vendor advisory and follow its remediation steps for your deployment.
- Turn on the secure enrollment option the vendor documents, if the advisory says it addresses this issue in your setup.
- Audit enrolled clients and remove any that do not match a real device and user.
- Treat the Orgkey like a secret from now on. Remove it from places where many people can read it.
- Add the client to your software inventory with its build number, so the next vendor notice maps to a list of devices. The vulnerability management demo shows the workflow.
Why it matters
The weakness is CWE-287, improper authentication. The root problem is a credential that is shared across everything in a tenant and cannot be changed. A secret that lives in installers and scripts will eventually be seen by someone who should not see it. Without a way to rotate or revoke it, one leak becomes a long lived weakness.
For a security client, the stakes are specific. An impersonated device or user inside a tenant can distort what the security team sees and may act with the rights of the identity it claims. The record does not set the KEV flag, and no source I read reports exploitation.
Quick check
Is a patch the only fix?
The vendor advisory is the source for this. The record points to Netskope's secure enrollment documentation, which suggests a configuration change is part of the answer, so read both documents.
What does an attacker need?
The record says the Orgkey token. With it, an actor can enroll a client into the tenant and impersonate a user.
Sources
- Netskope advisory NSKPSA-2024-001 (page did not load for me, check it directly)
- Netskope secure enrollment documentation
- Gold page for CVE-2024-7401
Last reviewed: 19 October 2026.
