CVE-2025-49825 is the authentication bypass vulnerability in Teleport, disclosed in June 2025 by Teleport security engineers. Recently I’ve conducted an engagement where Teleport was used in the target infrastructure. This led to a small investigation on the vulnerability, root cause and exploitation. As previously detailed information was not published (at least to my knowledge) - I’d like to share some results of this work. What is Teleport In this blogpost I will talk about Teleport software available at https://github.com/gravitational/teleport . Simply put, Teleport is an open-source solution for secure infrastructure access. It provides means to authenticate, authorize and connect to various remote assets in a centralized and auditable way. It supports a lot of nice features to improve the infrastructure security, such as MFA, SSO, session sharing, infrastructure management and others. What kind of assets can you access through Teleport? Some examples: - SSH nodes - Kubernetes clusters - Databases - Web apps - Windows & Linux servers in general Centralized access to the sensitive infrastructure assets? Sounds interesting. Let’s see now what the vulnerability was about. Finding the bug We start with CVE and the following advisory: https://github.com/gravitational/teleport/security/advisories/GHSA-8cqv-pj7f-pwpc Teleport security engineers identified a critical security vulnerability that could allow remote authentication bypass of Teleport. ... For the full mitigation, we require you to upgrade both Proxy and Teleport agents. This is an interesting part. In a nutshell, Teleport has two components: proxy and agent. Proxy is the server which provides access to the managed asset (infrastructure resource). The agent runs on the asset, connects it to Teleport proxy and allows the asset to be managed by proxy. The complete architecture description can be found here: https://goteleport.com/docs/core-concepts/ . If the advisory states that both proxy and agent upgrade is required for the full mitigation - I would assume that the vulnerability can be exploited if either component is not patched. Finding an outdated agent in the internal infrastructure is more likely than proxy in my experience, so that’s good news for us. Then we have the fixed versions list: Fixed in versions: 17.5.2, 16.5.12, 15.5.3, 14.4.1, 13.4.27, 12.4.35. Let’s find the correct commit, luckily the source code is available. I’ve found the following pull request: https://github.com/gravitational/teleport/pull/56250 - Avoid counterproductive checks in IsUserAuthority and IsHostAuthority , which is obviously relevant to the authentication bypass: This PR removes the special handling for *ssh.Certificate authorities in the IsHostAuthority and IsUserAuthority callbacks used by x/crypto/ssh.CertChecker as it's a condition that should never happen anyway, and can lead to accepting invalid credentials as legitimate. Commit review quickly leads us to lib/srv/authhandlers.go , which is related to authentication. These are the important diffs. IsUserAuthority function checks the issuer of a user certificate a client presents to the agent and verifies it is signed by Teleport User CA key. This guarantees that certificate used for authentication originates from the Teleport proxy (trusted CA) which already handled the authentication of the user. Looking at authorityForCert function (called from IsUserAuthority to conduct the check) we see that if the certificate was signed by an unknown authority - access is denied. 1029 // the certificate was signed by unknown authority 1030 if ca == nil { 1031 return nil , trace . AccessDenied ( "the certificate signed by untrusted CA" ) 1032 } Looking back at authorityForCert diff, we see that a switch case block was removed, which rings a bell. The function determines which Teleport CA (of a given caType : “user” or “host”) matches the signing authority of the supplied SSH key . for _ , checker := range checkers { // if we have a certificate, compare the certificate signing key against // the ca key. otherwise check the public key that was passed in. this is // due to the differences in how this function is called by the user and // host checkers. switch v := key .( type ) { ( 1 ) case * ssh . Certificate : ( 2 ) if apisshutils . KeysEqual ( v . SignatureKey , checker ) { ca = cas [ i ] break } ( 3 ) default : ( 4 ) if apisshutils . KeysEqual ( key , checker ) { ca = cas [ i ] break } } } The presented material (SSH key) is compared against the retrieved CA checkers (2, 4). We see that the vulnerable code version supported two different SSH key types (1, 3). Case (1) was removed to patch the bug. So what is case *ssh.Certificate ? Let’s get back to the definition of SSH certificate, that is passed to the Teleport agent during the authentication: ssh.Certificate : https://github.com/golang/crypto/blob/master/ssh/certs.go#L72 // An Certificate represents an OpenSSH certificate as defined in // [PROTOCOL.certkeys]?rev...