You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@inlong.apache.org by Geo via dev <de...@inlong.apache.org> on 2026/05/28 01:36:30 UTC
[InLong] Authenticated SSRF via POST /api/node/testConnection
Hi team,
I've gone through https://inlong.apache.org/docs/next/security/ and I
believe the below finding is valid and thus I'm reporting:
I've found a SSRF vulnerability in Apache InLong Manager affecting the
`POST /api/node/testConnection` REST endpoint.
Summary: Any authenticated user (no admin role required) can cause the
InLong Manager server to make outbound HTTP requests or TCP connections to
arbitrary internal hosts and ports, including cloud instance metadata
services. This is confirmed on inlong/manager:latest (v2.4.0-SNAPSHOT,
commit 965f9da3).
Affected component: inlong-manager, DataNodeController.java /
DataNodeServiceImpl.java
Affected versions: at minimum v2.4.0-SNAPSHOT; earlier stable releases also
affected based on code history
CWE: CWE-918
CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N = 7.7 High
Root cause: The testConnection endpoint has no @RequiresRoles annotation
(any logged-in session is sufficient). The URL validation in
UrlVerificationUtils checks only port range and host:port format, with no
allowlist or private-IP denylist. Each operator (Elasticsearch, Pulsar,
MySQL, ClickHouse, Hive, etc.) issues live network connections to the
caller-supplied URL without SSRF-safe HTTP client configuration.
Live-validated PoC summary:
1. Login as a regular user (account_type=1, no admin role).
2. POST /inlong/manager/api/node/testConnection with type=ELASTICSEARCH,
url=http://169.254.169.254/latest/meta-data/
3. Server returns: "elasticsearch connection failed for url=
http://169.254.169.254/latest/meta-data/, username=, password=" --
confirming the server made an outbound request to the AWS metadata endpoint.
4. Repeat with type=PULSAR, adminUrl=http://10.0.0.1:8080 -- server returns
"Pulsar connection failed for AdminUrl=http://10.0.0.1:8080".
5. Repeat with type=MYSQL, url=127.0.0.1:3306 -- server returns "mysql
connection failed for jdbcUrl=jdbc:mysql://127.0.0.1:3306".
Recommended fix:
1. Add @RequiresRoles to testConnection consistent with other data node
management operations.
2. Extend UrlVerificationUtils to deny link-local, loopback, and RFC 1918
address ranges.
3. Configure RestTemplate instances used by HTTP-based operators to reject
SSRF-prone targets before connecting.
For your review and coordinated disclosure,
Geo
Re: [InLong] Authenticated SSRF via POST /api/node/testConnection
Posted by Charles Zhang <do...@apache.org>.
CVE-2026-63044 was allocated to track this issue.
On 2026/05/28 08:06:38 付文凯 wrote:
> Thank you. We have addressed this issue in the PR mentioned above:
> https://github.com/apache/inlong/pull/12116
>
> Geo via dev <de...@inlong.apache.org> 于2026年5月28日周四 10:52写道：
>
> > Hi team,
> >
> > I've gone through https://inlong.apache.org/docs/next/security/ and I
> > believe the below finding is valid and thus I'm reporting:
> >
> > I've found a SSRF vulnerability in Apache InLong Manager affecting the
> > `POST /api/node/testConnection` REST endpoint.
> >
> > Summary: Any authenticated user (no admin role required) can cause the
> > InLong Manager server to make outbound HTTP requests or TCP connections to
> > arbitrary internal hosts and ports, including cloud instance metadata
> > services. This is confirmed on inlong/manager:latest (v2.4.0-SNAPSHOT,
> > commit 965f9da3).
> >
> > Affected component: inlong-manager, DataNodeController.java /
> > DataNodeServiceImpl.java
> > Affected versions: at minimum v2.4.0-SNAPSHOT; earlier stable releases also
> > affected based on code history
> > CWE: CWE-918
> > CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N = 7.7 High
> >
> > Root cause: The testConnection endpoint has no @RequiresRoles annotation
> > (any logged-in session is sufficient). The URL validation in
> > UrlVerificationUtils checks only port range and host:port format, with no
> > allowlist or private-IP denylist. Each operator (Elasticsearch, Pulsar,
> > MySQL, ClickHouse, Hive, etc.) issues live network connections to the
> > caller-supplied URL without SSRF-safe HTTP client configuration.
> >
> > Live-validated PoC summary:
> >
> > 1. Login as a regular user (account_type=1, no admin role).
> > 2. POST /inlong/manager/api/node/testConnection with type=ELASTICSEARCH,
> > url=http://169.254.169.254/latest/meta-data/
> > 3. Server returns: "elasticsearch connection failed for url=
> > http://169.254.169.254/latest/meta-data/, username=, password=" --
> > confirming the server made an outbound request to the AWS metadata
> > endpoint.
> > 4. Repeat with type=PULSAR, adminUrl=http://10.0.0.1:8080 -- server
> > returns
> > "Pulsar connection failed for AdminUrl=http://10.0.0.1:8080".
> > 5. Repeat with type=MYSQL, url=127.0.0.1:3306 -- server returns "mysql
> > connection failed for jdbcUrl=jdbc:mysql://127.0.0.1:3306".
> >
> > Recommended fix:
> >
> > 1. Add @RequiresRoles to testConnection consistent with other data node
> > management operations.
> > 2. Extend UrlVerificationUtils to deny link-local, loopback, and RFC 1918
> > address ranges.
> > 3. Configure RestTemplate instances used by HTTP-based operators to reject
> > SSRF-prone targets before connecting.
> >
> > For your review and coordinated disclosure,
> > Geo
> >
>
Re: [InLong] Authenticated SSRF via POST /api/node/testConnection
Posted by 付文凯 <fu...@gmail.com>.
Thank you. We have addressed this issue in the PR mentioned above:
https://github.com/apache/inlong/pull/12116
Geo via dev <de...@inlong.apache.org> 于2026年5月28日周四 10:52写道：
> Hi team,
>
> I've gone through https://inlong.apache.org/docs/next/security/ and I
> believe the below finding is valid and thus I'm reporting:
>
> I've found a SSRF vulnerability in Apache InLong Manager affecting the
> `POST /api/node/testConnection` REST endpoint.
>
> Summary: Any authenticated user (no admin role required) can cause the
> InLong Manager server to make outbound HTTP requests or TCP connections to
> arbitrary internal hosts and ports, including cloud instance metadata
> services. This is confirmed on inlong/manager:latest (v2.4.0-SNAPSHOT,
> commit 965f9da3).
>
> Affected component: inlong-manager, DataNodeController.java /
> DataNodeServiceImpl.java
> Affected versions: at minimum v2.4.0-SNAPSHOT; earlier stable releases also
> affected based on code history
> CWE: CWE-918
> CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N = 7.7 High
>
> Root cause: The testConnection endpoint has no @RequiresRoles annotation
> (any logged-in session is sufficient). The URL validation in
> UrlVerificationUtils checks only port range and host:port format, with no
> allowlist or private-IP denylist. Each operator (Elasticsearch, Pulsar,
> MySQL, ClickHouse, Hive, etc.) issues live network connections to the
> caller-supplied URL without SSRF-safe HTTP client configuration.
>
> Live-validated PoC summary:
>
> 1. Login as a regular user (account_type=1, no admin role).
> 2. POST /inlong/manager/api/node/testConnection with type=ELASTICSEARCH,
> url=http://169.254.169.254/latest/meta-data/
> 3. Server returns: "elasticsearch connection failed for url=
> http://169.254.169.254/latest/meta-data/, username=, password=" --
> confirming the server made an outbound request to the AWS metadata
> endpoint.
> 4. Repeat with type=PULSAR, adminUrl=http://10.0.0.1:8080 -- server
> returns
> "Pulsar connection failed for AdminUrl=http://10.0.0.1:8080".
> 5. Repeat with type=MYSQL, url=127.0.0.1:3306 -- server returns "mysql
> connection failed for jdbcUrl=jdbc:mysql://127.0.0.1:3306".
>
> Recommended fix:
>
> 1. Add @RequiresRoles to testConnection consistent with other data node
> management operations.
> 2. Extend UrlVerificationUtils to deny link-local, loopback, and RFC 1918
> address ranges.
> 3. Configure RestTemplate instances used by HTTP-based operators to reject
> SSRF-prone targets before connecting.
>
> For your review and coordinated disclosure,
> Geo
>
Re: [InLong] Authenticated SSRF via POST /api/node/testConnection
Posted by 付文凯 <fu...@gmail.com>.
Thank you. We have addressed this issue in the PR mentioned above:
https://github.com/apache/inlong/pull/12130
Geo via dev <de...@inlong.apache.org> 于2026年5月28日周四 10:52写道：
> Hi team,
>
> I've gone through https://inlong.apache.org/docs/next/security/ and I
> believe the below finding is valid and thus I'm reporting:
>
> I've found a SSRF vulnerability in Apache InLong Manager affecting the
> `POST /api/node/testConnection` REST endpoint.
>
> Summary: Any authenticated user (no admin role required) can cause the
> InLong Manager server to make outbound HTTP requests or TCP connections to
> arbitrary internal hosts and ports, including cloud instance metadata
> services. This is confirmed on inlong/manager:latest (v2.4.0-SNAPSHOT,
> commit 965f9da3).
>
> Affected component: inlong-manager, DataNodeController.java /
> DataNodeServiceImpl.java
> Affected versions: at minimum v2.4.0-SNAPSHOT; earlier stable releases also
> affected based on code history
> CWE: CWE-918
> CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N = 7.7 High
>
> Root cause: The testConnection endpoint has no @RequiresRoles annotation
> (any logged-in session is sufficient). The URL validation in
> UrlVerificationUtils checks only port range and host:port format, with no
> allowlist or private-IP denylist. Each operator (Elasticsearch, Pulsar,
> MySQL, ClickHouse, Hive, etc.) issues live network connections to the
> caller-supplied URL without SSRF-safe HTTP client configuration.
>
> Live-validated PoC summary:
>
> 1. Login as a regular user (account_type=1, no admin role).
> 2. POST /inlong/manager/api/node/testConnection with type=ELASTICSEARCH,
> url=http://169.254.169.254/latest/meta-data/
> 3. Server returns: "elasticsearch connection failed for url=
> http://169.254.169.254/latest/meta-data/, username=, password=" --
> confirming the server made an outbound request to the AWS metadata
> endpoint.
> 4. Repeat with type=PULSAR, adminUrl=http://10.0.0.1:8080 -- server
> returns
> "Pulsar connection failed for AdminUrl=http://10.0.0.1:8080".
> 5. Repeat with type=MYSQL, url=127.0.0.1:3306 -- server returns "mysql
> connection failed for jdbcUrl=jdbc:mysql://127.0.0.1:3306".
>
> Recommended fix:
>
> 1. Add @RequiresRoles to testConnection consistent with other data node
> management operations.
> 2. Extend UrlVerificationUtils to deny link-local, loopback, and RFC 1918
> address ranges.
> 3. Configure RestTemplate instances used by HTTP-based operators to reject
> SSRF-prone targets before connecting.
>
> For your review and coordinated disclosure,
> Geo
>