Yes. CISA added CVE-2023-21492 to its Known Exploited Vulnerabilities catalogue on 19 May 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Samsung mobile devices running Android 11, 12, and 13 contain an insertion of sensitive information into log file vulnerability that allows a privileged, local attacker to conduct an address space layout randomization (ASLR) bypass.
What the KEV listing means for this Samsung flaw
CISA’s KEV catalogue is the practical signal that matters here, because it marks vulnerabilities that defenders should treat as active exploitation risks rather than theoretical issues. For a mobile device flaw, that changes the response from routine backlog management to exposure verification, fast remediation, and a hunt for signs that the affected device or its data was already abused.
For Samsung mobile fleets, the first question is not whether the bug exists in the abstract, but whether any device in scope is still running the affected Android releases and is reachable by a local privileged attacker. That is a device management and exposure problem, so the control point is your asset inventory, patch compliance view, and exception register rather than the CVE record alone.
When a vulnerability is already in KEV, the operational assumption should be that exploitation may already have happened somewhere in the ecosystem. The safer response is to verify exposure on managed devices, prioritise patching through your mobile management workflow, and treat any privileged, locally reachable device as a higher-value endpoint until it is confirmed remediated.
Why sensitive data in logs is more dangerous than it sounds
“Insertion of sensitive information into log file” sounds narrow, but logs are one of the easiest places for an attacker to recover secrets, session material, internal identifiers, or diagnostic details that should never have been recorded. On mobile devices, logs may be easier to collect after device compromise, debugging access, local privilege escalation, or forensic extraction, so the harm is often the disclosure chain that follows the original defect.
Because the reported issue is tied to ASLR bypass, the risk is not just privacy exposure. Security controls that depend on address-space randomization become less effective once an attacker can use the leaked information as a stepping stone toward further local exploitation or post-compromise chaining.
CWE Top 25 Guide is useful background here because log leakage is a classic example of a weakness that turns diagnostics into an attack aid, rather than a standalone incident.
What defenders should do when patching is not immediate
If you cannot remediate every device at once, the practical task is to reduce the chance that the vulnerable logging path can be reached and to reduce the value of anything that might already have been written to disk. That means narrowing device privilege where possible, checking whether developer or diagnostic modes are enabled, and reviewing whether logging, backup, or support tooling could expose the same data more broadly than the handset itself.
Mobile Device Security Guide is relevant because the strongest compensating controls for this class of issue usually sit in mobile device management, enrollment policy, and compliance enforcement, not in the application that triggered the log entry.
If the device is high value, assume that local compromise or physical access can become a disclosure event. Preserve logs for investigation, but restrict who can collect them, and do not keep sensitive diagnostics longer than needed for triage.
Zero-Day and Exploited Vulnerabilities Guide provides the right operational mindset for KEV-class issues: use emergency prioritisation, verify exposure, and then confirm that remediation actually reduced attack surface rather than only changing a version number.
Risk and Threat Considerations
Active exploitation matters because log leakage often becomes an enabler for follow-on access, especially when the disclosed information helps defeat exploit mitigations or reveals environment details an attacker can reuse. For mobile devices, the exposure is concentrated on endpoints that are routinely carried outside the corporate perimeter and may hold data with both personal and enterprise value.
Failure mechanism: A privileged local attacker can trigger or recover sensitive log content, then use the disclosed information to bypass ASLR or to improve the reliability of a subsequent exploit chain.
Impact: The immediate effect is sensitive-data disclosure on the device, but the more serious outcome is that the leaked information can lower the cost of deeper compromise, persistence, or broader device abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed flaws require rapid exposure tracking and remediation prioritisation. |
| Recommendation — Prioritise, verify, and remediate KEV-listed mobile vulnerabilities through continuous asset and patch management. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | KEV exploitation changes how urgently this mobile risk should be treated. |
| Recommendation — Classify KEV-listed mobile devices as elevated risk and escalate remediation accordingly. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The issue requires timely identification, patching, and exception handling for affected devices. |
| Recommendation — Remediate the flaw promptly and track any approved exceptions until closure. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | The vulnerability is about sensitive information being written into logs. |
| Recommendation — Review logging so sensitive data is not recorded or exposed during error handling. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Active exploitation makes vulnerability handling and prioritisation materially relevant. |
| Recommendation — Triage and remediate the vulnerability within your technical vulnerability management process. | ||
Practitioner Guidance
What to verify: Confirm which Samsung Android devices are still in service, whether they fall into the affected operating-system range stated in the advisory, and whether any local administrative or debugging access is enabled on those endpoints. For KEV-listed issues, inventory accuracy matters as much as patch availability.
Decision rule: If the device can hold sensitive enterprise data or connect to production services, treat remediation and exposure review as urgent even when no abuse has been observed yet. If the device is consumer-only and holds no managed data, the operational priority may be lower, but it still needs a normal security fix cycle.
What good looks like: The device is patched, logs no longer contain sensitive material, support teams can justify any remaining exceptions, and investigators can prove whether the endpoint was queried or extracted before remediation.
Practitioner takeaway: For KEV-listed mobile flaws, the real question is not whether exploitation is possible, but whether your fleet can prove it was not already exposed and whether the logging path was ever allowed to carry data that attackers could reuse.
Related resources from NHI Mgmt Group
- CVE-2023-21492 (Samsung Mobile Devices Insertion of Sensitive Information Into Log File)
- Is CVE-2025-21043 (Samsung Mobile Devices Out-of-Bounds Write) being exploited in the wild?
- Is CVE-2021-25394 (Samsung Mobile Devices Race Condition) being exploited in the wild?
- Is CVE-2023-35081 (Ivanti Endpoint Manager Mobile (EPMM) Path Traversal) being exploited in the wild?