Is CVE-2023-26369 (Adobe Acrobat and Reader Out-of-Bounds Write) being exploited in the wild?

Yes. CISA added CVE-2023-26369 to its Known Exploited Vulnerabilities catalogue on 14 September 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Adobe Acrobat and Reader contains an out-of-bounds write vulnerability that allows for code execution. Any organisation running the affected product should treat remediation as urgent.

What “exploited in the wild” means for this CVE

A KEV listing means this is no longer a theoretical issue. For CVE-2023-26369, the practical question is not whether the flaw can be weaponised, but whether your estate still contains exposed Acrobat or Reader installations that could be reached before remediation lands. Treat the answer as an operational trigger, not a curiosity.

For teams that track exploitability signals, the right lens is rapid exposure confirmation, not score chasing. Use the CISA Known Exploited Vulnerabilities Catalog as the authoritative exploitation signal, and pair it with your software inventory so you know which endpoints and virtual desktops still run the product.

Adobe’s out-of-bounds write classification matters because memory corruption issues can move quickly from crash to code execution when an attacker can deliver a malicious document or a crafted content path. That is why actively exploited client-side document flaws are often handled as urgent remediation items rather than routine patch cycle work.

How to confirm whether you are exposed

Start with presence, not patch theory. Identify every workstation, VDI image, published app host, and shared workstation that can open PDF files in Adobe Acrobat or Reader, then verify which versions are actually installed on each platform and whether the vulnerable product is the default PDF handler.

If you use central software management, inventory the application in the management console and cross-check against telemetry from endpoints that may have gone dark or are outside normal management coverage. User-installed PDF software and unmanaged laptops are common blind spots in response to document-format vulnerabilities.

Where exposure is uncertain, validate by opening the question through your asset system, EDR, or software catalog rather than relying on user reports. The point is to establish whether the vulnerable reader exists on a system that can receive external documents, because that combination is what turns a product flaw into a practical attack path.

What to do if patching must wait

If you cannot remediate immediately, reduce exposure around the application rather than treating the delay as harmless. Limit the number of users who can launch the affected reader, remove it from high-risk systems where possible, and prefer temporary containment on the most exposed endpoints first.

Inspect controls around inbound documents, especially email attachment handling, browser download flows, shared drives, and automated ingestion paths. Even a short delay in patching becomes much riskier when untrusted PDFs are routinely accepted from outside the organisation.

When there is a delay, monitor for anomalous child processes, unusual crashes, or repeated document-open failures on affected endpoints. Those signals are not proof of compromise, but they help separate a normal software defect from an exploitation attempt that may already be in progress.

Risk and Threat Considerations

Document-reader exploitation is dangerous because the delivery mechanism is ordinary business traffic: email, browser downloads, collaboration tools, and shared storage. A user only has to preview or open a malicious file for the attacker to reach code execution on an endpoint that may already trust the user’s context.

Failure mechanism: A crafted PDF triggers the out-of-bounds write during parsing or rendering, corrupting memory and enabling attacker-controlled execution on the victim system.

Impact: Successful exploitation can lead to endpoint compromise, malware delivery, credential theft, and lateral movement from a user workstation into higher-value internal systems.

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 and NIST SP 800-53 Rev 5 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 fast asset exposure and remediation prioritisation.
Recommendation — Prioritise and remediate KEV-listed software on exposed endpoints first.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	This question hinges on confirming where the vulnerable product exists.
	RS.MA-01 — Incidents are contained	If exploitation is suspected, containment reduces spread before full eradication.
Recommendation — Identify every exposed installation of Acrobat or Reader in the asset inventory. Isolate suspect endpoints and restrict document ingestion paths while investigating.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	KEV-listed exploitation calls for rapid discovery and tracking of vulnerable assets.
	SI-2 — Flaw Remediation	The question is operationally about urgent remediation of an exploited flaw.
Recommendation — Scan for and track vulnerable Acrobat and Reader installations until removed. Apply the vendor fix or approved mitigation as soon as exposure is confirmed.

Practitioner Guidance

What to prioritise: Triage by exposure, not by device count. Systems that routinely open external documents, handle sensitive mail, or have access to shared drives and internal portals should move ahead of low-use endpoints.

What to verify: Confirm that remediation actually removes the vulnerable product state from the asset, not just that a patch ticket was closed. For reader software, version drift and side-by-side installations are common reasons teams think they are safe when they are not.

Decision rule: If an endpoint cannot be patched promptly and it receives untrusted PDFs, treat it as a high-risk exception and apply compensating controls immediately rather than waiting for a maintenance window.

Practitioner takeaway: For a KEV-listed client-side exploit, the real security question is how many reachable endpoints still trust the vulnerable parser, because that determines whether exploitation remains a live path into the estate.