Register | Log in

jetty9

Java servlet engine and webserver

Choose email to subscribe with

general

source: jetty9 (main)
version: 9.4.52-1
maintainer: Debian Java Maintainers (archive) (DMD)
uploaders: Emmanuel Bourg [DMD]
arch: all
std-ver: 4.6.2
VCS: Git (Browse, QA)

versions [more versions can be listed by madison] [old versions available from snapshot.debian.org]

[pool directory]

o-o-stable: 9.4.16-0+deb10u1
o-o-sec: 9.4.16-0+deb10u2
o-o-bpo: 9.4.39-1~bpo10+1
oldstable: 9.4.39-3+deb11u1
old-sec: 9.4.39-3+deb11u1
old-bpo: 9.4.50-1~bpo11+1
stable: 9.4.50-4
testing: 9.4.50-4
unstable: 9.4.52-1

versioned links

9.4.16-0+deb10u1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
9.4.16-0+deb10u2: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
9.4.39-1~bpo10+1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
9.4.39-3+deb11u1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
9.4.50-1~bpo11+1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
9.4.50-4: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
9.4.52-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]

binaries

jetty9 (2 bugs: 0, 2, 0, 0)
libjetty9-extra-java
libjetty9-java

action needed

lintian reports 2 warnings high

Lintian reports 2 warnings about this package. You should make the package lintian clean getting rid of them.

Created: 2023-01-07 Last update: 2023-09-24 11:39

4 security issues in trixie high

There are 4 open security issues in trixie.

4 important issues:

CVE-2023-26048: Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).
CVE-2023-26049: Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `"` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.
CVE-2023-40167: Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.
CVE-2023-41900: Jetty is a Java based web server and servlet engine. Versions 9.4.21 through 9.4.51, 10.0.15, and 11.0.15 are vulnerable to weak authentication. If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. This impacts usages of the jetty-openid which have configured a nested `LoginService` and where that `LoginService` will is capable of rejecting previously authenticated users. Versions 9.4.52, 10.0.16, and 11.0.16 have a patch for this issue.

Created: 2023-09-17 Last update: 2023-09-24 05:38

4 security issues in sid high

There are 4 open security issues in sid.

4 important issues:

CVE-2023-26048: Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).
CVE-2023-26049: Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `"` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.
CVE-2023-40167: Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.
CVE-2023-41900: Jetty is a Java based web server and servlet engine. Versions 9.4.21 through 9.4.51, 10.0.15, and 11.0.15 are vulnerable to weak authentication. If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. This impacts usages of the jetty-openid which have configured a nested `LoginService` and where that `LoginService` will is capable of rejecting previously authenticated users. Versions 9.4.52, 10.0.16, and 11.0.16 have a patch for this issue.

Created: 2023-09-17 Last update: 2023-09-24 05:38

5 security issues in buster high

There are 5 open security issues in buster.

4 important issues:

CVE-2023-26048: Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).
CVE-2023-26049: Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `"` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.
CVE-2023-40167: Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.
CVE-2023-41900: Jetty is a Java based web server and servlet engine. Versions 9.4.21 through 9.4.51, 10.0.15, and 11.0.15 are vulnerable to weak authentication. If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. This impacts usages of the jetty-openid which have configured a nested `LoginService` and where that `LoginService` will is capable of rejecting previously authenticated users. Versions 9.4.52, 10.0.16, and 11.0.16 have a patch for this issue.

1 ignored issue:

CVE-2020-27218: In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request.

Created: 2023-09-17 Last update: 2023-09-24 05:38

4 security issues in bullseye high

There are 4 open security issues in bullseye.

4 important issues:

CVE-2023-26048: Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).
CVE-2023-26049: Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `"` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.
CVE-2023-40167: Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.
CVE-2023-41900: Jetty is a Java based web server and servlet engine. Versions 9.4.21 through 9.4.51, 10.0.15, and 11.0.15 are vulnerable to weak authentication. If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. This impacts usages of the jetty-openid which have configured a nested `LoginService` and where that `LoginService` will is capable of rejecting previously authenticated users. Versions 9.4.52, 10.0.16, and 11.0.16 have a patch for this issue.

Created: 2023-09-17 Last update: 2023-09-24 05:38

4 security issues in bookworm high

There are 4 open security issues in bookworm.

4 important issues:

CVE-2023-26048: Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).
CVE-2023-26049: Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `"` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.
CVE-2023-40167: Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.
CVE-2023-41900: Jetty is a Java based web server and servlet engine. Versions 9.4.21 through 9.4.51, 10.0.15, and 11.0.15 are vulnerable to weak authentication. If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. This impacts usages of the jetty-openid which have configured a nested `LoginService` and where that `LoginService` will is capable of rejecting previously authenticated users. Versions 9.4.52, 10.0.16, and 11.0.16 have a patch for this issue.

Created: 2023-09-17 Last update: 2023-09-24 05:38

debian/patches: 3 patches to forward upstream low

Among the 8 debian patches available in version 9.4.52-1 of the package, we noticed the following issues:

3 patches where the metadata indicates that the patch has not yet been forwarded upstream. You should either forward the patch upstream or update the metadata to document its real status.

Created: 2023-02-26 Last update: 2023-09-24 08:10

testing migrations

excuses:
- Migration status for jetty9 (9.4.50-4 to 9.4.52-1): Waiting for test results or another package, or too young (no action required now - check later)
- Issues preventing migration:
- ∙ ∙ Too young, only 0 of 5 days old
- Additional info:
- ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/j/jetty9.html
- Not considered

news

[2023-09-24] Accepted jetty9 9.4.52-1 (source) into unstable (Markus Koschany)
[2023-06-02] jetty9 9.4.50-4 MIGRATED to testing (Debian testing watch)
[2023-05-27] Accepted jetty9 9.4.51-2 (source) into experimental (Markus Koschany)
[2023-05-27] Accepted jetty9 9.4.50-4 (source) into unstable (Markus Koschany)
[2023-03-29] Accepted jetty9 9.4.51-1 (source) into experimental (sun min) (signed by: Pierre Gruet)
[2023-03-01] jetty9 9.4.50-3 MIGRATED to testing (Debian testing watch)
[2023-02-19] Accepted jetty9 9.4.50-3 (source) into unstable (Markus Koschany)
[2023-01-11] jetty9 9.4.50-2 MIGRATED to testing (Debian testing watch)
[2023-01-06] Accepted jetty9 9.4.50-2 (source) into unstable (Emmanuel Bourg)
[2022-12-21] Accepted jetty9 9.4.50-1~bpo11+1 (source all) into bullseye-backports (Debian FTP Masters) (signed by: Emmanuel Bourg)
[2022-12-03] jetty9 9.4.50-1 MIGRATED to testing (Debian testing watch)
[2022-11-27] Accepted jetty9 9.4.50-1 (source) into unstable (Emmanuel Bourg)
[2022-10-20] jetty9 9.4.49-1.1 MIGRATED to testing (Debian testing watch)
[2022-10-15] Accepted jetty9 9.4.49-1.1 (source) into unstable (Michael Biebl)
[2022-09-28] jetty9 9.4.49-1 MIGRATED to testing (Debian testing watch)
[2022-09-22] Accepted jetty9 9.4.49-1 (source) into unstable (Markus Koschany)
[2022-08-21] Accepted jetty9 9.4.16-0+deb10u2 (source) into oldstable (Markus Koschany)
[2022-08-06] Accepted jetty9 9.4.39-3+deb11u1 (source) into proposed-updates->stable-new, proposed-updates (Debian FTP Masters) (signed by: Markus Koschany)
[2022-08-02] Accepted jetty9 9.4.39-3+deb11u1 (source) into stable-security->embargoed, stable-security (Debian FTP Masters) (signed by: Markus Koschany)
[2022-07-20] jetty9 9.4.48-1 MIGRATED to testing (Debian testing watch)
[2022-07-18] Accepted jetty9 9.4.48-1 (source) into unstable (Markus Koschany)
[2022-05-08] jetty9 9.4.46-1 MIGRATED to testing (Debian testing watch)
[2022-05-02] Accepted jetty9 9.4.46-1 (source) into unstable (Emmanuel Bourg)
[2022-02-16] jetty9 9.4.45-1 MIGRATED to testing (Debian testing watch)
[2022-02-11] Accepted jetty9 9.4.45-1 (source) into unstable (Markus Koschany)
[2021-12-31] jetty9 9.4.44-4 MIGRATED to testing (Debian testing watch)
[2021-12-25] Accepted jetty9 9.4.44-4 (source) into unstable (Markus Koschany)
[2021-11-17] jetty9 9.4.44-3 MIGRATED to testing (Debian testing watch)
[2021-11-12] Accepted jetty9 9.4.44-3 (source) into unstable (Markus Koschany)
[2021-10-23] jetty9 9.4.44-2 MIGRATED to testing (Debian testing watch)

1
2

bugs [bug history graph]

all: 4
RC: 0
I&N: 4
M&W: 0
F&P: 0
patch: 0

links

homepage
lintian (0, 2)
buildd: logs, reproducibility
popcon
browse source code
edit tags
other distros
security tracker
screenshots
debian patches

ubuntu

[Information about Ubuntu for Debian Developers]

version: 9.4.51-2
6 bugs

Debian Package Tracker — Copyright 2013-2018 The Distro Tracker Developers

Report problems to the tracker.debian.org pseudo-package in the Debian BTS.

Documentation — Bugs — Git Repository — Contributing