IBM Support

Security Bulletin: An unauthorized attacker who has obtained an IBM Watson IoT Platform security authentication token can use it to impersonate an authorized platform user (CVE-2023-38372)

Security Bulletin


Guidance on best practices to mitigate or avoid compromise in case an unauthorized attacker obtains an IBM Watson IoT Platform security authentication token (CVE-2023-38372).

Vulnerability Details

CVEID:   CVE-2023-38372
DESCRIPTION:   IBM Watson IoT Platform contains a vulnerability that could allow an unauthorized attacker to obtain security authentication tokens.
CVSS Base score: 5.9
CVSS Temporal Score: See: for the current score.
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N)

Affected Products and Versions


Affected Product(s)Version(s)
Watson IoT Platform1.0




Product(s)Version(s) number and/or range Remediation/Fix/Instructions
Watson IoT Platform1.0Use the guidance under Workaround and Mitigations section.


Workarounds and Mitigations

Application Security in Watson IoT Platform

Applications authenticate to the Watson IoT Platform using API Keys which can be given permission
to carry out a number of different operations. It is, therefore, important to consider a number of
security-related aspects when creating keys.


When you create an IoT Platform API Key you have to assign it a role [1]. It is important to use the
“Principle of Least Privilege” and assign each API key a role that permits only the operations that its
application needs to perform. In this way exposure can be minimised if an application’s credentials
are compromised. Application roles are discussed here:

with more details about the individual roles available here:

By default, API Keys that are created using the IoT User Interface (shown above) are assigned the
”Visualization Application” role. This is the least-privileged of all the pre-defined roles. It gives an
application the ability to view events being sent from devices, but not to send commands to devices.

Dedicated API Keys

Although a single API key can be used by multiple applications, we recommend that you generate a
separate API Key for each application. This means that if an API key is known to have been
compromised, it can be revoked without impacting the other applications.

API Key expiry

When API keys are created (In Apps > Generate API Key) [1], they can be assigned an expiry date.
Giving an API key an expiry ensures that:

1. Credentials for temporary applications do not live longer than are required

2. It ensures that tokens are rotated at appropriate intervals and that old credentials that are
eventually compromised do not act as an attack vector.

We recommend that API keys are created with expiry and that new API keys are generated and
provisioned to applications when the old ones expire. Programmatic APIs are available to allow this
process to be automated. The default expiry time (if expiry is enabled) in the User Interface is 30

Secure storage of the token

In order to ensure the credentials for an application are not leaked, it is important to ensure that
these credentials are stored properly. For example, care should be taken with file permissions and
only copied to systems where necessary. Credentials should not (for example) be embedded in
webpages distributed to multiple users.

Signing and verification of command messages

One use of applications is to send command messages to devices. In many cases, devices rely on the
fact that the IoT Platform has authenticated and authorized the Application that sent the command.
For situations that require a higher degree of security, this can be augmented through the use of
digital signatures.

1) The Application is provisioned with a PKI private key and public key certificate signed by a
Certificate Authority that is trusted by the device firmware. The application uses its private
key to sign the content of the command. The private key can be held by a secure
computing element and this element can also perform the signing operation, to
Minimize the risk of the private key being compromised.

2) With MQTT version 5 it is possible to publish metadata in the form of properties with a
message. These properties can include the signature of the payload and the certificate that
was used for this signature.

3) The Device can then use the signature to verify the contents of the message and
retrieve the identity of the sending application from the Certificate. This allows the
private key used to sign the command messages to be a second factor in the verification of
command messages, in the case that the API key had been compromised.

[1] The creation of API Keys is described as follows:



Get Notified about Future Security Bulletins






This vulnerability was reported to IBM by Md Rabbi Alam

Change History

04 Aug 2023: Initial Publication

*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.


According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

Document Location


[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSQTQM","label":"IBM Watson IoT Platform"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1.0","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]

Document Information

Modified date:
04 August 2023