Using AI to Uncover a Long‑Hidden OAuth Combo Vulnerability

Introduction

This vulnerability was discovered in a protected network. The author spent a day reproducing the exact environment locally for learning purposes.

1. Initial Testing

Weak‑password login attempts : Accessed the target system’s login page and tried common weak passwords.

Captcha functionality test : Tested the captcha login and observed the related network packets.

2. Information Gathering and Configuration Leak

In the login request packet, a grant_type parameter was observed, indicating the target uses the OAuth 2.0 authentication framework.

The OAuth 2.0 client‑credential flow requires client_id and client_secret. A direct search in the front‑end source code returned no results, and the browser’s developer‑tool search across all loaded JS files also found nothing.

After traversing every JavaScript file, api.js was found to contain many interface definitions. In the directory index, a commented JavaScript file was discovered.

Visiting the commented file revealed the OAuth 2.0 configuration, including the client_id and client_secret.

3. Credential Validity Verification

Using the request parameters from loginController.js, a request was crafted with the leaked client credentials.

The client_credentials grant type is intended for server‑to‑server (machine‑to‑machine) authentication without user involvement.

A token was obtained, but when the token was added to request headers and an API was called, the response indicated “no permission”. The password grant type also failed because no user credentials existed in the system.

Inspecting api.js revealed a registration endpoint. By registering a user and then authorising that user via the password mode, a token with higher privileges could be obtained.

4. Register User and Attempt Privilege Escalation

In the test environment, packet capture showed the username and password parameters.

Direct registration created a normal account (roleType=GUEST).

The OAuth password mode was used to grant permissions to the registered account.

Accessing the personal user interface with the returned id and token succeeded, but when accessing the “all users” interface the response showed low permissions, indicating a distinction between normal and admin privileges.

5. Find Administrator Registration Method

In main.js the mapping between permission IDs and roles is defined.

All registrations require an ownerId parameter. By providing an ownerId that corresponds to an admin role, an administrator account was created.

After re‑assigning OAuth permissions, the previously 403‑blocked interface could be accessed successfully.

6. Vulnerability Summary

Front‑end JavaScript contained a commented block exposing OAuth client credentials ( client_id and client_secret), which can be directly retrieved.

The registration endpoint allows creation of high‑privilege (admin) accounts by specifying an ownerId parameter.

The system relies on front‑end parameters for permission control; the back‑end does not enforce strict validation.

Attack path: leaked credentials → register normal account → obtain low‑privilege token → discover admin ownerId → register admin account → obtain high‑privilege token → access restricted APIs.

7. AI‑Automated Penetration Test Comparison

The author evaluated three AI‑driven penetration approaches on the same vulnerability.

Approach 1: AI agent autonomous penetration

Used the GLM 5.1 model to perform web testing without port scanning. Screenshots show key steps, but the process got stuck while searching for privilege‑escalation interfaces and ended without full exploitation.

Approach 2: GLM 5.1 + chrome‑devtools‑mcp

Installed Node.js and the chrome-devtools-mcp extension, added a few lines of configuration code, and enabled the “allow” button. After four prompts the vulnerability was fully reproduced.

Approach 2.1: DeepSeek v4 pro + chrome‑devtools‑mcp

Spent $10 on DeepSeek v4 pro. The model discovered a bug in the GLM 5.1 testbed, perfectly escalated privileges, whereas GLM itself missed the backend issue. After fixing the bug, the test no longer succeeded, requiring four prompts again.

Approach 3: AI agent + skill

A custom skill (illustrated in the following images) was defined for the AI agent. The result was poor, achieving only about 10% effectiveness.

Overall experiment results: AI still struggles with multi‑step logical vulnerabilities; foreign models have not been tested yet.