Summary
pupnp contains an integer conversion flaw in HTTP Content-Length parsing that can cause declared body sizes to be truncated or wrapped on some systems. A remote adjacent-network peer may exploit parser disagreement to cause HTTP request desynchronization in persistent or proxied connections, or trigger excessive waiting and denial of service.
pupnp contains an integer conversion flaw in HTTP Content-Length parsing that can cause declared body sizes to be truncated or wrapped on some systems. A remote adjacent-network peer may exploit parser disagreement to cause HTTP request desynchronization in persistent or proxied connections, or trigger excessive waiting and denial of service.
Affected context
The issue occurs in pupnp's HTTP parser when Content-Length values are converted from a wide integer type to a 32-bit signed integer and later stored as an unsigned value. It is most relevant on LP64 systems and in deployments that process persistent connections, proxy traffic, or allow adjacent-network peers to send HTTP requests.
The issue occurs in pupnp's HTTP parser when Content-Length values are converted from a wide integer type to a 32-bit signed integer and later stored as an unsigned value. It is most relevant on LP64 systems and in deployments that process persistent connections, proxy traffic, or allow adjacent-network peers to send HTTP requests.
Exploit preconditions
- Attack surface: Network-accessible UPnP HTTP service or control-point parser
- Required access: Ability to send HTTP requests from an adjacent network
- Trigger point: Parsing an oversized or boundary-value Content-Length header
- Why exploitation is possible: A wide parsed value can be truncated or wrapped during conversion, causing the parser and the sender, proxy, or downstream component to calculate different body boundaries
- Attack surface: Network-accessible UPnP HTTP service or control-point parser
- Required access: Ability to send HTTP requests from an adjacent network
- Trigger point: Parsing an oversized or boundary-value Content-Length header
- Why exploitation is possible: A wide parsed value can be truncated or wrapped during conversion, causing the parser and the sender, proxy, or downstream component to calculate different body boundaries
Why this happens
The parser uses strtol to obtain a wide integer, then casts the result to a 32-bit signed integer before the caller stores it as an unsigned value. Values outside the representable range can therefore lose information or change interpretation. This maps primarily to CWE-190: Integer Overflow or Wraparound and can contribute to CWE-444: Inconsistent Interpretation of HTTP Requests, because different components may disagree about where one request ends and another begins.
The parser uses strtol to obtain a wide integer, then casts the result to a 32-bit signed integer before the caller stores it as an unsigned value. Values outside the representable range can therefore lose information or change interpretation. This maps primarily to CWE-190: Integer Overflow or Wraparound and can contribute to CWE-444: Inconsistent Interpretation of HTTP Requests, because different components may disagree about where one request ends and another begins.
Potential impact
- HTTP request desynchronization in persistent connections
- Request smuggling or unintended interpretation by proxies and back-end services
- Worker threads or processes waiting for an impractically large body
- Denial of service through connection or resource exhaustion
- Unexpected handling of subsequent requests or application data
- HTTP request desynchronization in persistent connections
- Request smuggling or unintended interpretation by proxies and back-end services
- Worker threads or processes waiting for an impractically large body
- Denial of service through connection or resource exhaustion
- Unexpected handling of subsequent requests or application data
General mitigation guidance
Mitigation typically focuses on making length parsing range-safe and ensuring every HTTP component applies the same framing rules.
Common defensive patterns include:
- Parse Content-Length using a type and validation routine that cannot silently narrow or wrap values
- Reject negative, oversized, malformed, or ambiguous length values before storing or using them
- Apply consistent maximum body-size and timeout limits across parsers, proxies, and back-end services
- Prefer secure-by-default HTTP framing behavior that rejects conflicting or inconsistent requests
- Minimize parser privilege and isolate network-facing workers from sensitive resources
- Treat client-supplied length metadata as untrusted until it passes range and policy validation
Mitigation typically focuses on making length parsing range-safe and ensuring every HTTP component applies the same framing rules.
Common defensive patterns include:
- Parse Content-Length using a type and validation routine that cannot silently narrow or wrap values
- Reject negative, oversized, malformed, or ambiguous length values before storing or using them
- Apply consistent maximum body-size and timeout limits across parsers, proxies, and back-end services
- Prefer secure-by-default HTTP framing behavior that rejects conflicting or inconsistent requests
- Minimize parser privilege and isolate network-facing workers from sensitive resources
- Treat client-supplied length metadata as untrusted until it passes range and policy validation
How teams detect issues like this
Organizations can detect related weaknesses through:
- Static analysis for narrowing conversions from
longor other wide types into signed 32-bit integers - Code review of Content-Length parsing, integer casts, range checks, and unsigned conversions
- Tests using boundary values around zero,
INT_MAX,UINT_MAX, and implementation-specific limits - Integration testing through persistent connections and proxy chains to identify framing disagreements
- Network monitoring for malformed or unusually large Content-Length headers and repeated incomplete bodies
- Policy enforcement requiring centralized HTTP parsing and explicit maximum body-size controls
Automated code-review and security-testing tools may help identify suspicious conversion and request-framing patterns.
Organizations can detect related weaknesses through:
- Static analysis for narrowing conversions from
longor other wide types into signed 32-bit integers - Code review of Content-Length parsing, integer casts, range checks, and unsigned conversions
- Tests using boundary values around zero,
INT_MAX,UINT_MAX, and implementation-specific limits - Integration testing through persistent connections and proxy chains to identify framing disagreements
- Network monitoring for malformed or unusually large Content-Length headers and repeated incomplete bodies
- Policy enforcement requiring centralized HTTP parsing and explicit maximum body-size controls
Automated code-review and security-testing tools may help identify suspicious conversion and request-framing patterns.
