CVE-2024-23185

What it actually does

Unbounded growth of the full_value buffer in the message-header-parser when processing large or multi-line headers from message chunks, leading to excessive memory consumption without size limits.

Why it matters to the business

Potential memory exhaustion affecting service availability; limited real-world impact due to upstream MTA size restrictions, though self-inflicted disruption remains possible via large message appends. Low urgency given absence from known exploited lists and minimal exploit probability trend.

How an attack unfolds

An attacker crafts an email containing oversized single or folded header lines and delivers it to the system, either directly or by inducing a user to append such a message; the parser accumulates header data without bounds until memory pressure occurs. No named threat actors or public exploits are associated.

How to fix it

Upgrade github.com/usememos/memos (Go) to version 0.9.1 or later. Implement header size restrictions on any MTA or preprocessing component before messages reach the parser. Consider enforcing vsz_limit or similar memory caps as an additional control.

How to confirm the fix worked

Confirm the installed version is at least 0.9.1; test by submitting messages with headers exceeding typical MTA limits and monitoring memory usage during parsing; review configuration for any header restriction policies.

Typical attack path

1. Craft email with extremely large header values or many folded lines
2. Deliver via MTA or direct APPEND operation to the affected component
3. Trigger repeated parsing of the oversized headers to accumulate memory usage
4. Observe resource exhaustion on the backend service

How to detect it

Inspect mail processing logs for entries showing unusually large header accumulation or memory allocation warnings during parsing; correlate with any user-initiated APPEND operations containing oversized content; no specific actor campaigns known.

What your security team should do

• Apply the 0.9.1 update immediately across all instances
• Add upstream MTA header size limits to prevent oversized messages from reaching the parser
• Monitor memory metrics for unexpected spikes during mail ingestion
• Review and tune any vsz_limit settings to contain potential impact