You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firstly, thank you for your work on the library. We're currently using test.chuck 0.2.13 and it looks like one of the child dependencies of antq is pulling in an old version of jetty which contains a critical vulnerability. I was wondering if it would be possible to update antq to a more recent version to remove this vulnerability?
Vulnerability details:
In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to an integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request.
Hi,
Firstly, thank you for your work on the library. We're currently using test.chuck 0.2.13 and it looks like one of the child dependencies of antq is pulling in an old version of jetty which contains a critical vulnerability. I was wondering if it would be possible to update antq to a more recent version to remove this vulnerability?
Vulnerability details:
In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to an integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request.
Ref: https://nvd.nist.gov/vuln/detail/CVE-2017-7657
Any help would be much appreciated.
Many Thanks,
Chris
The text was updated successfully, but these errors were encountered: