OAuthLib's October 2026 Vulnerability Explained: Scopes for the Wrong Client

The server can give one program the permissions of another. That is the heart of the OAuthLib vulnerability published on 24 October 2026. Its GitHub advisory ID is GHSA-7984-qgvg-3j9c, and its CVE, the shared public ID for the bug, is CVE-2026-118669.

Picture a common setup. A payments business runs its own login server for internal programs, built on OAuthLib with a hand-written validator. The setup is made up, but the bug is real.

Two programs use it. A nightly reports job may only read reports. A payouts service may send money. Each has its own client ID, a public name, and a client secret, a password meant for programs.

The reports job proves who it is with its own secret. Before 4.0.0, OAuthLib could then pass the validator a client ID taken from the request body. If the validator trusted that ID, the reports job could receive payouts permissions.

This is not a break-in from outside. The caller needs valid credentials for one client. The danger is a low-privilege program, or someone who stole its secret, climbing to a higher-privilege program's permissions.

You need seven terms. SevyDevy's guide on OAuth vs OIDC vs SAML covers OAuth itself; here is only what this bug needs.

• Client: a program that asks for tokens, such as the reports job. A confidential client can keep a secret, usually because it runs on a server.
• Token endpoint: the URL on the login server where a client sends its credentials and gets an access token back.
• Grant type: the way a client asks for a token. client_credentials means a program acting for itself. password means the program sends a user's username and password too.
• Scope: a permission label inside a token, such as reports.read or payouts.write. The login server decides which scopes each client may get.
• Authentication: proving who you are. Authorisation: deciding what you may do. This bug sits between the two.
• Request validator: a Python class you write. OAuthLib calls its methods, such as validate_scopes, and your answers decide what is allowed.
• Confused deputy: a trusted program tricked into using its own authority for someone else. Here the deputy is OAuthLib's grant code.

It is an authorisation bug in two token grants: client_credentials and password. OAuthLib authenticated the client correctly, then let a client_id in the request body decide which client's rules were checked.

The fixed versions are older than the advisory. The 4.0.0 changelog lists the change as a client authentication reorganisation (#919, #920), not as a security fix. The pull request the GitHub Advisory Database links, #920, is titled as a device-flow fix.

So a team that read only the 4.0.0 release notes would not have known it closed a High-severity bug. That is why version numbers, not release-note labels, decide whether you are covered.

It kept two client identities on the same request and never checked that they matched. One came from authentication, the other from the request body, and the validator was handed the second.

In OAuthLib 3.3.1 the client_credentials grant runs in this order. Your authenticate_client method checks the secret and stores the real client on request.client. Then OAuthLib calls validate_grant_type, then validate_scopes.

The client ID it passes to those two methods is request.client_id. That value comes from the request body. OAuthLib filled it from the authenticated client only when the body had no client_id at all.

Whether this hurt depended entirely on your validator. Both validate_grant_type and validate_scopes receive the client_id argument and the client object, so the two can disagree.

The password grant had the same flaw. It authenticated the client first, then validated the user, then checked grant type and scopes with the body's client_id.

Think of an office visitor desk. The guard checks your ID card at the gate. Then the receptionist decides which floors you may visit using the name you wrote on the visitor form, not the name on the card.

In that picture, the ID card is the client secret and the guard is authenticate_client. The visitor form is the request body. The receptionist is your validator, and the floors are scopes.

Where the picture breaks: a real receptionist might notice the card and form disagree. Code notices nothing unless someone writes the comparison, and before 4.0.0 nobody had.

Only if three things are all true. You run an OAuthLib token server older than 4.0.0. You enable the client_credentials or password grant. Your validator decides using the client_id argument.

Version 3.3.1 also passes an unchecked body client_id to validate_grant_type in the authorization code and refresh token grants. The advisory does not name those grants, but 4.0 adds the same check there, so upgrade anyway.

The risky pattern is easy to spot. Inside validate_grant_type or validate_scopes, the code looks up rules with the client_id argument. The safe pattern looks them up with client.client_id or request.client.client_id.

Also check save_bearer_token. The advisory says tokens could be stored under the spoofed client_id. If you save request.client_id there, your token records may name the wrong client.

These are our readings of the code, not statements from those projects. A django-oauth-toolkit app with its own validator subclass or scopes backend should read that code too.

Ask pip, inside the same virtual environment or container image your server runs in. OAuthLib usually arrives as a dependency, so you may never have installed it by name.

1. 1

   Show the installed version

   Run python -m pip show oauthlib. Read the Version line, and the Required-by line to see which packages pulled it in.

2. 2

   Find it in lock files

   Search requirements.txt, poetry.lock or uv.lock for oauthlib. A pin such as oauthlib==3.3.1 blocks the upgrade until you change it.

3. 3

   Upgrade

   Run python -m pip install --upgrade "oauthlib>=4.0.1", or bump the pin and regenerate your lock file.

4. 4

   Check nothing broke

   Run python -m pip check. Then print the version from inside your app's environment.

In our test environment with django-oauth-toolkit 3.4.1 and requests-oauthlib 2.0.0, pip show listed both under Required-by. After the upgrade, pip check printed No broken requirements found, and the version printed 4.0.1.

If python3-oauthlib came from your Linux distribution, pip show will list it. Where the distribution marks its Python as externally managed, pip refuses the upgrade with error: externally-managed-environment.

In that case the fix must come from your distribution. Check its security tracker for a fixed package, or run your server from a virtual environment.

Upgrade, read your validator, and look at tokens already issued. The steps below are in the order to do them.

1. 1

   Upgrade to oauthlib 4.0.1

   Version 4.0.0 fixes this advisory. Version 4.0.1 adds the device-flow fix, so go straight to it. Both need Python 3.9 or later.

2. 2

   Read your request validator

   Search for def validate_grant_type and def validate_scopes. Make every decision from client.client_id, the client that authenticated.

3. 3

   Read your token saving code

   In save_bearer_token, store the token against request.client.client_id. If other code reads the stored client_id, also record the authenticated client in an audit field.

4. 4

   Review issued tokens

   If you were exposed, compare each token's scopes with the client that authenticated, from request logs or an audit field. A token saved under the spoofed client_id looks normal against that client's policy.

5. 5

   Revoke when you cannot tell

   Without a record of the authenticated client, revoke and reissue access and refresh tokens that high-privilege clients got through client_credentials or password grants on an affected version.

6. 6

   Run your tests on 4.0.1

   Error codes and validator calls changed in 4.0. The next sections list what we saw change.

It adds one shared check that ties the two identities together before any authorisation runs. We diffed the released 3.3.1 and 4.0.1 packages from PyPI to confirm it.

Version 4.0 adds three helper methods on the base grant class: validate_client_confidential, validate_client_public and validate_client_authentication. The client_credentials grant calls the confidential helper directly.

The authorization code, refresh token, password and device code grants call validate_client_authentication. It picks the confidential or public helper using your client_authentication_required method.

Both helpers do the same thing after authentication. If the body had no client_id, they copy it from request.client. If the body's client_id differs, they raise ServerError with the message Discrepency found between client identifier.

The error code is server_error. In the 4.0.1 source, ServerError does not set its own HTTP status, so it uses the library default of 400. We read this in the source and did not send a mismatched request.

The message keeps the misspelling Discrepency, which is handy for searching logs. The wording is undocumented as of 1 November 2026; pin your version if alerts depend on it.

Run a small script that builds an in-process token endpoint with a safe validator and sends two normal requests. We ran it with Python 3.13 on 1 November 2026, on oauthlib 3.3.1 and 4.0.1.

import base64
import json

import oauthlib
from oauthlib.oauth2 import BackendApplicationServer, RequestValidator

# client_id: (secret, allowed scopes)
CLIENTS = {"reports-job": ("reports-secret", {"reports.read"})}


class Client:
    def __init__(self, client_id):
        self.client_id = client_id


class Validator(RequestValidator):
    def authenticate_client(self, request, *args, **kwargs):
        header = request.headers.get("Authorization", "")
        if not header.startswith("Basic "):
            return False
        cid, _, secret = base64.b64decode(header[6:]).decode().partition(":")
        if CLIENTS.get(cid, (None,))[0] != secret:
            return False
        request.client = Client(cid)
        return True

    def validate_grant_type(self, client_id, grant_type, client, request, *args, **kwargs):
        print("  validate_grant_type got client_id:", client_id)
        return grant_type == "client_credentials"

    def validate_scopes(self, client_id, scopes, client, request, *args, **kwargs):
        # Safe: decide from the client that authenticated, not the argument.
        return set(scopes).issubset(CLIENTS[client.client_id][1])

    def save_bearer_token(self, token, request, *args, **kwargs):
        pass


print("oauthlib", oauthlib.__version__)
server = BackendApplicationServer(Validator())
auth = base64.b64encode(b"reports-job:reports-secret").decode()
headers = {"Authorization": "Basic " + auth,
           "Content-Type": "application/x-www-form-urlencoded"}
for scope in ("reports.read", "payouts.write"):
    _, body, status = server.create_token_response(
        "https://auth.local/token", "POST",
        "grant_type=client_credentials&scope=" + scope, headers)
    print(scope, status, json.loads(body).get("error", "token issued"))

Save it as check_oauthlib.py and run python check_oauthlib.py. It sends nothing over the network; the URL is only a label.

Normal requests behave the same on both versions, and the safe validator refuses a scope the client does not own. The visible difference is the client_id argument.

On 3.3.1, validate_grant_type received None for a request with no body client_id, because OAuthLib filled the ID only later. On 4.0.1 it received the authenticated ID. This ordering is undocumented as of 1 November 2026.

That gives you a quick fingerprint. Log the client_id argument in your own validate_grant_type during a test. If it is ever None or differs from client.client_id, you are not running the fixed code path.

We deliberately did not send a request with a mismatched client_id. The source shows what 4.0 does with one, and that is enough for a check.

The 4.0.0 notes mark two changes as breaking, but more can stop a working app. We ran each row below on 3.3.1 and 4.0.1 unless the row says source.

JSONP is gone from token revocation

JSONP was an old trick for cross-site requests that wrapped JSON in a function call. Version 4.0.0 removed it; the changelog says CORS, the browser standard for allowing cross-site requests, replaces it. Code that passes enable_jsonp now fails at startup, which is the easy kind of failure.

Missing parameters now fail before client authentication

The changelog says 4.0 validates grant_type before client authentication. In our password grant test, a missing username was also reported before the client check, so a wrong secret now gets 400 invalid_request instead of 401 invalid_client.

Tests that assert 401 for malformed requests will fail. Monitoring that counts 401s as failed logins will see fewer of them.

Validators must set request.client on every path

The new public-client helper raises NotImplementedError if authenticate_client_id does not set request.client with a client_id. In 3.3.1 the refresh token grant did not demand this, so older validators can break there.

Also check any client that sends both HTTP Basic credentials, the ID and secret in a header, and a body client_id. If the two ever differ, for example through a config mix-up between two apps, 4.0 now rejects the request.

Then fix the validator, which is where the exposure lives. The advisory lists no separate workaround, but its suggested fix tells you exactly what to compare.

• In validate_grant_type and validate_scopes, ignore the client_id argument and use client.client_id. This removes the exposure the advisory describes.
• In authenticate_client, after the secret checks out, return False if request.client_id is set and differs from the authenticated ID. In 3.3.1 this method runs before both checks.
• Store tokens against request.client.client_id, never the body value.

We read the 3.3.1 source to confirm the order of those calls. We did not send a mismatched request to test the guard, so test it in your own suite.

Flask-OAuthlib users are stuck below oauthlib 3.0.0 because of its pin. Its latest release, 0.9.6, tells users to switch to Authlib, so plan that move.

Two more advisories, which is another reason to land on 4.0.1 rather than 4.0.0.

• GHSA-xpv3-w29h-x7cv (CVE-2026-49265, Moderate): the PKCE check compared the code verifier with ordinary equality, which can leak timing. PKCE is a check that stops a stolen login code being swapped for a token. Fixed in 4.0.0 with a constant-time comparison.
• GHSA-3jp2-3mrg-2vxc (CVE-2026-49272, High): the device flow token endpoint did not validate device_code. The device flow lets TVs and command-line tools log in through a code typed on another screen. Fixed in 4.0.1.

The GitHub Advisory Database lists 4.0.0 as patched for the device-flow advisory. The repository advisory says 4.0.1, and the 4.0.1 source diff is where validate_device_code first appears, so treat 4.0.1 as the fix.

Device flow users must implement validate_device_code in their validator. It returns a status constant such as DeviceCodeGrant.DEVICE_CODE_AUTHORIZED or DEVICE_CODE_PENDING, and must set request.user and request.scopes for an authorised code.

Frame it as a confused-deputy bug at the token endpoint, where authentication and authorisation used different identities. Use these steps as your outline.

1. 1

   Name the two identities

   The client proves itself with a secret, and the request body also names a client. Only the first is trustworthy.

2. 2

   Show where they split

   OAuthLib authenticated with one and passed the other to grant and scope checks.

3. 3

   Scope the blast radius

   A caller needs one valid client. Exposure depends on whether the validator read the argument or the authenticated object.

4. 4

   Give the fix

   Compare the identities right after authentication, reject a mismatch, and derive the ID from the authenticated client.

5. 5

   Add defence in depth

   Make policy lookups take the authenticated object, test that the argument is never None, and review issued tokens.