CVE-2023-38372 is a medium severity (CVSS 5.9) authentication flaw in IBM Watson IoT Platform 1.0: an attacker who has obtained a security authentication token can impersonate an authorized platform user. IBM lists no code fix. Its bulletin gives least privilege guidance for API keys instead.
What's affected
The affected product is IBM Watson IoT Platform 1.0. The record says an unauthorized attacker who has obtained a security authentication token can use it to impersonate an authorized platform user. The record is dated 2024-02-29 and scores 5.9, Medium, with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N. IBM's bulletin gives the same score.
IBM's bulletin does not give a fixed version. Its remediation section says to follow the guidance under workarounds and mitigations. That guidance is about application security: assign each API key the least privileged role that its application needs, use the lowest role by default (the Visualization Application role), create dedicated API keys per application, and consider the exposure if a key is compromised. There is no patch to install.
Weakness class: CWE-287.
How to check if you're exposed
Review the API keys in your Watson IoT Platform organisation. For each key, record its role and the application that uses it.
Look for keys with broad roles, keys shared between applications and keys that appear in source code or configuration files. A scan of your repositories for committed secrets is worthwhile, because the weakness is only exploitable when a token is obtained by someone else.
What to do now
- List all API keys in each Watson IoT Platform organisation and the role each one has.
- Reduce each key to the least privileged role its application needs.
- Create a separate key per application so you can revoke one without breaking others.
- Search source repositories, build logs and configuration files for committed tokens and keys.
- Rotate any key you suspect has been exposed.
Why it matters
This is a token handling problem more than a bug in code. A bearer token proves identity by itself, so whoever holds it is treated as the user. If the token is stolen from a log, a repository or a device, the platform cannot tell the difference. The defence is to limit what each token can do and to make rotation easy.
Because IBM's guidance is about key hygiene, the work sits with your teams. Over-privileged keys on IoT devices are a common finding, since the device is physically out in the world. The CVE is not on the CISA Known Exploited Vulnerabilities list, and IBM's bulletin does not report exploitation.
Improper authentication means the product accepts a claim of identity without adequately proving it, or accepts a credential or token that it should not trust. Tokens and keys should be treated as secrets, scoped to the least access needed, and revocable.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan covers the dependencies a code project declares. It does not see firmware, desktop software or vendor appliances, so keep this item in your asset inventory and track the vendor's advisory.
Quick check
Is there a patch?
IBM's bulletin gives mitigations and no fixed version.
What is the quickest improvement?
Give each key the least privileged role, one key per application, and rotate any you cannot account for.
Sources
Last reviewed: 19 October 2026.
