A piece of secret information is sent over the network in the clear if the administrator has configured weaker encryption protocols or if some of the HTCondor daemons are version 8.8 or earlier. An attacker could use this secret information to control the slot of another user, including running their own code as that user. An attacker could also impersonate a condor_negotiator and condor_startd, tricking the condor_schedd into sending them the jobs of any user.

Component Vulnerable Versions Platform Availability Fix Available
Schedd daemon 8.9.3 and above All platforms Not known to be publicly exploited 9.0.10, 9.6.0
Status Access Required Host Type Required Effort Required Impact/Consequences
Verified Ability to capture network traffic between Schedd and Startd or Collector N/A High High
Fixed Date Credit
2022-03-15 Brian Bockelman, Jaime Frey
Access Required: Ability to capture network traffic between Schedd and Startd or Collector

An attacker must be able to capture network traffic between a condor_schedd and a condor_startd or condor_collector. The HTCondor daemons must be configured to use BLOWFISH or 3DES encryption (the default is AES in 9.0 and above) and match password authentication enabled (the default) to be vulnerable. A condor_schedd communicating to a version 8.8 peer is most likely to be vulnerable.

Effort Required: High

A good understanding of the HTCondor network protocol and access to network traffic.

Impact/Consequences Required: High

Using the secret information, an attacker could manipulate a user's running job, including evicting that job or replacing that job with one that executes the attacker's own code. The attacker could impersonate a condor_startd and cause the condor_schedd to send them a user's jobs for execution, allowing the attacker to read private data and return bogus results.


Upgrading all HTCondor daemons to version 9.0.10 or 9.6.0 fully addresses this vulnerability.

If upgrading isn't possible, the easiest workaround is to ensure all machines are running HTCondor 9.0.0 or above, and that the SEC_XXX_ENCRYPTION_METHODS configuration parameters are either unset or list "AES" as the first entry.

If some machines cannot be upgraded to 9.0.0 or above, then you can configure all machines to use encryption for all communications. To do this, set SEC_DEFAULT_ENCRYPTION=REQUIRED and ensure no other SEC_XXX_ENCRYPTION parameters set a different value. In 9.0 and above, the configuration templates use SECURITY: strong and use SECURITY: recommended_v9_0 also enable encryption.

If some of your execute or central manager machines cannot be upgraded to 9.0.0 or above and their configuration cannot be altered to require encryption, you can disable match password authentication on your submit machines. To do this, set SEC_ENABLE_MATCH_PASSWORD_AUTHENTICATION=False in the configuration files. Be advised that this may require additional configuration for authentication and authorization between your submit and execute machines. It can also put significant extra load on your submit machines in a large pool (thousands of nodes).

Full Details:

Embargoed until future notice.