CVE-2024-23449

What it actually does

An uncaught exception in the attachment processor causes the ingest node to crash when an encrypted PDF is submitted via the REST API.

Why it matters to the business

Successful exploitation leads to denial of service against search and indexing functionality, resulting in temporary service disruption; low exploitation likelihood and no known ransomware usage reduce urgency despite broad affected versions.

How an attack unfolds

An attacker crafts a request containing an encrypted PDF and submits it through the public REST API to the attachment processor, triggering an uncaught exception that terminates the ingest node.

How to fix it

Upgrade to Elasticsearch 8.11.1 or later; apply the listed Joomla commit cf2534078e8b47162f5ba4b197ef99230ebe9d81 where the component is integrated through Joomla packages.

How to confirm the fix worked

After upgrade, resubmit an encrypted PDF through the attachment processor endpoint and confirm the ingest node remains stable; review startup logs for the corrected exception handling path.

Typical attack path

1. Locate an exposed Elasticsearch instance running version 8.4.0 to 8.11.0 with the attachment processor enabled
2. Prepare a minimal encrypted PDF file
3. Issue a REST API call that routes the PDF to the attachment processor
4. Observe node crash and service degradation

How to detect it

Inspect Elasticsearch ingest and node logs for uncaught exceptions during PDF parsing; correlate sudden ingest node restarts with attachment processor activity.

What your security team should do

• Prioritize upgrade of all Elasticsearch instances between 8.4.0 and 8.11.0
• Temporarily disable the attachment processor if encrypted PDFs are not required
• Add network-level filtering to block unexpected attachment uploads until patched