Is CVE-2019-3568 (WhatsApp VOIP Stack Buffer Overflow) being exploited in the wild?

Yes. CISA added CVE-2019-3568 to its Known Exploited Vulnerabilities catalogue on 19 April 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. A buffer overflow vulnerability in WhatsApp VOIP stack allowed remote code execution via specially crafted series of RTCP packets sent to a target phone number.

What “Exploited in the Wild” Means for CVE-2019-3568

For a vulnerability like CVE-2019-3568, “exploited in the wild” is not a theoretical label, it means defenders should treat it as an active exposure with real-world attack value. In practice, that shifts the question from curiosity to urgency: confirm whether the vulnerable product is present, whether exposure is still possible, and whether evidence of prior compromise exists.

A useful reference point is CISA’s CISA Known Exploited Vulnerabilities Catalog, which is intended for vulnerabilities with confirmed active exploitation. For CVE triage, the catalog is a stronger signal than generic severity scoring because it reflects observed abuse, not just potential impact.

When the flaw is an overflow in a communications stack, the operational concern is usually remote execution or crash conditions that can be triggered with crafted network traffic. That means exposure can exist even when users have no obvious reason to suspect risk, especially if the affected service is reachable and the target cannot easily distinguish malicious packets from ordinary protocol handling.

How Practitioners Should Confirm Exposure and Reduce Risk

Start with asset confirmation: identify where the affected application or embedded stack is present, whether it is internet-reachable, and whether it is still supported by the vendor’s current security guidance. For active exploitation questions, the key decision is not just “is the version installed?” but “can this attack path still be reached in the environment today?”

For prioritized vulnerability handling, NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is the most relevant internal starting point because it addresses KEV-style triage, emergency mitigation, hotpatching, and post-patch hunting. That is the right operational frame when exploitation is already a live concern.

If patching or vendor remediation must wait, reduce exposure by removing reachability, tightening network paths, and applying any vendor-endorsed workaround or mitigation that materially blocks the exploit path. For a remotely triggerable stack overflow, compensating controls matter most when they reduce the chance that hostile traffic can reach the vulnerable code path at all.

What to Check After a Likely Exploitation Window

When a vulnerability is known to be exploited, the job is not finished after remediation. You should also look for evidence that the endpoint or service was used before the fix, including unexpected crashes, process anomalies, unexplained restarts, unusual outbound connections, or signs that a remote code execution attempt succeeded.

That is why post-remediation validation should include compromise assessment, not just patch confirmation. If the vulnerable component could have exposed account material, sessions, or adjacent application data, you should also consider whether related credentials, tokens, or service access need rotation, even if the exact exploit path did not directly steal them.

For exploitation research and naming hygiene, the CVE Program and NIST National Vulnerability Database remain the authoritative places to verify the record, its identifiers, and any linked metadata. Use those sources alongside vendor guidance rather than relying on secondary summaries alone.

Risk and Threat Considerations

Actively exploited buffer overflows are especially dangerous because they can convert a parser bug into remote execution, denial of service, or device takeover without needing user interaction. In mobile and messaging contexts, that can create fast-moving exposure because the vulnerable code may process attacker-controlled traffic before the user has any visible warning.

Failure mechanism: The attacker sends crafted packets or malformed input that overrun memory in the vulnerable stack, potentially altering control flow or crashing the process before normal validation can stop it.

Impact: Successful exploitation can produce code execution, device compromise, service disruption, or a foothold for follow-on abuse, which is why confirmed exploitation should be treated as a priority response event rather than a routine patch item.

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 SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Exploited CVEs require prioritized vulnerability handling and validation.
Recommendation — Prioritise KEV-listed flaws for rapid remediation and verification.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The answer depends on confirming exposure and tracking exploited vulnerabilities.
	SI-2 — Flaw Remediation	Active exploitation makes timely flaw remediation a core control concern.
Recommendation — Track exposed assets and verify remediation for exploited weaknesses. Patch or mitigate the flaw and document the remediation outcome.
NIST CSF 2.0	DE.CM-08 — Vulnerability Scans Are Performed	The response requires exposure confirmation and ongoing vulnerability monitoring.
Recommendation — Continuously scan for exposed vulnerable assets and confirm closure.
OWASP ASVS	V15 — Secure Coding and Architecture	Buffer overflow exploitation is a memory-safety and architecture concern.
Recommendation — Eliminate unsafe memory handling patterns that enable overflows.

Practitioner Guidance

What to prioritise: Treat KEV-listed vulnerabilities as an exposure-management problem first and a patch-management problem second. Confirm whether the vulnerable service is actually reachable, because internet exposure and broad trust boundaries materially increase the chance of live exploitation.

What to verify: Validate both remediation and aftermath. A clean version state does not rule out pre-patch compromise, so pair fix verification with log review, process review, and a focused hunt for abnormal behaviour during the exposure window.

Practitioner takeaway: For a vulnerability already added to KEV, the right question is not whether exploitation is possible, but whether the exploit path is still open and whether the environment has already been touched.