JWT tokens appearing in task logs

[unixengineer]

Apache Airflow version

3.1.7

If "Other Airflow 3 version" selected, which one?

No response

What happened?

in task logs, JWT tokens are being exposed. hers is an example:

{"timestamp":"2026-02-24T19:46:05.812507Z","level":"info","event":"Executing workload","workload":"ExecuteTask(token='eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIwMTljOTEyZS1mNzIxLTcyMjYtODA0Yi1hMGYwNjE4NzU4NDkiLCJqdGkiOiI4NzY3ZjQyMTllMjM0NmU5YjdkOWI2ZjNjODIzM2RlNiIsImF1ZCI6InVybjphaXJmbG93LmFwYWNoZS5vcmc6dGFzayIsIm5iZiI6MTc3MTk2MjMzNSwiZXhwIjoxNzcxOTYyOTM1LCJpYXQiOjE3NzE5NjIzMzV9.rS5py-iaK7SjB5wAWmaWPdRBPX_nwZd96e6I10GnLAqyzBimv1Mb4TmtKJ-R2kNjKd_85z2DE8uKE73Qn1hUGA', ti=TaskInstance(id=UUID('019c912e-f721-7226-804b-a0f061875849'), dag_version_id=UUID('019c912f-3165-7016-af2f-ccd4979fff19'), task_id='upload_to_s3', dag_id='sync_git_to_s3', run_id='scheduled__2026-02-24T19:45:00+00:00', try_number=1, map_index=-1, pool_slots=1, queue='default', priority_weight=1, executor_config=None, parent_context_carrier={}, context_carrier={}), dag_rel_path=PurePosixPath('sync_git_to_s3.py'), bundle_info=BundleInfo(name='dags-folder', version=None), log_path='dag_id=sync_git_to_s3/run_id=scheduled__2026-02-24T19:45:00+00:00/task_id=upload_to_s3/attempt=1.log', type='ExecuteTask')","logger":"__main__","filename":"execute_workload.py","lineno":56}

What you think should happen instead?

Token exposure is being flagged as security risk and why expose the token in the logs ?

How to reproduce

3.1.7 - set logging to INFO

Operating System

RHEL 9

Versions of Apache Airflow Providers

No response

Deployment

Official Apache Airflow Helm Chart

Deployment details

No response

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[Eason09053360]

I would like to work on this issue!

[duuree-beep]

I’m experiencing the same error. Even though the API server is running, when I access the URL it shows "something bad has happened."
When I checked the API server pod logs, it appears to be a JWT-related error.

[pierrejeambrun]

Can you provide a way to reproduce? (Which executor are you using, if you see that in the worker logs or tasks logs, etc...)

I wasn't able to reproduce on my end. (With Celery, I see the payload being logged, but the token is properly redacted).

[ashb]

"logger":"__main__","filename":"execute_workload.py" tells me this might be KubeExec @pierrejeambrun

@unixengineer Are you using KubeExec?

[unixengineer]

"logger":"__main__","filename":"execute_workload.py" tells me this might be KubeExec @pierrejeambrun

@unixengineer Are you using KubeExec?

We are using KubernetesExecutor.

[unixengineer]

Can you provide a way to reproduce? (Which executor are you using, if you see that in the worker logs or tasks logs, etc...)

I wasn't able to reproduce on my end. (With Celery, I see the payload being logged, but the token is properly redacted).

@ashb Sorry - Forgot to mention it. It is KubernetesExecutor.

[duuree-beep]

Are you using a Helm chart? If your error is the same as mine, I can share how I fixed it. Could you please provide more detailed information?