T09 · Insecure Skill Coding Practices
- Location
scripts/odps_is_query.sh:147- Finding
Custom SQL Validation Can Be Bypassed to Execute DDL or DML Statements
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is mainly a MaxCompute metadata helper, but it also includes poorly scoped paths that can run broader SQL or steer users toward mutating database operations.
Review before installing. Use this only with a least-privileged MaxCompute identity restricted to Information Schema reads, avoid the custom SQL mode, and do not rely on this skill for DDL/DML, table creation, data insertion, or broad environment enumeration unless you intentionally grant that authority. Treat outputs involving users, roles, privileges, job statements, client IPs, and project settings as sensitive administrative data.
scripts/odps_is_query.sh:147Custom SQL Validation Can Be Bypassed to Execute DDL or DML Statements
scripts/odps_is_query.sh:120Permission Audit Queries Use an Incomplete Table Join Key
The skill’s declared scope explicitly excludes ad-hoc SQL and broader execution, but the documentation references a custom SQL mode and odpscmd fallback that can execute user-supplied queries. That mismatch is dangerous because agents may trust the narrow description while still exposing a broader execution path, increasing the chance of unauthorized queries, policy bypass, or use of the skill for unintended database operations.
The reference explicitly documents create_table and insert_values capabilities even though the skill is described as metadata-only and not for DDL/DML. In an agent setting, embedded guidance often influences tool selection, so this can cause the skill to perform state-changing operations outside its declared safety boundary, leading to unauthorized data creation or modification.
The routing matrix instructs handling create table, insert data, and DDL/DML requests, directly contradicting the skill’s declared scope. This is especially dangerous because routing tables are high-authority decision aids for agents, so the skill may actively route destructive or privilege-affecting requests into execution paths rather than refusing them.
The script exposes a generic custom <sql> mode even though the skill is scoped to Information Schema metadata queries, and its validation only blocks obvious DDL/DML prefixes and SELECT *. That still allows arbitrary SELECT statements against non-Information-Schema objects, broad data exfiltration, expensive scans, and potentially multi-statement or dialect-specific bypasses if odpscmd accepts them.
The file states that the skill is only for Information Schema metadata queries, but later instructions broaden usage to general MCP and odpscmd operations. Such inconsistent guidance can mislead orchestration logic or human reviewers into granting trust based on a narrower purpose while the skill still facilitates broader execution patterns.
The documentation tells users to route non-Information-Schema tasks such as DDL/DML to odpscmd, which expands operational use beyond the skill’s stated safety boundary. Even if framed as fallback guidance, this can cause an agent to perform mutating or sensitive actions under the authority of a metadata-oriented skill, undermining least privilege and user expectations.
The documentation materially broadens the apparent scope of the skill beyond the stated manifest by advertising additional INFORMATION_SCHEMA targets such as UDFs, resources, packages, volumes, foreign servers, and security-label metadata. This can cause downstream agents or users to issue more sensitive metadata queries than intended, increasing exposure of privilege, labeling, and infrastructure details and undermining least-privilege expectations.
The documentation instructs use of MCP operations (list_tables, get_table_schema) even though the skill metadata explicitly says listing tables via MCP is out of scope. This creates a scope-bypass path where an agent may invoke broader discovery capabilities than intended, potentially exposing metadata outside the approved INFORMATION_SCHEMA-only workflow.
These examples normalize queries that enumerate admin users, role assignments, and permission exposure, which are sensitive security metadata. In an agent setting, providing such ready-made queries without warning or access-control guidance can facilitate reconnaissance and privilege mapping by unauthorized or over-broadly authorized users.
The project settings audit query exposes potentially sensitive configuration values such as backup retention, IP whitelist, and SQL cost limits. Publishing this as a routine example without caution increases the risk of configuration reconnaissance that could aid targeting, bypass planning, or exfiltration of internal security posture details.
The trigger examples and routing guidance are broad enough to capture requests beyond the intended read-only metadata use case, and they do not consistently state exclusions. In LLM-driven systems, ambiguous scope increases the chance of prompt-to-tool misrouting, including execution of unsupported or unsafe operations under this skill.
The CLI documentation includes a generic custom SQL mode, which broadens the skill from Information Schema metadata access to arbitrary query execution. Even if intended for convenience, this weakens scope boundaries and can enable access to non-IS data or facilitate risky commands if other controls fail or are bypassed.
The playbook explicitly directs use of MCP operations like list_tables and execute_sql as a 'Quick Path', which expands behavior beyond the stated skill scope of information-schema NL→SQL and even contradicts the manifest note 'NOT for ... listing tables via MCP'. Scope drift like this is dangerous because agents may follow the broader operational guidance instead of the manifest, resulting in unauthorized enumeration or ad-hoc data access paths.
The file repeatedly recommends list_tables even though the skill description expressly says it is 'NOT for ... listing tables via MCP'. This contradiction can cause an agent to bypass intended SQL-only metadata patterns and perform broader table enumeration, which is especially risky in multi-project or tenant-level catalog contexts.
The data transfer audit section encourages analysis of top downloads and client IP tracing without any caution about sensitive audit data handling, minimization, or authorization requirements. Because these queries can surface download activity and source IPs, omission of safety guidance raises the risk of unnecessary exposure of personal or security-sensitive telemetry.
This guidance introduces list_projects and list_schemas MCP operations that are not described in the skill metadata and broaden the skill into environment enumeration. In a metadata-access skill, undocumented project/schema discovery increases the chance of over-collection and access to tenant structure beyond the user's intended question.
This reference documents queries over highly sensitive metadata surfaces, including user identities, role assignments, privilege grants, client IPs, scheduler metadata, and raw job statements (operation_text), but it does not warn users that these views can expose security-relevant and potentially regulated information. In the context of an NL→SQL skill, omission of these cautions increases the chance that the agent will generate and return broad metadata queries that over-disclose internal access patterns, identities, and workload details to users who may not expect the sensitivity of the results.
The manifest says the skill is not for listing tables via MCP, yet the script documents MCP tools such as list_tables and also implements tables/top-storage listing queries itself. This indicates the skill behavior includes direct table enumeration capabilities that are broader than the narrowly framed information-schema NL→SQL purpose and blur the declared boundary around table listing channels.
The script forwards user-supplied custom SQL directly to odpscmd via a subprocess without any interactive warning, approval gate, or strong scope validation. In an agent context, that increases the chance of unintended execution of broad or sensitive queries, especially because the command is presented as a helper for metadata access but can issue more expansive reads.
The placeholder rules explicitly state that '' should be avoided due to incomplete data risk, yet the cost spike queries filter on both yesterday and today. This is an active contradiction between the file's own guidance and its example query behavior, which could mislead users performing causal analysis.
Throughout the playbooks, intent signals are hard-coded in Chinese and English, but the document does not explain whether users may choose their preferred language or how locale handling works. This can create an implicit language policy without explicit user opt-in or documentation.
No suspicious patterns detected.