Summary
Mongoose's built-in TCP/IP stack does not adequately validate the declared length of certain TCP options before reading their contents. An unauthenticated remote peer may corrupt the per-connection maximum segment size, causing later application data sent through the connection to be truncated or omitted while the connection still appears healthy.
Mongoose's built-in TCP/IP stack does not adequately validate the declared length of certain TCP options before reading their contents. An unauthenticated remote peer may corrupt the per-connection maximum segment size, causing later application data sent through the connection to be truncated or omitted while the connection still appears healthy.
Affected context
The issue occurs in Mongoose deployments that enable the built-in TCP/IP stack through MG_ENABLE_TCPIP and process malformed TCP options. It is associated with the TCP option handling path in src/net_builtin.c, where inconsistent option lengths can cause data to be read beyond the declared options area and influence connection state.
The issue occurs in Mongoose deployments that enable the built-in TCP/IP stack through MG_ENABLE_TCPIP and process malformed TCP options. It is associated with the TCP option handling path in src/net_builtin.c, where inconsistent option lengths can cause data to be read beyond the declared options area and influence connection state.
Exploit preconditions
- Attack surface: Network-facing TCP listener using Mongoose's built-in TCP/IP implementation
- Required access: Ability to establish or send packets to a reachable TCP connection; authentication is not generally required
- Trigger point: Processing of malformed or truncated TCP options
- Why exploitation is possible: The option parser does not sufficiently verify that a declared option length fits within the remaining option bytes, allowing an out-of-bounds option read to corrupt the connection's MSS value
- Attack surface: Network-facing TCP listener using Mongoose's built-in TCP/IP implementation
- Required access: Ability to establish or send packets to a reachable TCP connection; authentication is not generally required
- Trigger point: Processing of malformed or truncated TCP options
- Why exploitation is possible: The option parser does not sufficiently verify that a declared option length fits within the remaining option bytes, allowing an out-of-bounds option read to corrupt the connection's MSS value
Why this happens
The vulnerability results from incomplete bounds validation in TCP option parsing. A declared option length can exceed the bytes remaining in the options area, yet the parser continues reading a field outside that declared region and uses the resulting value to update the connection's maximum segment size. This maps primarily to CWE-20: Improper Input Validation and is also associated with CWE-125: Out-of-bounds Read, because parser logic accesses data beyond the validated input boundary.
The vulnerability results from incomplete bounds validation in TCP option parsing. A declared option length can exceed the bytes remaining in the options area, yet the parser continues reading a field outside that declared region and uses the resulting value to update the connection's maximum segment size. This maps primarily to CWE-20: Improper Input Validation and is also associated with CWE-125: Out-of-bounds Read, because parser logic accesses data beyond the validated input boundary.
Potential impact
- Application payloads may be truncated or reduced to zero length
- Applications may experience a connection-level denial of service
- Protocol-dependent data transfers could become incomplete or unreliable
- Monitoring may incorrectly report healthy connections despite failed application delivery
- Application payloads may be truncated or reduced to zero length
- Applications may experience a connection-level denial of service
- Protocol-dependent data transfers could become incomplete or unreliable
- Monitoring may incorrectly report healthy connections despite failed application delivery
General mitigation guidance
Mitigation generally focuses on making protocol parsing length-aware and treating all network input as untrusted.
Common defensive patterns include:
- Validate every option length against the bytes remaining before reading any option field
- Reject malformed, truncated, or internally inconsistent TCP options
- Use bounded parsing helpers that track offsets and remaining lengths
- Keep outbound payload handling independent of attacker-controlled connection metadata where practical
- Run network services with least privilege and isolate them from sensitive resources
- Add regression tests and fuzzing for malformed protocol headers and option combinations
Secure-by-default parser behavior should fail closed rather than applying partially parsed values.
Mitigation generally focuses on making protocol parsing length-aware and treating all network input as untrusted.
Common defensive patterns include:
- Validate every option length against the bytes remaining before reading any option field
- Reject malformed, truncated, or internally inconsistent TCP options
- Use bounded parsing helpers that track offsets and remaining lengths
- Keep outbound payload handling independent of attacker-controlled connection metadata where practical
- Run network services with least privilege and isolate them from sensitive resources
- Add regression tests and fuzzing for malformed protocol headers and option combinations
Secure-by-default parser behavior should fail closed rather than applying partially parsed values.
How teams detect issues like this
Organizations can detect related flaws through:
- Static analysis rules for unchecked length fields, offset arithmetic, and array accesses in protocol parsers
- Code review checks requiring bounds validation before every variable-length field read
- Fuzz testing with truncated, oversized, and inconsistent TCP option lengths
- Network telemetry identifying repeated malformed TCP options or unusual payload truncation
- CI policy gates requiring parser boundary tests and memory-safety analysis
Automated code review and fuzzing tools can help identify these patterns before deployment.
Organizations can detect related flaws through:
- Static analysis rules for unchecked length fields, offset arithmetic, and array accesses in protocol parsers
- Code review checks requiring bounds validation before every variable-length field read
- Fuzz testing with truncated, oversized, and inconsistent TCP option lengths
- Network telemetry identifying repeated malformed TCP options or unusual payload truncation
- CI policy gates requiring parser boundary tests and memory-safety analysis
Automated code review and fuzzing tools can help identify these patterns before deployment.
