Yes. CISA added CVE-2021-25487 to its Known Exploited Vulnerabilities catalogue on 29 June 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 contain an out-of-bounds read vulnerability within the modem interface driver due to a lack of boundary checking of a buffer in set_skb_priv(), leading to remote code execution by dereference of an invalid function pointer.
What the KEV listing means for this Samsung mobile flaw
CISA’s KEV catalogue is the practical signal that matters here, because it reflects evidence of active exploitation rather than a theoretical risk. For a mobile-device flaw like CVE-2021-25487, that means defenders should treat exposure as real until proven otherwise, and use the vendor advisory plus KEV entry to confirm whether any enrolled device builds remain in scope.
For teams that manage fleets rather than individual phones, the first question is not whether the weakness exists in the abstract, but whether any supported or unsupported Samsung device is still reachable, remotely manageable, or outside patch policy. A KEV-listed vulnerability should be handled as an exposure management issue, not a routine backlog item, especially when the affected surface sits in a low-visibility component such as a modem interface driver.
If you need a broader process view for this kind of response, Zero-Day and Exploited Vulnerabilities Guide is the most directly useful internal playbook for triage, emergency mitigation, and post-patch validation.
Why an out-of-bounds read in a modem driver is operationally serious
An out-of-bounds read in a low-level driver is not just a crash concern. When boundary checking is missing in code that processes external input, the result can be memory disclosure, control-flow corruption, or a path to remote code execution depending on the exact execution context and surrounding mitigations. On mobile devices, that is especially sensitive because the modem stack sits close to the trust boundary for radio-facing input.
Samsung’s mobile ecosystem also raises the usual lifecycle problem: fleets are unevenly patched, carriers and regions do not always align on update timing, and some devices remain in service long after mainstream attention has moved on. That makes exploitation most attractive where patch cadence is weak, device inventory is incomplete, or users are allowed to defer updates indefinitely.
For a control-oriented reference point, Mobile Device Security Guide helps connect the vulnerability to device enrollment, compliance, and fleet-level remediation.
What to verify before you assume a device is safe
Start with device inventory and version confirmation, then validate whether any Samsung devices are still receiving security updates. If you cannot prove patch status from management tooling, treat the device as exposed until you can. For mobile vulnerabilities, the practical failure is often not the exploit itself but the gap between “we have a patch available” and “we know the fleet is actually on the patched state.”
That verification should include remote management reachability, whether the device is enrolled in MDM, and whether users can sideload or delay updates outside policy. If the organization supports bring-your-own-device access, the question becomes whether sensitive corporate access is still allowed from a device whose patch state is unknown.
Where you need a framework for the vulnerability itself, NIST National Vulnerability Database is useful for canonical record lookup, while CVE Program remains the authoritative reference for the identifier and record structure.
Risk and Threat Considerations
KEV inclusion means the vulnerability is not hypothetical, so the threat model should assume real-world interest from attackers who target mobile devices for stealthy access, data theft, or follow-on compromise. A modem-interface bug is particularly concerning because exploitation may occur before a user notices anything obvious, and mobile platforms often have weaker endpoint telemetry than traditional desktops.
Failure mechanism: Missing boundary checking in set_skb_priv() can allow malformed input to drive an invalid function-pointer dereference, which can turn a read bug into code execution or another security-relevant memory corruption path depending on exploitability and platform protections.
Impact: Successful exploitation can expose device memory, undermine device trust, and provide an attacker with a foothold on a phone that may contain email, messaging, authentication apps, corporate profiles, and tokens used for downstream access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | Device inventory is essential for finding exposed Samsung phones. |
| PR.PS-01 — Configurations and inventories are managed and maintained | Patch state and managed configuration determine exposure to the flaw. | |
| Recommendation — Maintain an accurate mobile device inventory and map every Samsung model to patch status. Enforce managed mobile configurations and verify update compliance continuously. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | You cannot scope exploited mobile exposure without asset inventory. |
| CIS-7 — Continuous Vulnerability Management | KEV-listed exploitation demands rapid identification and remediation. | |
| Recommendation — Track all Samsung endpoints and remove unknown or unmanaged devices from trust. Prioritise remediation for KEV-listed mobile vulnerabilities and confirm completion. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Organizations need scanning and tracking to identify vulnerable devices. |
| Recommendation — Scan mobile estates and verify remediation for the exposed Samsung flaw. | ||
Practitioner Guidance
What to prioritise: If a Samsung device is internet-reachable, user-managed, or used for corporate access, prioritise patch verification and access restriction before deeper forensic work. Devices with unknown update state should be treated as higher priority than devices that are simply “old,” because exploitability, not age, is the operational decision point.
What to verify: Confirm whether the fleet can produce a current patch-level report, whether vulnerable models are still enrolled, and whether any high-risk users can bypass mobile compliance checks. If a device cannot be confidently attested, do not rely on its apparent normal behavior as evidence of safety.
Decision rule: If patching is delayed, reduce exposure by limiting sensitive access from the device, forcing re-enrollment where appropriate, and increasing monitoring for unusual account activity that could indicate prior compromise. If the device is business-critical and cannot be removed immediately, treat the situation as a temporary exception with explicit expiry and ownership.
Practitioner takeaway: For exploited mobile vulnerabilities, the practical question is not whether the flaw is interesting, but whether you can prove the fleet is no longer reachable through it, and whether any credential-bearing apps on those devices would make compromise materially worse.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2021-25487 (Samsung Mobile Devices Out-of-Bounds Read)?
- CVE-2021-25487 (Samsung Mobile Devices Out-of-Bounds Read)
- Is CVE-2025-21043 (Samsung Mobile Devices Out-of-Bounds Write) being exploited in the wild?
- Is CVE-2025-21042 (Samsung Mobile Devices Out-of-Bounds Write) being exploited in the wild?