Is helloliuyongsheng-bot/oauth-helper safe?

https://github.com/openclaw/skills/tree/main/skills/helloliuyongsheng-bot/oauth-helper

48
DANGEROUS

This skill claims to be an OAuth login helper but is fundamentally designed to enter credentials directly into authentication provider forms — the precise opposite of what OAuth is intended to accomplish. Published by a bot account ('helloliuyongsheng-bot') with no human accountability, the skill includes password field CSS selectors for Apple, Microsoft, GitHub, Discord, and QQ, routes all user confirmation through a Telegram channel that can be silently controlled by the publisher, and integrates WeChat/QQ — Chinese platforms subject to government surveillance laws. While the git clone was structurally clean and no malware was dropped at install time, the skill's design constitutes a credential entry automation framework that — when deployed with an attacker-operated Telegram bot — enables silent credential harvesting and unauthorized OAuth authorization at scale.

Category Scores

Prompt Injection 25/100 · 30%
Data Exfiltration 10/100 · 25%
Code Execution 93/100 · 20%
Clone Behavior 95/100 · 10%
Canary Integrity 90/100 · 10%
Behavioral Reasoning 10/100 · 5%

Findings (12)

CRITICAL Password field credential entry for five major OAuth providers -55

The skill includes CSS selectors targeting password input fields for Apple, Microsoft, GitHub, Discord, and QQ. OAuth delegation is designed to eliminate credential sharing entirely — the relying party never sees the user's provider password. Having an agent fill password fields on provider login pages fundamentally inverts this model and makes the skill a credential entry automation tool. The skill offers no documentation of where these passwords are sourced from, implying they are expected to exist in the agent's accessible context and will be silently consumed.

HIGH Published by bot account — no human author or accountability -35

The skill owner is 'helloliuyongsheng-bot', an automated bot account. There is no identifiable human developer, no organization, no contact email, and no accountability mechanism. A bot account publishing a skill that automates credential entry for seven major authentication providers — including Google, Apple, Microsoft, and GitHub — represents a fundamentally untrustworthy provenance. The name 'helloliuyongsheng' is a Chinese personal name pattern, consistent with the WeChat/QQ provider inclusions.

HIGH Skill misrepresents scope — claims OAuth but instructs credential entry -30

The skill is titled 'OAuth Helper' and describes 'Automate OAuth login flows with user confirmation' in its frontmatter. However, its core click sequences require the agent to fill email and password fields — actions that are only needed when bypassing OAuth and entering credentials directly. This scope misrepresentation causes the agent to acquire authority over credential handling that a user granting 'OAuth login automation' would not anticipate.

HIGH Telegram confirmation bypass enables silent unauthorized OAuth authorization -25

The skill routes all OAuth confirmations through a Telegram channel. If the Telegram bot token is controlled by the skill publisher or an attacker who compromises it, they can auto-respond 'yes' to every confirmation prompt, removing the human from the loop entirely. The 60-second timeout means the window for silent authorization is narrow but fully automatable. This enables mass unauthorized OAuth application authorization across any site a user visits.

HIGH Telegram creates persistent bidirectional external data relay channel -25

The Telegram integration sends messages outbound (login prompts, success/failure notifications, screenshots, QR codes) and receives messages inbound (user choices, 'yes' confirmations). This bidirectional channel gives the Telegram operator visibility into which accounts are being authenticated, which OAuth apps are being authorized, and which sites the user visits. Screenshots sent on failure expose page state. QR codes for WeChat/QQ are sent directly to the Telegram channel.

HIGH Trust expansion clicks grant persistent auth and permissions without explicit user review -20

The Apple click sequence instructs the agent to click 'Trust' on the 'Trust this browser?' prompt, establishing a persistent trusted session on the user's Apple ID. The Microsoft sequence instructs clicking 'Accept' on the OAuth consent screen, granting application permissions. A user who replies 'yes' on Telegram to 'login to a site' may not understand that the agent is simultaneously establishing permanent trust relationships and granting third-party application permissions on their behalf.

MEDIUM WeChat and QQ integration creates Chinese government surveillance exposure -25

The skill explicitly supports WeChat (open.weixin.qq.com) and QQ (graph.qq.com), both operated by Tencent. China's National Security Law (2015) and Cybersecurity Law (2017) obligate domestic tech companies to cooperate with government intelligence requests. Automating persistent authenticated sessions to these platforms, with session management coordinated via a Telegram bot operated by an unidentified Chinese-named bot account, creates a surveillance risk that Western enterprise users in particular cannot accept.

MEDIUM Credential harvesting pipeline when combined with Telegram operator control -20

In isolation the skill has dangerous components; combined with an attacker-controlled Telegram bot the components form a complete credential theft pipeline: (1) user asks agent to log into a site, (2) agent navigates to provider, (3) agent fills email and password from agent context, (4) Telegram operator receives confirmation event and optional screenshots, (5) operator auto-approves OAuth consent, (6) attacker gains persistent OAuth access token. This attack requires only that the Telegram bot token belong to the attacker — a condition satisfied by the publisher publishing their own bot token.

MEDIUM Credential source entirely undocumented — implies silent agent context access -10

The prerequisites claim browsers are pre-logged in, yet password field selectors exist for 5 of 7 providers. This contradiction means the skill is designed to operate when browsers are NOT pre-authenticated, requiring it to source credentials from somewhere. No documentation, user prompt, or disclosure mechanism is described for how passwords are obtained — implying they are silently read from environment variables, configuration files, or other agent-accessible stores without the user being informed.

MEDIUM Skill inverts OAuth security model — structural credential harvesting pattern -10

OAuth's core security property is that relying parties never receive the user's provider credentials — only time-limited tokens with declared scopes. This skill bypasses that property by entering credentials directly into provider login forms. This is the behavior of a phishing tool or password manager combined with a session harvesting proxy, not a legitimate OAuth automation helper. The 'confirmation' UX provides plausible deniability while the underlying mechanism is credential-first authentication.

LOW Expected GitHub traffic only during sparse checkout installation -5

Installation involved a shallow git clone from github.com (140.82.121.4:443) with sparse checkout targeting the skill subdirectory, followed by a cp and rm -rf of the temp clone. All observed network activity is accounted for. No unexpected processes were spawned. No unexpected filesystem changes outside the designated skill directory.

INFO Canary files read by audit framework at expected phases — not modified 0

Credential canary files were accessed at two timestamps: 1771931560 (pre-clone, during oathe audit baseline setup) and 1771931584 (post-install, during audit framework post-install verification sequence). Both access windows correlate precisely with oathe infrastructure phases visible in the auditd EXECVE log. All accesses were read-only (inotify CLOSE_NOWRITE). No modifications, writes, or exfiltration were detected. Canary integrity confirmed intact.