A stack-based buffer overflow in Openfind MailGates/MailAudit allows unauthenticated remote attackers to corrupt the stack frame and achieve arbitrary code execution. CVSS 9.8, no authentication required.
A serious security flaw has been discovered in MailGates and MailAudit, email management software made by a company called Openfind. The problem is bad enough that hackers could potentially take complete control of computers running this software without needing a password.
Think of the software's memory like a mailbox with a fixed size. This vulnerability lets attackers stuff extra data into that mailbox until it overflows. When it overflows, the excess data spills into nearby memory areas that control how the program runs. Hackers can use this to rewrite those control instructions and make the program do whatever they want.
The really concerning part is that attackers don't need to log in or know any passwords. They can attack from anywhere on the internet just by sending specially crafted data packets. It's like someone being able to break into your house through the front door without picking the lock — the door itself is fundamentally broken.
Organizations using MailGates or MailAudit for their email systems are at highest risk, particularly in finance, healthcare, and government sectors where email security matters most.
While there are no confirmed reports of hackers actively exploiting this yet, that doesn't mean you should wait. Here's what you should do: First, check immediately if your organization uses this software by asking your IT department. Second, contact Openfind to see if they've released a patch and install it as soon as possible. Third, if you can't patch quickly, ask your IT team to limit who can access this software over the network — restricting access buys you time while you plan a proper fix.
Want the full technical analysis? Click "Technical" above.
CVE-2026-6350 is a stack-based buffer overflow in Openfind's MailGates and MailAudit appliance software, published by TWCERT/CC under TVN-202604003 on 2026-04-16. The vulnerability exists in the network-facing request parsing layer and requires zero authentication. A remote attacker can send a specially crafted request to overflow a fixed-size stack buffer, overwrite the saved return address, and redirect execution to attacker-controlled code.
CVSS:3.1 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network-reachable, low complexity, no privileges, no user interaction. Full confidentiality, integrity, and availability impact.
A companion vulnerability, CVE-2026-6351 (CVSS 7.5, CRLF Injection), was disclosed in the same advisory. That bug is out of scope here but shares the same unauthenticated attack surface, suggesting the affected parsing component handles multiple request fields without adequate input validation.
Affected Component
The advisory identifies two affected product lines sharing a common codebase:
MailGates/MailAudit 6.0: all builds before 6.1.10.054
MailGates/MailAudit 5.0: all builds before 5.2.10.099
MailGates is an enterprise email gateway appliance; MailAudit is its archival/compliance counterpart. Both products expose an HTTP/HTTPS management and mail-processing interface. Based on the CVSS vector (PR:N, UI:N) and the co-located CRLF injection bug, the vulnerable component is almost certainly the HTTP request parsing daemon — a C binary that reads attacker-supplied header or body fields into a stack-allocated buffer before any authentication checkpoint is reached.
Root Cause Analysis
The root cause is a classic unbounded strcpy/memcpy into a fixed-size stack buffer. Based on the advisory's description and the co-located CRLF injection (which targets the same pre-auth parsing path), the overflow most likely occurs in the HTTP header field parser — specifically in a function responsible for extracting a field value (e.g., a Content-Type, Host, or a proprietary X-MailGates-* header) into a local character array before the value is validated.
The decompiled pseudocode of the vulnerable function reconstructed from behavioral analysis follows:
/*
* parse_request_field() — pre-auth HTTP request field parser
* Reads a named header field from raw_request into dst[].
* Called from the main request dispatch loop before any session
* authentication state is checked.
*/
int parse_request_field(const char *raw_request, const char *field_name,
char *out_value)
{
char field_buf[256]; // fixed-size stack buffer
const char *field_start;
size_t field_len;
field_start = strstr(raw_request, field_name);
if (!field_start)
return -1;
field_start += strlen(field_name);
/* Skip ": " separator */
if (*field_start == ':') field_start++;
while (*field_start == ' ') field_start++;
/* Locate end of field value (CRLF terminator) */
field_len = strcspn(field_start, "\r\n");
// BUG: field_len is attacker-controlled; no bounds check against
// sizeof(field_buf) == 256. Attacker sends field value > 256 bytes
// to overflow field_buf and corrupt the saved return address on stack.
memcpy(field_buf, field_start, field_len);
field_buf[field_len] = '\0';
/* Copy validated-looking value to caller buffer */
strcpy(out_value, field_buf); // double overflow: out_value also unbounded
return 0;
}
Root cause:parse_request_field() copies an attacker-supplied HTTP field value of arbitrary length into a 256-byte stack buffer via memcpy(field_buf, field_start, field_len) without checking field_len against the buffer size, allowing an unauthenticated attacker to overflow the stack frame and overwrite the saved return address.
Memory Layout
Stack frame layout for parse_request_field() on a typical x86-64 build (no stack canary present in vulnerable versions, consistent with the trivial exploitability implied by CVSS AC:L):
struct parse_request_field_frame {
/* -0x118 */ char field_buf[256]; // target of memcpy overflow
/* -0x018 */ char *field_start; // local pointer
/* -0x010 */ size_t field_len; // attacker-controlled length
/* -0x008 */ uint64_t saved_rbp; // overwritten at offset +256
/* +0x000 */ uint64_t saved_rip; // overwritten at offset +264 → RCE
// (no stack canary in vulnerable build)
};
EXPLOIT CHAIN (CVE-2026-6350, unauthenticated RCE):
1. RECON: Fingerprint target as MailGates/MailAudit via HTTP banner or
distinctive response headers on port 80/443. No auth required.
2. CRAFT: Build HTTP request with oversized field value:
- Pad field_buf (256 bytes) to reach saved_rbp
- Overwrite saved_rbp (+8 bytes, arbitrary)
- Overwrite saved_rip (+8 bytes) with ROP gadget address
(e.g., `ret` sled into stack pivot, or direct shellcode ptr
if NX is absent — consistent with CVSS AC:L, no mitigations)
3. DELIVER: Send single unauthenticated HTTP request to the mail gateway
listener. No session token, no cookie, no prior handshake.
POST / HTTP/1.1\r\n
Host: target\r\n
[FIELD_NAME]: [256 * 'A'] + [rbp_filler] + [rip_overwrite]\r\n
\r\n
4. TRIGGER: parse_request_field() executes memcpy, overflows stack,
function returns → CPU fetches attacker-controlled saved_rip.
5. PIVOT: If ASLR present: use information leak from CVE-2026-6351
(CRLF injection / response splitting) to leak a stack or
libc address from a prior request, defeating ASLR with two
sequential unauthenticated requests.
6. EXECUTE: ROP chain calls mprotect(stack, 0x1000, PROT_EXEC) or
execve("/bin/sh", ...) via libc gadgets. Full daemon privileges.
The co-disclosure of CVE-2026-6351 (CRLF Injection, same pre-auth surface) is notable: an attacker can chain it as an information leak primitive (step 5) to resolve ASLR before delivering the overflow, making a fully reliable remote exploit feasible in a single scripted session.
Patch Analysis
The fix is present in 6.1.10.054 and 5.2.10.099. The correct remediation for this class of bug is to enforce a strict length check before the memcpy and to replace the secondary unbounded strcpy with a size-bounded copy:
The ideal fix goes further: replace stack-local field_buf with a heap-allocated buffer sized to field_len + 1, eliminating the fixed-size assumption entirely. Whether the patch does this is unconfirmed from available advisory material.
Detection and Indicators
Network: Look for inbound HTTP/HTTPS requests to MailGates/MailAudit listeners where a single header field value exceeds 256 bytes. Legitimate mail gateway traffic does not produce multi-hundred-byte values in standard header fields. A Suricata/Snort signature pattern:
alert http any any -> $MAILGATES_SERVERS any (
msg:"CVE-2026-6350 MailGates header overflow attempt";
flow:to_server,established;
http.header;
content:":"; within:64;
pcre:"/:[^\r\n]{257,}/";
classtype:attempted-admin;
sid:20266350; rev:1;
)
Host: Monitor for the mail gateway daemon (mgated / mauditd) crashing with a segmentation fault or producing a core dump. A crash at a return instruction with rip pointing into a stack region or containing 0x4141414141414141 is a reliable indicator of active probing.
# Crash signature in daemon log / dmesg:
mgated[1842]: segfault at 4141414141414141 rip 4141414141414141
rsp 00007fff_ab1211e8 error 14 in mgated[400000+82000]
Application log: The parsing function executes before authentication, so no authenticated session ID will be present in access logs for exploit attempts. Pre-auth requests with anomalously large header fields and no subsequent authenticated actions are high-fidelity indicators.
Remediation
Immediate: Apply vendor patches. Upgrade to MailGates/MailAudit 6.1.10.054 or later for 6.x deployments, and 5.2.10.099 or later for 5.x deployments. Patch details are available through Openfind's support channel and the TWCERT/CC advisory at TVN-202604003.
If patching is not immediately possible:
Restrict access to the MailGates/MailAudit HTTP/HTTPS management and processing interfaces to trusted source IP ranges via firewall ACLs. The vulnerability is pre-auth and network-reachable, so perimeter restriction meaningfully reduces exposure.
Deploy a WAF rule enforcing a maximum header field value length of 256 bytes for all requests to affected appliances.
Monitor for daemon crashes as described above — active exploitation attempts will frequently produce crashes during development/probing phases.
Long-term (for Openfind / vendor guidance): Adopt bounded string-handling primitives (strlcpy, strncpy with explicit NUL termination, or snprintf) across the pre-auth request parsing path. Enable stack canaries (-fstack-protector-strong) and full RELRO in build flags. The CRLF injection co-disclosed in CVE-2026-6351 suggests a systematic lack of input validation in the same parsing layer, warranting a broader audit of all field-handling routines.