When a user is authenticating to a daemon using IDTOKENS it is possible for them to impersonate other users and/or the "condor" service itself.

Component Vulnerable Versions Platform Availability Fix Available
All daemons 8.9.2 through 8.9.10 (inclusive) All Not known to be publicly exploited 8.9.11
Status Access Required Host Type Required Effort Required Impact/Consequences
Verified Login Any Low High
Fixed Date Credit
2021-01-27 Brian Bockleman

Access Required:


An attacker must only be able to authenticate (as any user) to a condor_schedd process. IDTOKENS is enabled by default; this exploit could be performed by any user who is able to login to the SchedD machine. Any type of authentication can be used including the default methods such as "FS" (on Linux) or NTSSPI (on Windows)

Effort Required:


Any user who can authenticate to a condor_schedd can use command line tools supplied with HTCondor to obtain a valid IDTOKEN. With low effort they could then create a custom tool to connect to the condor_schedd to impersonate another user or the "condor" service.



This allows a user to impersonate any other or the "condor" service.

This would allow the user to submit a job as another user on the system, which could potentially run processes as that user and read/write files belonging to that user.

By impersonating the "condor" service, the attacker could turn off or potentially reconfigure the HTCondor daemons.


If you do not need to use IDTOKENS, you can disable that authentication method by specifying a list of authentication mechanisms that does not include it.

On Linux, you would want to set, e.g., (removing any other methods you did not want to use):


On Windows, you would want to set, e.g., (removing any other methods you did not want to use):


You should also check your configuration for other places you may have explicitly set the list of methods:

condor_config_val -dump AUTHENTICATION_METHODS

After making any changes, you will need to run


Full Details:

Embargoed until future notice.