HackerOne Bug Bounty Disclosure: openssl-engine-selection-omitted-from-mtls-connection-matching

A researcher found a connection-reuse issue in curl’s mutual TLS (mTLS) support when OpenSSL ENGINEs are used to load client certificates and private keys.

An OpenSSL ENGINE can interpret an identifier such as `slot0-key` and map it to a particular private key. Two different ENGINEs could interpret the same identifier as different credentials. However, curl did not include the selected ENGINE when deciding whether an existing TLS connection could be reused.

## How the Issue Could Occur

Suppose one curl handle uses `engine_alpha`, where `slot0-key` belongs to User A, while another handle uses `engine_beta`, where the same identifier belongs to User B.

If both handles connect to the same server and use otherwise identical TLS settings, curl could consider their configurations equivalent. The second handle might then reuse the connection created by the first handle instead of creating a new TLS connection with its own client certificate.

In the reported scenario, a request intended to use User B’s mTLS identity could be sent over a connection authenticated as User A.

This could cause the server to process User B’s request using User A’s authorization context. The issue therefore represented a possible identity mix-up between mTLS connections.

## Why the Existing Fix Was Not Enough

A curl change added client certificate and private-key settings to the connection-reuse comparison. That prevented reuse when applications selected different key or certificate identifiers.

However, the fix did not account for the ENGINE that gives those identifiers their meaning. Identical strings could still refer to different credentials when interpreted by different ENGINEs.

## Reproduction Limitations

The issue required an unusual configuration: two separate ENGINEs had to resolve the same certificate and key identifiers to different client identities.

The submitted proof of concept demonstrated that the configuration-comparison logic treated the two handles as matching, but curl maintainers noted that the proof of concept did not reproduce the complete TLS behavior in practice.

curl’s maintainers classified the report as a bug but not a security vulnerability. They explained that support for provider-selected connections had recently been changed so those connections are no longer reused, which already prevents the reported condition in current versions.

OpenSSL ENGINEs are also deprecated in modern OpenSSL releases, further limiting the practical impact. The report was therefore closed as **Informative**, rather than receiving a security fix or bounty.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.

HackerOne report summary

Programme

Submitted by Anteater

Profile

Report title OpenSSL ENGINE selection omitted from mTLS connection matching

Report link

Date submitted 2026-09-14T06:59:12.767Z

A researcher found a connection-reuse issue in curl’s mutual TLS (mTLS) support when OpenSSL ENGINEs are used to load client certificates and private keys.

An OpenSSL ENGINE can interpret an identifier such as `slot0-key` and map it to a particular private key. Two different ENGINEs could interpret the same identifier as different credentials. However, curl did not include the selected ENGINE when deciding whether an existing TLS connection could be reused.

## How the Issue Could Occur

Suppose one curl handle uses `engine_alpha`, where `slot0-key` belongs to User A, while another handle uses `engine_beta`, where the same identifier belongs to User B.

If both handles connect to the same server and use otherwise identical TLS settings, curl could consider their configurations equivalent. The second handle might then reuse the connection created by the first handle instead of creating a new TLS connection with its own client certificate.

In the reported scenario, a request intended to use User B’s mTLS identity could be sent over a connection authenticated as User A.

This could cause the server to process User B’s request using User A’s authorization context. The issue therefore represented a possible identity mix-up between mTLS connections.

## Why the Existing Fix Was Not Enough

A curl change added client certificate and private-key settings to the connection-reuse comparison. That prevented reuse when applications selected different key or certificate identifiers.

However, the fix did not account for the ENGINE that gives those identifiers their meaning. Identical strings could still refer to different credentials when interpreted by different ENGINEs.

## Reproduction Limitations

The issue required an unusual configuration: two separate ENGINEs had to resolve the same certificate and key identifiers to different client identities.

The submitted proof of concept demonstrated that the configuration-comparison logic treated the two handles as matching, but curl maintainers noted that the proof of concept did not reproduce the complete TLS behavior in practice.

curl’s maintainers classified the report as a bug but not a security vulnerability. They explained that support for provider-selected connections had recently been changed so those connections are no longer reused, which already prevents the reported condition in current versions.

OpenSSL ENGINEs are also deprecated in modern OpenSSL releases, further limiting the practical impact. The report was therefore closed as **Informative**, rather than receiving a security fix or bounty.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.