Skip to main content

Security Issues

Apache SeaTunnel Security

If you have apprehensions regarding SeaTunnel’s security or you discover vulnerability or potential threat, don’t hesitate to get in touch with the Apache Security Team by dropping a mail at security@apache.org. In the mail, specify the project name SeaTunnel with the description of the issue or potential threat. You are also urged to recommend the way to reproduce and replicate the issue. The security team and the SeaTunnel community will get back to you after assessing and analysing the findings.

Before using SeaTunnel, please review the usage documentation to ensure you understand the purpose and impact of each operation.

Supported Security Model

Apache SeaTunnel management interfaces are designed for trusted, operator-controlled environments.

seatunnel-web

seatunnel-web delegates user authentication to the surrounding deployment. Once a user is admitted, SeaTunnel treats that user as having full administrative access. seatunnel-web does not provide per-operation authorization checks for third-party SDK calls.

seatunnel-zeta

SeaTunnel Engine management access is administrative access. Any client that can reach a management interface should be treated as a cluster administrator. SeaTunnel does not perform additional authorization checks when those clients submit jobs or interact with connectors, plugins, or third-party SDKs.

  • SeaTunnel management interfaces are not intended to be exposed directly to the public Internet.
  • SeaTunnel does not currently provide role-based access control (RBAC), multi-tenant isolation, or per-user authorization for management operations.
  • SeaTunnel executes user-supplied jobs, connector logic, and plugin code with the privileges of the SeaTunnel process. It does not provide workload sandboxing.
  • If a deployment admits a user or client to a SeaTunnel management interface, that access should be protected like administrator access.

Deployment Recommendations

  • Expose only the management endpoints that you intentionally use.
  • Place SeaTunnel behind a private network, VPN, reverse proxy, ingress policy, or an equivalent access-control layer.
  • Use TLS or mutual TLS when management traffic crosses less-trusted networks.
  • Protect credentials, tokens, and cluster access like administrator credentials.

PLEASE PAY ATTENTION to report the security issue on the security email before disclosing it on public domain.

Frequently Asked Questions

During a security analysis of SeaTunnel, I noticed that SeaTunnel allows for remote code execution, is this an issue?

Apache SeaTunnel is a framework for executing user-supplied code and config in clusters. Users can submit code to SeaTunnel processes, which will be executed unconditionally, without any attempts to limit what code can run. Starting other processes, establishing network connections or accessing and modifying local files is possible.

Historically, we’ve received numerous remote code execution vulnerability reports, which we had to reject, as this is by design.

We strongly discourage users from exposing SeaTunnel processes to the public Internet. Within company networks or cloud accounts, we recommend restricting access to a SeaTunnel cluster via appropriate means.

Does SeaTunnel provide RBAC or fine-grained authorization for management APIs?

No. Once a user or client is admitted to a SeaTunnel management interface, SeaTunnel treats that access as administrative access.

If you need finer-grained access control, enforce it outside of SeaTunnel by using your identity provider, reverse proxy, API gateway, ingress policy, or network segmentation.

Can I expose SeaTunnel management interfaces directly to the public Internet?

No. SeaTunnel management interfaces are intended for trusted operator environments.

Expose them only through private networking or an explicit access-control layer, and use TLS where appropriate.