Vmime
Monthly
VMime 0.9.2 and earlier contain an integer underflow in uuEncoder::decode that turns a crafted uuencoded MIME part into a stack-based buffer overflow, letting remote attackers crash a mail-processing application or potentially corrupt memory toward code execution. The trigger is a uuencoded line whose length character is 'b' but which is not a valid 'begin' marker: the marker probe consumes more bytes than the short line accounts for, the remaining-length subtraction wraps to a huge value, and the decode loop then writes past its fixed-size stack buffer. Exploitation requires that the target application feeds untrusted uuencoded content to VMime's decoder and that a victim or their mail software actually processes the message (network-reachable, unauthenticated, requires user interaction); no active exploitation is confirmed (SSVC exploitation: none), EPSS is a modest 0.73% (54th percentile), and while an upstream fix exists in PR/commit form, a public technical writeup exists that is not verified as working exploit code.
Information disclosure in the VMime C++ MIME library through 0.9.2: the uuEncoder::decode routine trusts the line-length byte of a uuencode/x-uuencode part, so a crafted part with an over-long length byte causes uninitialized stack memory to be written into the decoded output - up to 15 bytes of stack contents per over-long line. Affected are applications that use VMime (kisli:vmime, all versions up to and including 0.9.2) to parse attacker-supplied MIME messages; no authentication is required, but the victim must have the crafted message decoded by the application (UI:P in the CVSS 4.0 vector, UI:R in the assessed 3.1 vector), and the leaked bytes are only useful if they are observable in the resulting decoded attachment. There is no CISA KEV entry and EPSS is low (0.25%, 17th percentile), no public exploit code has been confirmed at time of analysis, and the vendor has published a fix upstream (PR #363, commit e85925ed); this is a genuine but low-to-moderate priority flaw rather than an emergency.
VMime 0.9.2 and earlier contain an integer underflow in uuEncoder::decode that turns a crafted uuencoded MIME part into a stack-based buffer overflow, letting remote attackers crash a mail-processing application or potentially corrupt memory toward code execution. The trigger is a uuencoded line whose length character is 'b' but which is not a valid 'begin' marker: the marker probe consumes more bytes than the short line accounts for, the remaining-length subtraction wraps to a huge value, and the decode loop then writes past its fixed-size stack buffer. Exploitation requires that the target application feeds untrusted uuencoded content to VMime's decoder and that a victim or their mail software actually processes the message (network-reachable, unauthenticated, requires user interaction); no active exploitation is confirmed (SSVC exploitation: none), EPSS is a modest 0.73% (54th percentile), and while an upstream fix exists in PR/commit form, a public technical writeup exists that is not verified as working exploit code.
Information disclosure in the VMime C++ MIME library through 0.9.2: the uuEncoder::decode routine trusts the line-length byte of a uuencode/x-uuencode part, so a crafted part with an over-long length byte causes uninitialized stack memory to be written into the decoded output - up to 15 bytes of stack contents per over-long line. Affected are applications that use VMime (kisli:vmime, all versions up to and including 0.9.2) to parse attacker-supplied MIME messages; no authentication is required, but the victim must have the crafted message decoded by the application (UI:P in the CVSS 4.0 vector, UI:R in the assessed 3.1 vector), and the leaked bytes are only useful if they are observable in the resulting decoded attachment. There is no CISA KEV entry and EPSS is low (0.25%, 17th percentile), no public exploit code has been confirmed at time of analysis, and the vendor has published a fix upstream (PR #363, commit e85925ed); this is a genuine but low-to-moderate priority flaw rather than an emergency.