The comment in the product code "ignore secp386 for now" - and the P-384 mTS is turned into a decoration. Heap overflow in TLS-handshake - preauth RCE as root before the first HTTP request. Stack overflow via mDNS - one UDP-package. All this is Mongoose, the embedded C-library, which, according to Cesanta, is spinning on hundreds of millions of Siemens, Schneider Electric, Google, Samsung and Qualcomm. On April 2, 2026, Simone Margaritelli (evilsocket) posted a disclose of three CVE, affecting versions 7.0–7.20. The patch is at 7.21. Let’s understand what’s broken and why on a typical IoT gateway it’s scarier than it looks like via CVSS.
Disclosus - publication, disclosure
Mongoose in the attack chain on the embedded infrastructure
Mongoose - single-floor C-library: HTTP/HTTPS, WebSocket, MQTT, mDSN for embedded systems. Main feature - built-in implementation of TLS 1.3 (MG_TLS_BUILTIN) in order not to drag OpenSSL or mbedTLS on devices where every kilobyte of firmware on the account. Target platforms: MIPS and ARM SoC, FreeRTOS, Zephyr, bare-metal controllers.
In practice, Mongoose is found in IP cameras, SCADA gateways, building management systems, medical devices and automotive infotainment systems. Cesanta claims that the library works even on the ISS. The list of claimed users is industrial giants, but most end operators have no idea which TLS stacks rotate inside the purchased controller.
Three CVE covers several tactics on MITRE ATT&CK:
• Initial Access - Exploit Public-Facing Application (T1190): all three are operated remotely, without authentication, against network services
• Privilege Escalation - Exploitation for Privilege Escalation (T1068): heapflow in CVE-2026-5244 gives the code execution with the rights of the Mongoose process - on the embedded root
• Defense Impassment - Weaken Encryption (T1600): bypass mTS via CVE-2026-5246 completely kills mutual authentication
• Credential Access - Adversary-in-the-Middle (T1557): after bypassing mTLS, the attacker pretends to a legitimate client and gets access to control interfaces
According to Mandiant M-Trends 2025, exploits are the most common vector of initial access: 38% all incidents. IBM X-Force records that 70% Tracing attacks in 2024 affected critical infrastructure - the same segment where Mongoose lives.
Summary CVE
CVSS 4.0 formally gives low ratings - the AC:H (high complexity) for CVE-2026-5245 and CVE-2026-5246, "partial" impact on all three. But the formal score does not take into account the reality of the embedded: the absence of ASLR and the executable heap turn “medium” into root shell in one handishishak. I would look not at CVSS, I would look at the configuration of a particular device.
CVE-2026-5246: mTLS bypass via P-384 - authentication without verification
Mutual TLS is the standard of device-to-device authentication in IoT. Both sides present X.509-certificates signed by the confided CA. The server checks the signature of the client certificate, and only at the valid chain of trust, the client gets access. That's how it works.
In Mongoose is responsible for verification mg_tls_verify_cert_signature() in tls_builtin.c. The problem is the treatment of the P-384 (secp384r1) curve: when a CA certificate uses the P-384 ECDSA key, the function returns 1 (success) without any signature check. Anyway. According to the researcher, the comment in the code: “ignore secp386 for now”“Now Ignored Secp386”. Even the name of the curve with a typo - secp386 instead of secp384.
NVD assigned CVE-2026-5246 CVSS 4.0 rating 2.9 (LOW) with vector AV:N/AC:H/AT/N/NT/N/WI:N/VC:L/V:L/V:L:L. CWE: CWE-285 (Improper Authorization) and CWE-639 (Authorization Bypass Through User-Controlled Key) CISA within SSVC - Track* (Stay, cook patch), marking DC: poc.
What does this mean in practice? If the Mongoose server with mTLS uses the P-384 CA - and this is a reasonable choice, the P-384 gives a 192-bit security against 128-bit P-256 - then any client certificate is accepted. The certificate, molded in five seconds with an arbitrary CA, will pass the "verification". mTLS turns from a protection mechanism into a beautiful scenery.
Predictions and limitations
Works if: Mongoose v7.0–7.20 with MG_TLS_BUILTIN. CA certificate uses P-384 (secp384r1), mTLS enabled. Applicable for the external and internal OT/ICS infrastructure pentest.
Does not work if: The server uses the P-256 CA (signature checks is performed correctly), the external TLS stack (openSSL, mbedTLS) instead of the built-in, or Mongoose 7.21+.
At the recon stage, we define the type of CA curve: connect with an arbitrary self-signed certificate through openssl s_client -cert ... -key .... If the server does not break the TLS-hundishka - with a high probability before us P-384 bypass.
CVE-2026-5244: preauth RCE through heap overflow in TLS-hundishka
The most dangerous of the three consequences. Heap overflow occurs in mg_tls_recv_cert() when processing a client certificate during TLS-hundishka - to Signature checks and to processing of the first HTTP request. Again: to.
NVD: CVE-2026-5244, CVSS 4.0 - 5.5 (MEDIUM), vector AV:N/AC/ACT/AT:N/N/WI:N/VC:L/VC:L/VC. Network vector, low complexity, no privileges, without user interaction. CWE: CWE-119 and CWE-122 (Heap-based Buffer Overflow), and CWE-122 classified MITRE with High.
CISA SSVC: Track, exploitation: none, but automatable: yes - attack is automated on a scale. And here CVSS 5.5 begins to look inadequate.
The Vulnerability Mechanics
When processing a client certificate, the public key is copied to a fixed buffer pubkey within the structure tls_data Size 528 bytes. Length of the key ci->pubkey.len It is taken directly from the DER-performance of the X.509-certificate - is fully controlled by the attackers. There is no border check.
On embedded MIPS-compiled devices with -z execstack (typical configuration - without PIE, without canaries, without RELRO), overflow overwrites the pointer to the function mg_connection->fn. Direct execution of the shell code from root. On MIPS Linux, the kernel installs READ_IMPLIES_EXEC As a Side Effect PT_GNU_STACK RWE - not only stacks, but also a pile becomes executable.
Context of exploitation
Works if: The target device uses MG_TLS_BUILTIN and takes incoming TLS-connections. Embedded MIPS/ARM without ASLR, without PIE, with executable pile - standard IoT configuration. Applicable for external pentest with direct network access to the device.
Does not work if: The target is compiled with a full hardenings (ASLR + PIE + stack canaries + NX heap). Linux x86_64 with glibc and full RELRO operation is much more difficult - you need information leak to bypass the ASLR and ROP chain instead of direct shell code.
It does not depend on CVE-2026-5246: the heap overflow is triggered by a certificate parsing before sign-by-screen verification. MTS bypass is not needed for a trigger - any TLS connection with a crafted certificate is enough. Two bugs are independent ways of operation.
CVE-2026-5245: stack overflow via mDNS - RCE with a single UDP-package
The third vulnerability is in the mDNS records handler, handle_mdns_record(). Four DNS records are packed in stack buffer size 282 bytes without checking the boundaries. One UDP-packet overflows the stack on 386 bytes, re-recording the stored registers and return address.
NVD: CVE-2026-5245, CVSS 4.0 - 2.9 (LOW), vector AV:N/AC:H. CWE: CWE-119 and CWE-121 (Stack-based Buffer Overflow, by MITEpot" High) CISA SSVC: Track, exploitation: none, automatable: no.
In terms of kill chain is the fastest initial access vector: one UDP-package, without a TCP connection, without TLS-hundishka. But practical exploitation is limited.
Works if: mDS is enabled, TXT buffer is more than default size, the MIPS platform with a executable stack. Applicable in the internal pentest when in one broadcast domain with a device.
Does not work if: mDNS is disabled, standard TXT buffer size, platform with NX-glass. UDP-based - will not pass through the NAT or the firewall at an external pentest.
Embedded vs server: where preautth RCE vulnerability Mongose is actually exploited
According to the IBM X-Force Thread Intelligence Index 2025, the average time between CVE posting and elimination 29 months, and this is for server software. For the embedded, the figure is significantly higher: updating the PLC firmware or medical device may require physical access, coordination with a vendor or re-certification (FDA for medical equipment). For a significant part of the installation base, the patch will never reach the device - it will work with this vulnerability before writing off.
Remediation and vulnerability pattern in TLS-implementation Mongoose
Correction and Measuring
Patches for all three CVE - in Mongoose v7.21 (April 1, 2026) Priority recommendations:
1. Upgrading to v7.21 is the main path. For devices with OTA, the priority is critical.
2. Replacement of TLS-sweed - switching with MG_TLS_BUILTINon OpenSSL or mbedTLS eliminates CVE-2026-5244 and CVE-2026-5246. Requires recompilation of the firmware, but removes the chronically problematic component.
3. Disable mDNS - if not in use, deactivation closes CVE-2026-5245.
4. Refusal of P-384 CA - temporary measure: the transition to the P-256 eliminates CVE-2026-5246 without updating the library. Yes, we lose 64 bits of security level - but better working P-256 verification than non-working P-384.
5. Network segmentation - for non-patient devices (legacy PLC, medical equipment) the only real measure - isolation with monitoring of anomalous TLS-handsherks and oversized certificates.
Pattern: TLS in Mongoose as a chronically weak link
Three CVE 2026 is not the first time. In 2024, Nozomi Networks Labs found 10 vulnerabilities in TLS-implementation Mongoose v7.14. Among them CVE-2024-42386 (CVSS 3.1 - 8.2 HIGH, CWE-823: Use of Out-of-range Pointer Offset) and CVE-2024-42384 (CVSS 3.1 - 7.5 HIGH, CWE-190: Integer Overflow). Both allowed to drop the device with a crafted TLS-package.
According to Nozomi Networks, built-in TLS-realization of Mongoose was not integrated in the ticket factory testing, despite the connection to Google OSS-Fuzz. TLS-stack was developed and tested less carefully than other components - despite the fact that it processes the untrusted network input from remote customers. Nozomi wrote their own for harness phasesfing TLS-hundish and found 10 memory corruption in a limited time. Evilsoft after two years later found three more - on the updated version. Pattern is obvious: from v7.14 to v7.20 TLS-implementation of Mongoose systematically contains a memory corruption, and each time external researchers find vulnerabilities, not vendor.
For the pentester, the conclusion is specific: when Mongoose is detected on the target device, the TLS-stovet is the priority surface of the attack. If the device uses MG_TLS_BUILTIN on any version up to 7.21, the probability of an exploited vulnerability is high. I would start with TLS - crafted certificate and oversized key as the first step, even before the port scanning.
Three CVE in Mongoose is a special case of a system problem: lightweight TLS-implementation for embedded is written under conditions of hard resource constraints and is tested a bitter than OpenSSL or BoringSSL. P-384 in Mongoose was ignored literally - with the comment "ignore for now". CVSS 4.0 estimates CVE-2026-5244 as MEDIUM, CVE-2026-5246 as LOW, but on a typical IoT gateway without ASLR and with a septenary of a bunch of “medium” is preauth root shell, and “low” is a complete bypass of mTLS, which was the only access barrier.
But the most unpleasant aspect of this story is not the bugs themselves, but supply chain. Most organizations operating Mongoose devices inside don’t know they’re using Mongoose. Bought a controller from the vendor, mTLS turned on, tick in the fit fit. And for TLS is responsible for the single-file C-library, where the P-384 is missed with the words “then we will do”. Until the industry starts requiring SBOM for firmware with the same level of rigor as for server software, the “ignore for now” in the code will be the norm. And the next disclose will again affect “hundreds of millions of devices” – because no one knew what TLS stack was running on their own equipment. Check your own - strings by firmware and grep mongoose They'll take a minute. The result may be unpleasantly surprising.
Disclosus - publication, disclosure
Mongoose in the attack chain on the embedded infrastructure
Mongoose - single-floor C-library: HTTP/HTTPS, WebSocket, MQTT, mDSN for embedded systems. Main feature - built-in implementation of TLS 1.3 (MG_TLS_BUILTIN) in order not to drag OpenSSL or mbedTLS on devices where every kilobyte of firmware on the account. Target platforms: MIPS and ARM SoC, FreeRTOS, Zephyr, bare-metal controllers.
In practice, Mongoose is found in IP cameras, SCADA gateways, building management systems, medical devices and automotive infotainment systems. Cesanta claims that the library works even on the ISS. The list of claimed users is industrial giants, but most end operators have no idea which TLS stacks rotate inside the purchased controller.
Three CVE covers several tactics on MITRE ATT&CK:
• Initial Access - Exploit Public-Facing Application (T1190): all three are operated remotely, without authentication, against network services
• Privilege Escalation - Exploitation for Privilege Escalation (T1068): heapflow in CVE-2026-5244 gives the code execution with the rights of the Mongoose process - on the embedded root
• Defense Impassment - Weaken Encryption (T1600): bypass mTS via CVE-2026-5246 completely kills mutual authentication
• Credential Access - Adversary-in-the-Middle (T1557): after bypassing mTLS, the attacker pretends to a legitimate client and gets access to control interfaces
According to Mandiant M-Trends 2025, exploits are the most common vector of initial access: 38% all incidents. IBM X-Force records that 70% Tracing attacks in 2024 affected critical infrastructure - the same segment where Mongoose lives.
Summary CVE
CVSS 4.0 formally gives low ratings - the AC:H (high complexity) for CVE-2026-5245 and CVE-2026-5246, "partial" impact on all three. But the formal score does not take into account the reality of the embedded: the absence of ASLR and the executable heap turn “medium” into root shell in one handishishak. I would look not at CVSS, I would look at the configuration of a particular device.
CVE-2026-5246: mTLS bypass via P-384 - authentication without verification
Mutual TLS is the standard of device-to-device authentication in IoT. Both sides present X.509-certificates signed by the confided CA. The server checks the signature of the client certificate, and only at the valid chain of trust, the client gets access. That's how it works.
In Mongoose is responsible for verification mg_tls_verify_cert_signature() in tls_builtin.c. The problem is the treatment of the P-384 (secp384r1) curve: when a CA certificate uses the P-384 ECDSA key, the function returns 1 (success) without any signature check. Anyway. According to the researcher, the comment in the code: “ignore secp386 for now”“Now Ignored Secp386”. Even the name of the curve with a typo - secp386 instead of secp384.
NVD assigned CVE-2026-5246 CVSS 4.0 rating 2.9 (LOW) with vector AV:N/AC:H/AT/N/NT/N/WI:N/VC:L/V:L/V:L:L. CWE: CWE-285 (Improper Authorization) and CWE-639 (Authorization Bypass Through User-Controlled Key) CISA within SSVC - Track* (Stay, cook patch), marking DC: poc.
What does this mean in practice? If the Mongoose server with mTLS uses the P-384 CA - and this is a reasonable choice, the P-384 gives a 192-bit security against 128-bit P-256 - then any client certificate is accepted. The certificate, molded in five seconds with an arbitrary CA, will pass the "verification". mTLS turns from a protection mechanism into a beautiful scenery.
Predictions and limitations
Works if: Mongoose v7.0–7.20 with MG_TLS_BUILTIN. CA certificate uses P-384 (secp384r1), mTLS enabled. Applicable for the external and internal OT/ICS infrastructure pentest.
Does not work if: The server uses the P-256 CA (signature checks is performed correctly), the external TLS stack (openSSL, mbedTLS) instead of the built-in, or Mongoose 7.21+.
At the recon stage, we define the type of CA curve: connect with an arbitrary self-signed certificate through openssl s_client -cert ... -key .... If the server does not break the TLS-hundishka - with a high probability before us P-384 bypass.
CVE-2026-5244: preauth RCE through heap overflow in TLS-hundishka
The most dangerous of the three consequences. Heap overflow occurs in mg_tls_recv_cert() when processing a client certificate during TLS-hundishka - to Signature checks and to processing of the first HTTP request. Again: to.
NVD: CVE-2026-5244, CVSS 4.0 - 5.5 (MEDIUM), vector AV:N/AC/ACT/AT:N/N/WI:N/VC:L/VC:L/VC. Network vector, low complexity, no privileges, without user interaction. CWE: CWE-119 and CWE-122 (Heap-based Buffer Overflow), and CWE-122 classified MITRE with High.
CISA SSVC: Track, exploitation: none, but automatable: yes - attack is automated on a scale. And here CVSS 5.5 begins to look inadequate.
The Vulnerability Mechanics
When processing a client certificate, the public key is copied to a fixed buffer pubkey within the structure tls_data Size 528 bytes. Length of the key ci->pubkey.len It is taken directly from the DER-performance of the X.509-certificate - is fully controlled by the attackers. There is no border check.
RSA key measuring 8192 bits is a module of ~1037 bytes. This 509 bytes outside 528-byte buffer. Overflow rewrites related allocations in a pile.
On embedded MIPS-compiled devices with -z execstack (typical configuration - without PIE, without canaries, without RELRO), overflow overwrites the pointer to the function mg_connection->fn. Direct execution of the shell code from root. On MIPS Linux, the kernel installs READ_IMPLIES_EXEC As a Side Effect PT_GNU_STACK RWE - not only stacks, but also a pile becomes executable.
Context of exploitation
Works if: The target device uses MG_TLS_BUILTIN and takes incoming TLS-connections. Embedded MIPS/ARM without ASLR, without PIE, with executable pile - standard IoT configuration. Applicable for external pentest with direct network access to the device.
Does not work if: The target is compiled with a full hardenings (ASLR + PIE + stack canaries + NX heap). Linux x86_64 with glibc and full RELRO operation is much more difficult - you need information leak to bypass the ASLR and ROP chain instead of direct shell code.
It does not depend on CVE-2026-5246: the heap overflow is triggered by a certificate parsing before sign-by-screen verification. MTS bypass is not needed for a trigger - any TLS connection with a crafted certificate is enough. Two bugs are independent ways of operation.
CVE-2026-5245: stack overflow via mDNS - RCE with a single UDP-package
The third vulnerability is in the mDNS records handler, handle_mdns_record(). Four DNS records are packed in stack buffer size 282 bytes without checking the boundaries. One UDP-packet overflows the stack on 386 bytes, re-recording the stored registers and return address.
NVD: CVE-2026-5245, CVSS 4.0 - 2.9 (LOW), vector AV:N/AC:H. CWE: CWE-119 and CWE-121 (Stack-based Buffer Overflow, by MITEpot" High) CISA SSVC: Track, exploitation: none, automatable: no.
In terms of kill chain is the fastest initial access vector: one UDP-package, without a TCP connection, without TLS-hundishka. But practical exploitation is limited.
Works if: mDS is enabled, TXT buffer is more than default size, the MIPS platform with a executable stack. Applicable in the internal pentest when in one broadcast domain with a device.
Does not work if: mDNS is disabled, standard TXT buffer size, platform with NX-glass. UDP-based - will not pass through the NAT or the firewall at an external pentest.
Embedded vs server: where preautth RCE vulnerability Mongose is actually exploited
According to the IBM X-Force Thread Intelligence Index 2025, the average time between CVE posting and elimination 29 months, and this is for server software. For the embedded, the figure is significantly higher: updating the PLC firmware or medical device may require physical access, coordination with a vendor or re-certification (FDA for medical equipment). For a significant part of the installation base, the patch will never reach the device - it will work with this vulnerability before writing off.
Remediation and vulnerability pattern in TLS-implementation Mongoose
Correction and Measuring
Patches for all three CVE - in Mongoose v7.21 (April 1, 2026) Priority recommendations:
1. Upgrading to v7.21 is the main path. For devices with OTA, the priority is critical.
2. Replacement of TLS-sweed - switching with MG_TLS_BUILTINon OpenSSL or mbedTLS eliminates CVE-2026-5244 and CVE-2026-5246. Requires recompilation of the firmware, but removes the chronically problematic component.
3. Disable mDNS - if not in use, deactivation closes CVE-2026-5245.
4. Refusal of P-384 CA - temporary measure: the transition to the P-256 eliminates CVE-2026-5246 without updating the library. Yes, we lose 64 bits of security level - but better working P-256 verification than non-working P-384.
5. Network segmentation - for non-patient devices (legacy PLC, medical equipment) the only real measure - isolation with monitoring of anomalous TLS-handsherks and oversized certificates.
Pattern: TLS in Mongoose as a chronically weak link
Three CVE 2026 is not the first time. In 2024, Nozomi Networks Labs found 10 vulnerabilities in TLS-implementation Mongoose v7.14. Among them CVE-2024-42386 (CVSS 3.1 - 8.2 HIGH, CWE-823: Use of Out-of-range Pointer Offset) and CVE-2024-42384 (CVSS 3.1 - 7.5 HIGH, CWE-190: Integer Overflow). Both allowed to drop the device with a crafted TLS-package.
According to Nozomi Networks, built-in TLS-realization of Mongoose was not integrated in the ticket factory testing, despite the connection to Google OSS-Fuzz. TLS-stack was developed and tested less carefully than other components - despite the fact that it processes the untrusted network input from remote customers. Nozomi wrote their own for harness phasesfing TLS-hundish and found 10 memory corruption in a limited time. Evilsoft after two years later found three more - on the updated version. Pattern is obvious: from v7.14 to v7.20 TLS-implementation of Mongoose systematically contains a memory corruption, and each time external researchers find vulnerabilities, not vendor.
For the pentester, the conclusion is specific: when Mongoose is detected on the target device, the TLS-stovet is the priority surface of the attack. If the device uses MG_TLS_BUILTIN on any version up to 7.21, the probability of an exploited vulnerability is high. I would start with TLS - crafted certificate and oversized key as the first step, even before the port scanning.
Three CVE in Mongoose is a special case of a system problem: lightweight TLS-implementation for embedded is written under conditions of hard resource constraints and is tested a bitter than OpenSSL or BoringSSL. P-384 in Mongoose was ignored literally - with the comment "ignore for now". CVSS 4.0 estimates CVE-2026-5244 as MEDIUM, CVE-2026-5246 as LOW, but on a typical IoT gateway without ASLR and with a septenary of a bunch of “medium” is preauth root shell, and “low” is a complete bypass of mTLS, which was the only access barrier.
But the most unpleasant aspect of this story is not the bugs themselves, but supply chain. Most organizations operating Mongoose devices inside don’t know they’re using Mongoose. Bought a controller from the vendor, mTLS turned on, tick in the fit fit. And for TLS is responsible for the single-file C-library, where the P-384 is missed with the words “then we will do”. Until the industry starts requiring SBOM for firmware with the same level of rigor as for server software, the “ignore for now” in the code will be the norm. And the next disclose will again affect “hundreds of millions of devices” – because no one knew what TLS stack was running on their own equipment. Check your own - strings by firmware and grep mongoose They'll take a minute. The result may be unpleasantly surprising.
