Vulnerability-Lookup

BREW-KIMI-CLI-CVE-2026-114614 (GHSA-JJ7H-C3HG-M23X)

Vulnerability from osv_homebrew – Published: 2026-10-29 23:30 – Updated: 2026-10-30 10:26 – Source website

Summary

Authlib: is_secure_transport() loopback exemption can be bypassed with a userinfo component, allowing cleartext-HTTP URLs to non-loopback hosts

Details

Summary

authlib.common.security.is_secure_transport() is used throughout Authlib to enforce the OAuth 2.0 / OIDC requirement that endpoint and redirect URIs use TLS, with an RFC 8252 §7.3 exemption for loopback http:// URIs. The check is implemented as a textual str.startswith prefix match, so a URL such as http://localhost:80@evil.example/cb — whose actual host is evil.example and whose scheme is plain http — is accepted as "secure". An attacker who can supply a URL to any of the sinks that rely on this check (OIDC RP-Initiated Logout dynamic client registration, RFC 8414 authorization-server metadata validation, error-redirect rendering) can smuggle a cleartext non-loopback URL past the TLS-required guard. This is a defense-in-depth / spec-conformance failure; severity is low.

Details

Affected versions: authlib >= 0.13, <= 1.7.2 (all releases containing the loopback prefix exemption; verified against 1.7.2, the current latest)

The vulnerable function, from authlib/common/security.py at v1.7.2:

13  def is_secure_transport(uri):
14      """Check if the uri is over ssl."""
15      if os.getenv("AUTHLIB_INSECURE_TRANSPORT"):
16          return True
17
18      uri = uri.lower()
19      return uri.startswith(
20          ("https://", "http://localhost:", "http://127.0.0.1:", "http://[::1]:")
21      )

Per RFC 3986 §3.2 the authority component of a URI is [ userinfo "@" ] host [ ":" port ]. The URL http://localhost:80@evil.example/cb therefore has userinfo localhost:80 and host evil.example. Because the check is a raw prefix match against the full URL string, the http://localhost: prefix matches the userinfo portion and the function returns True even though the scheme is http and the host is an arbitrary external name. The trailing : in each allow-list entry — presumably intended to force a host:port shape and reject http://localhost.evil.com — is also satisfied by the user:password separator inside userinfo, so http://localhost:@evil.example/ matches too. The same construction works against all three loopback prefixes (http://127.0.0.1:...@evil.example/, http://[::1]:...@evil.example/).

is_secure_transport() is consumed at the following locations in v1.7.2, none of which independently reject URLs containing a userinfo component:

authlib/oidc/rpinitiated/registration.py:50-57 — validation of post_logout_redirect_uris during OIDC dynamic client registration for public clients (token_endpoint_auth_method == "none"). The preceding is_valid_url() check (authlib/common/urls.py:142-146) only requires parsed.scheme and parsed.hostname and does not reject userinfo, so the crafted URL passes both guards. A public client can therefore register http://localhost:80@attacker.example/cb as a post-logout redirect target; the OpenID Provider will later 302 the end-user's browser to that cleartext non-loopback URL (carrying state).
authlib/oauth2/rfc8414/models.py:61,75,100,115,123,248,284 — validation of issuer, authorization_endpoint, token_endpoint, jwks_uri, registration_endpoint, revocation_endpoint, introspection_endpoint in Authorization Server Metadata / OIDC Discovery documents. A relying party using AuthorizationServerMetadata.validate() would accept endpoint values of this form as satisfying the "MUST use https" requirement when they do not.
authlib/oidc/rpinitiated/discovery.py:12 — validation of end_session_endpoint in provider metadata.
authlib/oauth2/rfc6749/errors.py:64 and authlib/oauth1/rfc5849/errors.py:33 — governs how redirect_uri is rendered in error bodies (cosmetic).

The http://localhost: prefix was introduced in commit 0225c86b (first released in v0.13); http://127.0.0.1: and http://[::1]: were added later in the 1.6.x line. All variants share the same prefix-match weakness.

PoC

Against the current latest release (1.7.2):

python3 -m venv venv
./venv/bin/pip install 'authlib==1.7.2'
./venv/bin/python poc.py

poc.py:

#!/usr/bin/env python3
"""
is_secure_transport() must return True only for https:// URLs, or http://
URLs whose host is a loopback address (localhost / 127.0.0.1 / ::1).

Bypass: http://localhost:80@evil.example/cb has host 'evil.example'
(userinfo = 'localhost:80') per RFC 3986, but matches the prefix
'http://localhost:' and is therefore accepted as secure.
"""
from urllib.parse import urlparse
from authlib.common.security import is_secure_transport

cases = [
    "http://localhost:80@evil.example/cb",
    "http://127.0.0.1:80@evil.example/cb",
    "http://localhost:@evil.example/cb",
]

vulnerable = False
for url in cases:
    parsed = urlparse(url)
    ok = is_secure_transport(url)
    print(f"is_secure_transport({url!r}) = {ok}  "
          f"[actual host = {parsed.hostname!r}, scheme = {parsed.scheme!r}]")
    if ok and parsed.hostname not in ("localhost", "127.0.0.1", "::1") and parsed.scheme != "https":
        vulnerable = True

if vulnerable:
    print("\nVULNERABLE: is_secure_transport() returned True for a plain-HTTP "
          "URL whose host is NOT a loopback address.")
else:
    print("\nNOT VULNERABLE")

assert vulnerable, "expected bypass not observed"

Expected output:

is_secure_transport('http://localhost:80@evil.example/cb') = True  [actual host = 'evil.example', scheme = 'http']
is_secure_transport('http://127.0.0.1:80@evil.example/cb') = True  [actual host = 'evil.example', scheme = 'http']
is_secure_transport('http://localhost:@evil.example/cb') = True  [actual host = 'evil.example', scheme = 'http']

VULNERABLE: is_secure_transport() returned True for a plain-HTTP URL whose host is NOT a loopback address.

Impact

Deployments are affected if they rely on is_secure_transport() — directly or via the Authlib call sites listed above — to reject cleartext non-loopback URLs supplied by an external party. The most realistic path is an OpenID Provider that enables OIDC dynamic client registration and RP-Initiated Logout: a public client can register a post_logout_redirect_uris entry of the form http://localhost:80@attacker.example/…, which the provider will later use as an open-redirect target over plain HTTP. Relying parties that call AuthorizationServerMetadata.validate() on fetched discovery documents are also affected, though exploiting that sink requires the attacker to influence the metadata document. This does not bypass the OAuth 2.0 redirect-URI exact-match registration check and does not by itself yield authentication bypass or token theft; it defeats a TLS-required hardening check.

Suggested fix: Parse the URI with urllib.parse.urlsplit() and return True only if scheme == "https", or scheme == "http" and hostname in {"localhost", "127.0.0.1", "::1"}; additionally reject any URI whose parsed username/password is non-empty at these validation sites.

Severity

2.6 (Low)


                    
                      CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N

References

URL

Type

	https://github.com/authlib/authlib/security/advis…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-114614	ADVISORY
	https://github.com/authlib/authlib/commit/95ad1f9…	WEB
	https://github.com/authlib/authlib	PACKAGE
	https://github.com/authlib/authlib/releases/tag/v1.8.0	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.8.0",
        "upstream_fixed_in": "1.8.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "kimi-cli",
        "purl": "pkg:brew/kimi-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.40"
            },
            {
              "fixed": "1.50.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.8.0",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.8.0"
      }
    ]
  },
  "details": "### Summary\n`authlib.common.security.is_secure_transport()` is used throughout Authlib to enforce the OAuth 2.0 / OIDC requirement that endpoint and redirect URIs use TLS, with an RFC 8252 \u00a77.3 exemption for loopback `http://` URIs. The check is implemented as a textual `str.startswith` prefix match, so a URL such as `http://localhost:80@evil.example/cb` \u2014 whose actual host is `evil.example` and whose scheme is plain `http` \u2014 is accepted as \"secure\". An attacker who can supply a URL to any of the sinks that rely on this check (OIDC RP-Initiated Logout dynamic client registration, RFC 8414 authorization-server metadata validation, error-redirect rendering) can smuggle a cleartext non-loopback URL past the TLS-required guard. This is a defense-in-depth / spec-conformance failure; severity is low.\n\n### Details\n**Affected versions:** `authlib \u003e= 0.13, \u003c= 1.7.2` (all releases containing the loopback prefix exemption; verified against 1.7.2, the current latest)\n\nThe vulnerable function, from `authlib/common/security.py` at v1.7.2:\n\n```python\n13  def is_secure_transport(uri):\n14      \"\"\"Check if the uri is over ssl.\"\"\"\n15      if os.getenv(\"AUTHLIB_INSECURE_TRANSPORT\"):\n16          return True\n17\n18      uri = uri.lower()\n19      return uri.startswith(\n20          (\"https://\", \"http://localhost:\", \"http://127.0.0.1:\", \"http://[::1]:\")\n21      )\n```\n\nPer RFC 3986 \u00a73.2 the authority component of a URI is `[ userinfo \"@\" ] host [ \":\" port ]`. The URL `http://localhost:80@evil.example/cb` therefore has userinfo `localhost:80` and host `evil.example`. Because the check is a raw prefix match against the full URL string, the `http://localhost:` prefix matches the userinfo portion and the function returns `True` even though the scheme is `http` and the host is an arbitrary external name. The trailing `:` in each allow-list entry \u2014 presumably intended to force a `host:port` shape and reject `http://localhost.evil.com` \u2014 is also satisfied by the `user:password` separator inside userinfo, so `http://localhost:@evil.example/` matches too. The same construction works against all three loopback prefixes (`http://127.0.0.1:...@evil.example/`, `http://[::1]:...@evil.example/`).\n\n`is_secure_transport()` is consumed at the following locations in v1.7.2, none of which independently reject URLs containing a userinfo component:\n\n- `authlib/oidc/rpinitiated/registration.py:50-57` \u2014 validation of `post_logout_redirect_uris` during OIDC dynamic client registration for public clients (`token_endpoint_auth_method == \"none\"`). The preceding `is_valid_url()` check (`authlib/common/urls.py:142-146`) only requires `parsed.scheme and parsed.hostname` and does **not** reject userinfo, so the crafted URL passes both guards. A public client can therefore register `http://localhost:80@attacker.example/cb` as a post-logout redirect target; the OpenID Provider will later 302 the end-user\u0027s browser to that cleartext non-loopback URL (carrying `state`).\n- `authlib/oauth2/rfc8414/models.py:61,75,100,115,123,248,284` \u2014 validation of `issuer`, `authorization_endpoint`, `token_endpoint`, `jwks_uri`, `registration_endpoint`, `revocation_endpoint`, `introspection_endpoint` in Authorization Server Metadata / OIDC Discovery documents. A relying party using `AuthorizationServerMetadata.validate()` would accept endpoint values of this form as satisfying the \"MUST use https\" requirement when they do not.\n- `authlib/oidc/rpinitiated/discovery.py:12` \u2014 validation of `end_session_endpoint` in provider metadata.\n- `authlib/oauth2/rfc6749/errors.py:64` and `authlib/oauth1/rfc5849/errors.py:33` \u2014 governs how `redirect_uri` is rendered in error bodies (cosmetic).\n\nThe `http://localhost:` prefix was introduced in commit `0225c86b` (first released in v0.13); `http://127.0.0.1:` and `http://[::1]:` were added later in the 1.6.x line. All variants share the same prefix-match weakness.\n\n### PoC\nAgainst the current latest release (1.7.2):\n\n```sh\npython3 -m venv venv\n./venv/bin/pip install \u0027authlib==1.7.2\u0027\n./venv/bin/python poc.py\n```\n\n`poc.py`:\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nis_secure_transport() must return True only for https:// URLs, or http://\nURLs whose host is a loopback address (localhost / 127.0.0.1 / ::1).\n\nBypass: http://localhost:80@evil.example/cb has host \u0027evil.example\u0027\n(userinfo = \u0027localhost:80\u0027) per RFC 3986, but matches the prefix\n\u0027http://localhost:\u0027 and is therefore accepted as secure.\n\"\"\"\nfrom urllib.parse import urlparse\nfrom authlib.common.security import is_secure_transport\n\ncases = [\n    \"http://localhost:80@evil.example/cb\",\n    \"http://127.0.0.1:80@evil.example/cb\",\n    \"http://localhost:@evil.example/cb\",\n]\n\nvulnerable = False\nfor url in cases:\n    parsed = urlparse(url)\n    ok = is_secure_transport(url)\n    print(f\"is_secure_transport({url!r}) = {ok}  \"\n          f\"[actual host = {parsed.hostname!r}, scheme = {parsed.scheme!r}]\")\n    if ok and parsed.hostname not in (\"localhost\", \"127.0.0.1\", \"::1\") and parsed.scheme != \"https\":\n        vulnerable = True\n\nif vulnerable:\n    print(\"\\nVULNERABLE: is_secure_transport() returned True for a plain-HTTP \"\n          \"URL whose host is NOT a loopback address.\")\nelse:\n    print(\"\\nNOT VULNERABLE\")\n\nassert vulnerable, \"expected bypass not observed\"\n```\n\nExpected output:\n\n```\nis_secure_transport(\u0027http://localhost:80@evil.example/cb\u0027) = True  [actual host = \u0027evil.example\u0027, scheme = \u0027http\u0027]\nis_secure_transport(\u0027http://127.0.0.1:80@evil.example/cb\u0027) = True  [actual host = \u0027evil.example\u0027, scheme = \u0027http\u0027]\nis_secure_transport(\u0027http://localhost:@evil.example/cb\u0027) = True  [actual host = \u0027evil.example\u0027, scheme = \u0027http\u0027]\n\nVULNERABLE: is_secure_transport() returned True for a plain-HTTP URL whose host is NOT a loopback address.\n```\n\n### Impact\nDeployments are affected if they rely on `is_secure_transport()` \u2014 directly or via the Authlib call sites listed above \u2014 to reject cleartext non-loopback URLs supplied by an external party. The most realistic path is an OpenID Provider that enables OIDC dynamic client registration and RP-Initiated Logout: a public client can register a `post_logout_redirect_uris` entry of the form `http://localhost:80@attacker.example/\u2026`, which the provider will later use as an open-redirect target over plain HTTP. Relying parties that call `AuthorizationServerMetadata.validate()` on fetched discovery documents are also affected, though exploiting that sink requires the attacker to influence the metadata document. This does **not** bypass the OAuth 2.0 redirect-URI exact-match registration check and does not by itself yield authentication bypass or token theft; it defeats a TLS-required hardening check.\n\n**Suggested fix:** Parse the URI with `urllib.parse.urlsplit()` and return `True` only if `scheme == \"https\"`, or `scheme == \"http\"` and `hostname in {\"localhost\", \"127.0.0.1\", \"::1\"}`; additionally reject any URI whose parsed `username`/`password` is non-empty at these validation sites.",
  "id": "BREW-kimi-cli-CVE-2026-114614",
  "modified": "2026-10-30T10:26:52Z",
  "published": "2026-10-29T23:30:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-jj7h-c3hg-m23x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114614"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/95ad1f90acf0c7b9cf2a8f25e6eb3f1135b8dc70"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/releases/tag/v1.8.0"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authlib: is_secure_transport() loopback exemption can be bypassed with a userinfo component, allowing cleartext-HTTP URLs to non-loopback hosts",
  "upstream": [
    "GHSA-jj7h-c3hg-m23x",
    "CVE-2026-114614",
    "PYSEC-2026-4354"
  ]
}

CVE-2026-114614 (GCVE-0-2026-114614)

Vulnerability from cvelistv5 – Published: 2026-10-22 21:00 – Updated: 2026-10-29 13:49

Title

Authlib: is_secure_transport() loopback exemption can be bypassed with a userinfo component, allowing cleartext-HTTP URLs to non-loopback hosts

Summary

Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.13 until 1.8.0, authlib.common.security.is_secure_transport() uses a textual prefix comparison for loopback HTTP exemptions, so a URL whose userinfo begins with a loopback host can be accepted even when its parsed host is an external non-loopback system. An external party able to supply a URL to OIDC RP-Initiated Logout registration, authorization-server metadata validation, or another call site can bypass the TLS-required guard and cause cleartext redirection or acceptance of cleartext endpoints. The issue does not bypass redirect URI exact matching and does not by itself forge tokens or authenticate users. The vulnerable authlib.common.security.is_secure_transport() implementation in authlib/common/security.py misinterprets the userinfo component before OIDC RP-Initiated Logout dynamic client registration and other consumers enforce transport security. This issue is fixed in version 1.8.0.

Severity

2.6 (Low)


                        
                          CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-29 13:49 UTC

CWE

CWE-601 - URL Redirection to Untrusted Site ('Open Redirect')
CWE-693 - Protection Mechanism Failure

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 8035 records in the last 180 days details

References

3 references

URL	Tags
https://github.com/authlib/authlib/security/advis…	x_refsource_CONFIRM
https://github.com/authlib/authlib/commit/95ad1f9…	x_refsource_MISC
https://github.com/authlib/authlib/releases/tag/v1.8.0	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
authlib	authlib	Affected: < 1.8.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-114614",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-29T13:49:16.938418Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-29T13:49:50.607Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/authlib/authlib/security/advisories/GHSA-jj7h-c3hg-m23x"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "authlib",
          "vendor": "authlib",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.8.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.13 until 1.8.0, authlib.common.security.is_secure_transport() uses a textual prefix comparison for loopback HTTP exemptions, so a URL whose userinfo begins with a loopback host can be accepted even when its parsed host is an external non-loopback system. An external party able to supply a URL to OIDC RP-Initiated Logout registration, authorization-server metadata validation, or another call site can bypass the TLS-required guard and cause cleartext redirection or acceptance of cleartext endpoints. The issue does not bypass redirect URI exact matching and does not by itself forge tokens or authenticate users. The vulnerable authlib.common.security.is_secure_transport() implementation in authlib/common/security.py misinterprets the userinfo component before OIDC RP-Initiated Logout dynamic client registration and other consumers enforce transport security. This issue is fixed in version 1.8.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 2.6,
            "baseSeverity": "LOW",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-601",
              "description": "CWE-601: URL Redirection to Untrusted Site (\u0027Open Redirect\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-693",
              "description": "CWE-693: Protection Mechanism Failure",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-22T21:00:14.354Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/authlib/authlib/security/advisories/GHSA-jj7h-c3hg-m23x",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/authlib/authlib/security/advisories/GHSA-jj7h-c3hg-m23x"
        },
        {
          "name": "https://github.com/authlib/authlib/commit/95ad1f90acf0c7b9cf2a8f25e6eb3f1135b8dc70",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/authlib/authlib/commit/95ad1f90acf0c7b9cf2a8f25e6eb3f1135b8dc70"
        },
        {
          "name": "https://github.com/authlib/authlib/releases/tag/v1.8.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/authlib/authlib/releases/tag/v1.8.0"
        }
      ],
      "source": {
        "advisory": "GHSA-jj7h-c3hg-m23x",
        "discovery": "UNKNOWN"
      },
      "title": "Authlib: is_secure_transport() loopback exemption can be bypassed with a userinfo component, allowing cleartext-HTTP URLs to non-loopback hosts"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-114614",
    "datePublished": "2026-10-22T21:00:14.354Z",
    "dateReserved": "2026-10-21T20:34:25.599Z",
    "dateUpdated": "2026-10-29T13:49:50.607Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

GHSA-JJ7H-C3HG-M23X

Vulnerability from github – Published: 2026-10-27 15:37 – Updated: 2026-10-27 15:37

Summary

Authlib: is_secure_transport() loopback exemption can be bypassed with a userinfo component, allowing cleartext-HTTP URLs to non-loopback hosts

Details

Summary

Details

Affected versions: authlib >= 0.13, <= 1.7.2 (all releases containing the loopback prefix exemption; verified against 1.7.2, the current latest)

The vulnerable function, from authlib/common/security.py at v1.7.2:

13  def is_secure_transport(uri):
14      """Check if the uri is over ssl."""
15      if os.getenv("AUTHLIB_INSECURE_TRANSPORT"):
16          return True
17
18      uri = uri.lower()
19      return uri.startswith(
20          ("https://", "http://localhost:", "http://127.0.0.1:", "http://[::1]:")
21      )

is_secure_transport() is consumed at the following locations in v1.7.2, none of which independently reject URLs containing a userinfo component:

authlib/oidc/rpinitiated/registration.py:50-57 — validation of post_logout_redirect_uris during OIDC dynamic client registration for public clients (token_endpoint_auth_method == "none"). The preceding is_valid_url() check (authlib/common/urls.py:142-146) only requires parsed.scheme and parsed.hostname and does not reject userinfo, so the crafted URL passes both guards. A public client can therefore register http://localhost:80@attacker.example/cb as a post-logout redirect target; the OpenID Provider will later 302 the end-user's browser to that cleartext non-loopback URL (carrying state).
authlib/oauth2/rfc8414/models.py:61,75,100,115,123,248,284 — validation of issuer, authorization_endpoint, token_endpoint, jwks_uri, registration_endpoint, revocation_endpoint, introspection_endpoint in Authorization Server Metadata / OIDC Discovery documents. A relying party using AuthorizationServerMetadata.validate() would accept endpoint values of this form as satisfying the "MUST use https" requirement when they do not.
authlib/oidc/rpinitiated/discovery.py:12 — validation of end_session_endpoint in provider metadata.
authlib/oauth2/rfc6749/errors.py:64 and authlib/oauth1/rfc5849/errors.py:33 — governs how redirect_uri is rendered in error bodies (cosmetic).

PoC

Against the current latest release (1.7.2):

python3 -m venv venv
./venv/bin/pip install 'authlib==1.7.2'
./venv/bin/python poc.py

poc.py:

#!/usr/bin/env python3
"""
is_secure_transport() must return True only for https:// URLs, or http://
URLs whose host is a loopback address (localhost / 127.0.0.1 / ::1).

Bypass: http://localhost:80@evil.example/cb has host 'evil.example'
(userinfo = 'localhost:80') per RFC 3986, but matches the prefix
'http://localhost:' and is therefore accepted as secure.
"""
from urllib.parse import urlparse
from authlib.common.security import is_secure_transport

cases = [
    "http://localhost:80@evil.example/cb",
    "http://127.0.0.1:80@evil.example/cb",
    "http://localhost:@evil.example/cb",
]

vulnerable = False
for url in cases:
    parsed = urlparse(url)
    ok = is_secure_transport(url)
    print(f"is_secure_transport({url!r}) = {ok}  "
          f"[actual host = {parsed.hostname!r}, scheme = {parsed.scheme!r}]")
    if ok and parsed.hostname not in ("localhost", "127.0.0.1", "::1") and parsed.scheme != "https":
        vulnerable = True

if vulnerable:
    print("\nVULNERABLE: is_secure_transport() returned True for a plain-HTTP "
          "URL whose host is NOT a loopback address.")
else:
    print("\nNOT VULNERABLE")

assert vulnerable, "expected bypass not observed"

Expected output:

is_secure_transport('http://localhost:80@evil.example/cb') = True  [actual host = 'evil.example', scheme = 'http']
is_secure_transport('http://127.0.0.1:80@evil.example/cb') = True  [actual host = 'evil.example', scheme = 'http']
is_secure_transport('http://localhost:@evil.example/cb') = True  [actual host = 'evil.example', scheme = 'http']

VULNERABLE: is_secure_transport() returned True for a plain-HTTP URL whose host is NOT a loopback address.

Impact

Severity

2.6 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-114614"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-319",
      "CWE-601",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-27T15:37:48Z",
    "nvd_published_at": "2026-10-22T21:17:16Z",
    "severity": "LOW"
  },
  "details": "### Summary\n`authlib.common.security.is_secure_transport()` is used throughout Authlib to enforce the OAuth 2.0 / OIDC requirement that endpoint and redirect URIs use TLS, with an RFC 8252 \u00a77.3 exemption for loopback `http://` URIs. The check is implemented as a textual `str.startswith` prefix match, so a URL such as `http://localhost:80@evil.example/cb` \u2014 whose actual host is `evil.example` and whose scheme is plain `http` \u2014 is accepted as \"secure\". An attacker who can supply a URL to any of the sinks that rely on this check (OIDC RP-Initiated Logout dynamic client registration, RFC 8414 authorization-server metadata validation, error-redirect rendering) can smuggle a cleartext non-loopback URL past the TLS-required guard. This is a defense-in-depth / spec-conformance failure; severity is low.\n\n### Details\n**Affected versions:** `authlib \u003e= 0.13, \u003c= 1.7.2` (all releases containing the loopback prefix exemption; verified against 1.7.2, the current latest)\n\nThe vulnerable function, from `authlib/common/security.py` at v1.7.2:\n\n```python\n13  def is_secure_transport(uri):\n14      \"\"\"Check if the uri is over ssl.\"\"\"\n15      if os.getenv(\"AUTHLIB_INSECURE_TRANSPORT\"):\n16          return True\n17\n18      uri = uri.lower()\n19      return uri.startswith(\n20          (\"https://\", \"http://localhost:\", \"http://127.0.0.1:\", \"http://[::1]:\")\n21      )\n```\n\nPer RFC 3986 \u00a73.2 the authority component of a URI is `[ userinfo \"@\" ] host [ \":\" port ]`. The URL `http://localhost:80@evil.example/cb` therefore has userinfo `localhost:80` and host `evil.example`. Because the check is a raw prefix match against the full URL string, the `http://localhost:` prefix matches the userinfo portion and the function returns `True` even though the scheme is `http` and the host is an arbitrary external name. The trailing `:` in each allow-list entry \u2014 presumably intended to force a `host:port` shape and reject `http://localhost.evil.com` \u2014 is also satisfied by the `user:password` separator inside userinfo, so `http://localhost:@evil.example/` matches too. The same construction works against all three loopback prefixes (`http://127.0.0.1:...@evil.example/`, `http://[::1]:...@evil.example/`).\n\n`is_secure_transport()` is consumed at the following locations in v1.7.2, none of which independently reject URLs containing a userinfo component:\n\n- `authlib/oidc/rpinitiated/registration.py:50-57` \u2014 validation of `post_logout_redirect_uris` during OIDC dynamic client registration for public clients (`token_endpoint_auth_method == \"none\"`). The preceding `is_valid_url()` check (`authlib/common/urls.py:142-146`) only requires `parsed.scheme and parsed.hostname` and does **not** reject userinfo, so the crafted URL passes both guards. A public client can therefore register `http://localhost:80@attacker.example/cb` as a post-logout redirect target; the OpenID Provider will later 302 the end-user\u0027s browser to that cleartext non-loopback URL (carrying `state`).\n- `authlib/oauth2/rfc8414/models.py:61,75,100,115,123,248,284` \u2014 validation of `issuer`, `authorization_endpoint`, `token_endpoint`, `jwks_uri`, `registration_endpoint`, `revocation_endpoint`, `introspection_endpoint` in Authorization Server Metadata / OIDC Discovery documents. A relying party using `AuthorizationServerMetadata.validate()` would accept endpoint values of this form as satisfying the \"MUST use https\" requirement when they do not.\n- `authlib/oidc/rpinitiated/discovery.py:12` \u2014 validation of `end_session_endpoint` in provider metadata.\n- `authlib/oauth2/rfc6749/errors.py:64` and `authlib/oauth1/rfc5849/errors.py:33` \u2014 governs how `redirect_uri` is rendered in error bodies (cosmetic).\n\nThe `http://localhost:` prefix was introduced in commit `0225c86b` (first released in v0.13); `http://127.0.0.1:` and `http://[::1]:` were added later in the 1.6.x line. All variants share the same prefix-match weakness.\n\n### PoC\nAgainst the current latest release (1.7.2):\n\n```sh\npython3 -m venv venv\n./venv/bin/pip install \u0027authlib==1.7.2\u0027\n./venv/bin/python poc.py\n```\n\n`poc.py`:\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nis_secure_transport() must return True only for https:// URLs, or http://\nURLs whose host is a loopback address (localhost / 127.0.0.1 / ::1).\n\nBypass: http://localhost:80@evil.example/cb has host \u0027evil.example\u0027\n(userinfo = \u0027localhost:80\u0027) per RFC 3986, but matches the prefix\n\u0027http://localhost:\u0027 and is therefore accepted as secure.\n\"\"\"\nfrom urllib.parse import urlparse\nfrom authlib.common.security import is_secure_transport\n\ncases = [\n    \"http://localhost:80@evil.example/cb\",\n    \"http://127.0.0.1:80@evil.example/cb\",\n    \"http://localhost:@evil.example/cb\",\n]\n\nvulnerable = False\nfor url in cases:\n    parsed = urlparse(url)\n    ok = is_secure_transport(url)\n    print(f\"is_secure_transport({url!r}) = {ok}  \"\n          f\"[actual host = {parsed.hostname!r}, scheme = {parsed.scheme!r}]\")\n    if ok and parsed.hostname not in (\"localhost\", \"127.0.0.1\", \"::1\") and parsed.scheme != \"https\":\n        vulnerable = True\n\nif vulnerable:\n    print(\"\\nVULNERABLE: is_secure_transport() returned True for a plain-HTTP \"\n          \"URL whose host is NOT a loopback address.\")\nelse:\n    print(\"\\nNOT VULNERABLE\")\n\nassert vulnerable, \"expected bypass not observed\"\n```\n\nExpected output:\n\n```\nis_secure_transport(\u0027http://localhost:80@evil.example/cb\u0027) = True  [actual host = \u0027evil.example\u0027, scheme = \u0027http\u0027]\nis_secure_transport(\u0027http://127.0.0.1:80@evil.example/cb\u0027) = True  [actual host = \u0027evil.example\u0027, scheme = \u0027http\u0027]\nis_secure_transport(\u0027http://localhost:@evil.example/cb\u0027) = True  [actual host = \u0027evil.example\u0027, scheme = \u0027http\u0027]\n\nVULNERABLE: is_secure_transport() returned True for a plain-HTTP URL whose host is NOT a loopback address.\n```\n\n### Impact\nDeployments are affected if they rely on `is_secure_transport()` \u2014 directly or via the Authlib call sites listed above \u2014 to reject cleartext non-loopback URLs supplied by an external party. The most realistic path is an OpenID Provider that enables OIDC dynamic client registration and RP-Initiated Logout: a public client can register a `post_logout_redirect_uris` entry of the form `http://localhost:80@attacker.example/\u2026`, which the provider will later use as an open-redirect target over plain HTTP. Relying parties that call `AuthorizationServerMetadata.validate()` on fetched discovery documents are also affected, though exploiting that sink requires the attacker to influence the metadata document. This does **not** bypass the OAuth 2.0 redirect-URI exact-match registration check and does not by itself yield authentication bypass or token theft; it defeats a TLS-required hardening check.\n\n**Suggested fix:** Parse the URI with `urllib.parse.urlsplit()` and return `True` only if `scheme == \"https\"`, or `scheme == \"http\"` and `hostname in {\"localhost\", \"127.0.0.1\", \"::1\"}`; additionally reject any URI whose parsed `username`/`password` is non-empty at these validation sites.",
  "id": "GHSA-jj7h-c3hg-m23x",
  "modified": "2026-10-27T15:37:48Z",
  "published": "2026-10-27T15:37:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-jj7h-c3hg-m23x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114614"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/95ad1f90acf0c7b9cf2a8f25e6eb3f1135b8dc70"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/releases/tag/v1.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authlib: is_secure_transport() loopback exemption can be bypassed with a userinfo component, allowing cleartext-HTTP URLs to non-loopback hosts"
}

PYSEC-2026-4354

Vulnerability from pysec - Published: 2026-10-22 21:17 - Updated: 2026-10-30 09:33

Details

Severity

3.5 (Low)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N

Impacted products

Name	purl
authlib	pkg:pypi/authlib

Aliases

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {},
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib",
        "purl": "pkg:pypi/authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.13"
            },
            {
              "fixed": "1.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.13",
        "0.14",
        "0.14.1",
        "0.14.2",
        "0.14.3",
        "0.15",
        "0.15.1",
        "0.15.2",
        "0.15.3",
        "0.15.4",
        "0.15.5",
        "0.15.6",
        "1.0.0",
        "1.0.0a1",
        "1.0.0a2",
        "1.0.0b1",
        "1.0.0b2",
        "1.0.0rc1",
        "1.0.1",
        "1.1.0",
        "1.2.0",
        "1.2.1",
        "1.3.0",
        "1.3.1",
        "1.3.2",
        "1.4.0",
        "1.4.1",
        "1.5.0",
        "1.5.1",
        "1.5.2",
        "1.6.0",
        "1.6.1",
        "1.6.10",
        "1.6.11",
        "1.6.12",
        "1.6.2",
        "1.6.3",
        "1.6.4",
        "1.6.5",
        "1.6.6",
        "1.6.7",
        "1.6.8",
        "1.6.9",
        "1.7.0",
        "1.7.1",
        "1.7.2"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-114614",
    "GHSA-jj7h-c3hg-m23x"
  ],
  "details": "Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.13 until 1.8.0, authlib.common.security.is_secure_transport() uses a textual prefix comparison for loopback HTTP exemptions, so a URL whose userinfo begins with a loopback host can be accepted even when its parsed host is an external non-loopback system. An external party able to supply a URL to OIDC RP-Initiated Logout registration, authorization-server metadata validation, or another call site can bypass the TLS-required guard and cause cleartext redirection or acceptance of cleartext endpoints. The issue does not bypass redirect URI exact matching and does not by itself forge tokens or authenticate users. The vulnerable authlib.common.security.is_secure_transport() implementation in authlib/common/security.py misinterprets the userinfo component before OIDC RP-Initiated Logout dynamic client registration and other consumers enforce transport security. This issue is fixed in version 1.8.0.",
  "id": "PYSEC-2026-4354",
  "modified": "2026-10-30T09:33:49.280851Z",
  "published": "2026-10-22T21:17:16.683Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://github.com/authlib/authlib/releases/tag/v1.8.0"
    },
    {
      "type": "FIX",
      "url": "https://github.com/authlib/authlib/commit/95ad1f90acf0c7b9cf2a8f25e6eb3f1135b8dc70"
    },
    {
      "type": "EVIDENCE",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-jj7h-c3hg-m23x"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

BREW-KIMI-CLI-CVE-2026-114614 (GHSA-JJ7H-C3HG-M23X)

Summary

Details

PoC

Impact

CVE-2026-114614 (GCVE-0-2026-114614)

GHSA-JJ7H-C3HG-M23X

Summary

Details

PoC

Impact

PYSEC-2026-4354

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour