Samin061 opened a new pull request, #69644: URL: https://github.com/apache/airflow/pull/69644
When the api-server serves a task's logs it fetches them from the worker's log server at `http://{hostname}:{port}/log/...`, where `hostname` is whatever the worker reported for that task instance over the Execution API and was stored on the row unchanged. Nothing checks that value is a bare host before it is interpolated into the URL, so a hostname that carries URL syntax (for example `[email protected]`, or a value with a path or scheme) breaks out of the host component and the request lands on a different host than intended. That request is not anonymous: `_fetch_logs_from_service` attaches a freshly signed `task-instance-logs` token and, by default, follows redirects, so the token can be delivered to an attacker-chosen host and a log-server redirect can bounce it further. I hit this while tracing where `ti.hostname` is written against where it is later trusted, and the two ends disagree on the value being a safe host. The fix validates the hostname against a bare-host pattern inside `_get_log_retrieval_url` so an unexpected value yields no fetch URL at all, which covers both the worker and triggerer paths, and sets `allow_redirects=False` on the fetch so a signed request cannot be redirected off-host. Valid hostnames and IPs are unaffected. --- ##### Was generative AI tooling used to co-author this PR? - [ ] Yes (please specify the tool below) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
