CVE-2023-38738 is a Medium severity (CVSS 6.8) weakness in IBM OpenPages with Watson 8.3 and 9.0 when Native authentication is used. Someone with database access could take over other accounts. IBM's fix is 8.3.0.2.7 or later, or 9.0.0.1, followed by switching password encryption to PBKDF2.
What's affected
IBM's bulletin lists IBM OpenPages with Watson 8.3 and 9.0 as affected, but only in environments that use Native authentication. Installations that authenticate through LDAP or single sign-on do not store the native passwords in question.
The cause, in IBM's words, is that versions before 8.3.0.2.7 and 9.0.0.1 used a symmetric key encryption algorithm to protect OpenPages user passwords. Symmetric encryption can be reversed by anyone who obtains the key, unlike a one-way hash.
The fixes, per IBM:
- OpenPages 8.3: apply 8.3 FixPack 2 (8.3.0.2), then Interim Fix 1 (8.3.0.2.7) or later, then run the Update Password Encryption Algorithm step to change to PBKDF2.
- OpenPages 9.0: apply 9.0 FixPack 1 (9.0.0.1), then run the same algorithm update step.
- OpenPages 8.0, 8.1 and 8.2: IBM recommends upgrading to a supported fixed version, 8.3 or 9.0.
Note that installing the fix pack alone is not the end. The algorithm change is a separate action that an administrator must run.
How to check if you're exposed
First confirm how your OpenPages instance authenticates users. If it uses LDAP or a single sign-on option, native password storage is not in play, though you should still keep the product patched. If it uses Native authentication, you are in scope.
Next, confirm the product level. The bulletin names 8.3.0.2.7 and 9.0.0.1 as the levels where the stronger option becomes available. Compare your installed level to those.
Finally, check whether the password encryption algorithm has actually been changed. IBM publishes a documentation page on changing the password encryption algorithm to PBKDF2; use it to confirm the setting on your instance. A patched level with the old algorithm still selected is not a finished fix.
What to do now
- Identify OpenPages environments that use Native authentication.
- Apply the fix pack and, for 8.3, the interim fix: 8.3.0.2 then 8.3.0.2.7 or later, or 9.0.0.1 for the 9.0 line.
- Run the Update Password Encryption Algorithm procedure to switch to PBKDF2, following IBM's documentation.
- Where possible, move to LDAP or single sign-on, which IBM lists as a mitigation, and retire Native accounts.
- Restrict and audit direct access to the OpenPages database, since the attacker model requires it, and rotate passwords after the algorithm change.
Why it matters
The record maps this to CWE-257 (storing passwords in a recoverable format). If the stored passwords can be decrypted with a key that the application itself holds, then anyone who copies the database and can obtain or recover that key can read them. A one-way hash such as PBKDF2 removes that option.
The score is 6.8 because the attacker needs low privileges and high complexity (AV:N, AC:H, PR:L), but the confidentiality and integrity impact is rated high. OpenPages is a governance, risk and compliance platform, so a taken-over account may expose audit and risk records. The record does not mark the CVE as exploited, and it is not in the CISA Known Exploited Vulnerabilities catalog. Note that the record's affected list also shows operating system CPEs for Linux and Windows, which only reflect where the product runs.
Quick check
Is applying the fix pack enough?
No. IBM's remediation has two parts: the fix pack or interim fix, then running the step that changes password encryption to PBKDF2.
Which environments are not affected?
IBM scopes the issue to Native authentication. Environments that use LDAP or a single sign-on option are not exposed to this password storage weakness.
Sources
- IBM Security Bulletin: IBM OpenPages Is Vulnerable to Privilege Escalation attack (CVE-2023-38738)
- IBM X-Force entry 262594 (listed in the record; not retrieved)
- Record data for CVE-2023-38738
Last reviewed: 19 October 2026.
