CVE-2023-22894 is a cleartext storage of sensitive information vulnerability in Strapi Strapi. CISA added it to the Known Exploited Vulnerabilities catalogue on 8 October 2026, which means attackers have used it in real attacks. The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.
What this vulnerability means in practice
Cleartext storage means sensitive information is saved without effective encryption or protection, so anyone who can read the underlying data store, files, logs, or backups may recover it directly. In a web platform, that often turns an application weakness into an immediate data exposure problem, because the attacker does not need to break cryptography, only reach the stored material.
That is why cleartext storage is dangerous in content platforms such as Strapi: once data is written in readable form, compromise of the host, database, export, or backup can expose secrets, tokens, personal data, or administrative material that was assumed to be protected. For vulnerability context and record verification, readers should use the NIST National Vulnerability Database and the CVE Program.
Why stored sensitive data becomes an attack path
The main risk is not just disclosure, but what follows from disclosure. Stored credentials, session material, API keys, and other secret values can let an attacker authenticate elsewhere, expand access, or move laterally after the initial application compromise. A weakness that begins as information exposure can therefore become account takeover or broader environment compromise.
Because this CVE is associated with real-world exploitation, it should be treated as an active exposure rather than a theoretical coding flaw. Where a product or deployment is no longer supported, the safer decision may be to retire it instead of trying to harden an unsafe storage pattern around an obsolete stack.
How organisations assess exposure and scope
Exposure review should start with an asset inventory: identify every Strapi deployment, where it runs, who owns it, and which data stores, backups, exports, and replicas can contain the affected information. Then check whether the application is internet-facing, whether sensitive fields are stored or exported by the platform, and whether any vendor advisory or incident note changes the urgency of remediation.
For CVEs that are being actively exploited, prioritisation should follow exploitable exposure first, then business criticality. The practical question is not only “is the vulnerable version present?” but also “can an attacker reach the data path that stores or mirrors the sensitive material?”
Remediation, detection, and post-exploitation review
Where a supported fix exists, patching or upgrading should be the default response. If patching cannot happen immediately, reduce exposure by removing unnecessary sensitive fields, tightening filesystem and database access, segregating backups, and limiting who can read stored application data. The Vulnerability Management Guide is useful for turning KEV-listed issues into a prioritised remediation workflow.
After containment, review whether sensitive material was already exposed or copied. If the application stored secrets, rotate the impacted credentials, revoke sessions or tokens that may have been recoverable, and inspect logs and exports for evidence of access or exfiltration. If the deployment is end-of-life or end-of-service, migration to a supported platform is part of the fix, not a separate project.
Risk and Threat Considerations
Cleartext storage creates a direct disclosure path that attackers can exploit even without defeating application logic. In an exploited deployment, the stored information may be enough to pivot into adjacent systems, impersonate users or services, or recover additional secret material that was never meant to be visible outside the application.
Failure mechanism: Sensitive values are written to readable storage, then recovered through host compromise, database access, backup theft, log exposure, or administrative access abuse.
Impact: Exposed secrets can enable further authentication abuse, privilege escalation, lateral movement, and broader data compromise beyond the original application.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle protection of stored authenticators and secrets. |
| SC-28 — Protection of Information at Rest | Directly addresses protecting sensitive data stored on systems. | |
| SI-2 — Flaw Remediation | Supports timely remediation of exploitable software weaknesses. | |
| Recommendation — Protect stored authenticators and rotate any credentials exposed by the flaw. Encrypt sensitive data at rest and restrict access to the underlying stores. Prioritise patching and verify remediation for exploited vulnerabilities. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Addresses encryption and protection of sensitive data in storage. |
| CIS-7 — Continuous Vulnerability Management | Supports rapid identification and remediation of KEV-listed exposures. | |
| Recommendation — Apply data protection controls to prevent readable storage of sensitive material. Prioritise scanning, triage, and remediation of actively exploited flaws. | ||
Practitioner Guidance
Why practitioners should care: Treat cleartext storage findings as both a data-handling problem and a compromise-enabling condition. The operational question is whether the stored information would still be safe if the application server, database, backup set, or export were read by an unauthorised party.
What to watch for: Repeated storage of passwords, tokens, API keys, certificates, or recovery material in fields, logs, config snapshots, or exported records usually means the exposure is larger than the original defect description suggests.
Practitioner takeaway: If the platform cannot store the sensitive value safely, remove it from the system design, not just from the user interface.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org