[Improve][Zeta] Upgrade embedded Jetty and disable server version disclosure
- Dominant language
- Java
- Stars
- 9.7k
- Forks
- 2.4k
- Avg merge
- 3d 9h
- Merged PRs (30d)
- 204
Description
### What happened?
The latest `dev` branch still pins Eclipse Jetty `9.4.56.v20240826`:
- `seatunnel.shade.jetty.version`: `9.4.56.v20240826`
- `jetty.version`: `9.4.56.v20240826`
At commit `1ff72ceb3d2a823a0fca64ec009984d75e846c28`, `JettyService` also creates the HTTP connector using the default configuration:
```java
ServerConnector httpConnector = new ServerConnector(server);
```
Jetty therefore sends its exact version in every response by default:
```http
Server: Jetty(9.4.56.v20240826)
```
This exposes implementation details and causes version-based vulnerability scanners to report the following public advisories:
- CVE-2025-5115 / GHSA-mmxm-8w33-wc4h
- CVE-2024-6763 / GHSA-qh8g-58pp-2wxh
I searched the repository and existing issues/PRs, but did not find a change covering either advisory or `setSendServerVersion(false)`.
### Affected versions
- SeaTunnel 2.3.12
- SeaTunnel 2.3.13
- Latest `dev` as of 2026-08-28, commit `1ff72ceb3d2a823a0fca64ec009984d75e846c28`
### Security context
This issue does not claim that both CVEs are exploitable in every SeaTunnel deployment:
- CVE-2025-5115 requires HTTP/2. The current SeaTunnel `JettyService` creates a default HTTP/1.1 connector, so a standard deployment may not expose the vulnerable HTTP/2 path.
- CVE-2024-6763 primarily affects applications that directly use Jetty `HttpURI` to validate attacker-controlled URLs. Jetty's normal server-side use of the class is not itself vulnerable according to the upstream advisory.
However, the affected Jetty classes are embedded in the shaded SeaTunnel starter JAR, the exact vulnerable version is disclosed remotely, and there is currently no supported configuration to suppress the header.
### Expected behavior
1. Upgrade or backport the embedded Jetty security fixes.
2. Do not disclose the exact Jetty version in HTTP responses by default.
3. Add a configuration option if retaining the current behavior is required for compatibility.
4. Add a test asserting that REST responses do not contain an exact Jetty version.
For the HTTP connector, the header can be disabled with an explicit `HttpConfiguration`:
```java
HttpConfiguration httpConfig = new HttpConfiguration();
httpConfig.setSendServerVersion(false);
ServerConnector httpConnector =
new ServerConnector(server, new HttpConnectionFactory(httpConfig));
```
The HTTPS connector should use the same response-header policy.
### Upstream references
- https://github.com/jetty/jetty.project/security/advisories/GHSA-mmxm-8w33-wc4h
- https://github.com/jetty/jetty.project/security/advisories/GHSA-qh8g-58pp-2wxh
- https://github.com/apache/seatunnel/blob/1ff72ceb3d2a823a0fca64ec009984d75e846c28/pom.xml#L73
- https://github.com/apache/seatunnel/blob/1ff72ceb3d2a823a0fca64ec009984d75e846c28/pom.xml#L164
- https://github.com/apache/seatunnel/blob/1ff72ceb3d2a823a0fca64ec009984d75e846c28/seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/JettyService.java#L118
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.