Back to skill

Security audit

Hologres Slow Query Analysis

Security checks for vulnerabilities and agentic risk

Overview

This skill is a coherent Hologres troubleshooting guide, but it normalizes powerful database privilege changes and broad query-log exports without enough safeguards.

Install only for authorized Hologres administrators. Prefer read-only/statistics access over SUPERUSER, avoid running privilege or ALTER DATABASE commands unless explicitly approved and reversible, pin and isolate hologres-cli before use, and treat query logs as sensitive data when viewing or exporting them.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:9
Finding
Unpinned Third-Party CLI Installation Creates a Supply-Chain Risk## Vulnerability Details **File Location**: `SKILL.md`, lines 9-18 **Vulnerability Type**: Unpinned third-party dependency installation **Risk Level**: Medium ### Vulnerable Code ```markdown ## Prerequisites This skill requires **hologres-cli** to be installed first: ```bash pip install hologres-cli export HOLOGRES_SKILL=hologres-slow-query-analysis ``` All SQL execution and GUC parameter operations depend on `hologres-cli` commands (`hologres sql run`, `hologres guc set`). ``` ### Technical Analysis The skill directs users or agents to install `hologres-cli` without specifying an exact version, package hash, or trusted package index. Consequently, the installed artifact is determined at execution time rather than audit time. If a future release of the package is compromised, its publisher account is taken over, or package resolution is redirected to an attacker-controlled repository, installation may execute attacker-controlled package build or installation logic. The risk is increased because all subsequent SQL and configuration operations are delegated to this CLI, making the installed package part of the skill's trusted execution path. No malicious dependency payload is included in the audited project itself. The vulnerability is the unsafe, mutable dependency installation procedure. ### Attack Path 1. An attacker compromises the upstream `hologres-cli` distribution channel, publisher account, or package source used by the victim's Python configuration. 2. The attacker publishes a malicious version under the expected package name. 3. A user or agent follows the documented `pip install hologres-cli` command. 4. `pip` resolves and installs the attacker-controlled release because no version or integrity constraint is present. 5. Malicious installation hooks or CLI runtime code execute with the privileges of the account performing the installation. 6. Later `hologres` commands may capture database creden ...[truncated 663 chars]
Remediation
## Remediation Suggestions 1. Pin `hologres-cli` to a reviewed exact version, for example: ```bash python -m pip install 'hologres-cli==REVIEWED_VERSION' ``` 2. Use a locked requirements file containing cryptographic hashes and install with hash verification: ```bash python -m pip install --require-hashes -r requirements.txt ``` 3. Explicitly configure an approved package index rather than relying on ambient `pip` configuration. 4. Verify package provenance, signatures, publisher ownership, and release hashes before updating the pinned version. 5. Install the CLI in an isolated virtual environment with minimum operating-system privileges. 6. Review each dependency update before changing the lock file, and run dependency and malware scans on the resolved artifacts. 7. Avoid executing package installation automatically when the skill is loaded; require explicit user approval.

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:35
Finding
Documentation Recommends Granting Database Superuser Privileges for Log Analysis## Vulnerability Details **File Location**: `SKILL.md`, lines 35-46 **Vulnerability Type**: Excessive database privilege grant **Risk Level**: High ### Vulnerable Code ```sql -- Superuser: view all DB logs ALTER USER "cloud_account_id" SUPERUSER; -- Or join pg_read_all_stats group GRANT pg_read_all_stats TO "cloud_account_id"; -- For current DB only (SPM model) CALL spm_grant('<db_name>_admin', 'cloud_account_id'); ``` ### Technical Analysis The first permission-check workflow recommends changing an analysis identity into a database superuser merely to read query logs. Superuser access is substantially broader than the permissions required for slow-query diagnosis and violates least-privilege principles. A database superuser can generally bypass ordinary authorization boundaries and perform administrative actions unrelated to log inspection. Although less severe than `SUPERUSER`, granting a database administration role through `spm_grant('<db_name>_admin', ...)` may also provide unnecessary write or administrative capabilities when read-only statistics access is sufficient. The same snippet already presents `pg_read_all_stats` as a narrower alternative, demonstrating that unrestricted superuser access is not inherently required for the documented task. The instructions also do not include an approval checkpoint, a temporary elevation mechanism, or a command to revoke the granted role after diagnosis. ### Attack Path 1. An operator follows the skill's quick-start instructions to diagnose slow queries. 2. The operator replaces `cloud_account_id` with the diagnostic or automation identity and executes `ALTER USER ... SUPERUSER`. 3. The identity retains superuser privileges after the diagnostic session because no revocation step is documented. 4. An attacker compromises that identity, obtains its credentials, or abuses an existing session belonging to it. 5. The attacker uses the excessive database pr ...[truncated 1090 chars]
Remediation
## Remediation Suggestions 1. Remove `ALTER USER "cloud_account_id" SUPERUSER` from the standard diagnostic workflow. 2. Make a dedicated, read-only diagnostic identity the recommended approach. 3. Grant only the minimum supported permission required to read query statistics, such as `pg_read_all_stats`, when its scope is acceptable. 4. When access must be limited to one database, document the narrowest read-only SPM role instead of a general database administrator role. 5. Require explicit administrator approval before granting any instance-wide statistics access. 6. Document revocation commands and require privileges to be removed immediately after temporary troubleshooting access is no longer needed, for example: ```sql REVOKE pg_read_all_stats FROM "cloud_account_id"; ALTER USER "cloud_account_id" NOSUPERUSER; ``` 7. Separate the operator's normal account from the diagnostic account, use short-lived credentials where available, and audit all grants and diagnostic access. 8. Warn users that query logs can contain sensitive SQL text, identifiers, client addresses, and error messages, and restrict exported results accordingly.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (8)

Description-Behavior Mismatch

High
Confidence
97% confidence
Finding
The permission setup includes granting SUPERUSER and broad stats roles to an account, which is a privilege-escalating action unrelated to narrow slow-query analysis. In an agentic context, documenting these steps without strong guardrails can normalize or trigger excessive privilege grants, enabling broad database compromise if misused.

Vague Triggers

Medium
Confidence
92% confidence
Finding
The trigger phrase 'query diagnosis' is broad enough to match many routine database-performance requests, increasing the likelihood this skill is invoked in contexts beyond Hologres slow-query log review. Because the skill also contains privileged and state-changing instructions, broad activation raises the chance those operations are surfaced or suggested inappropriately.

Description-Behavior Mismatch

Medium
Confidence
94% confidence
Finding
The skill is presented as an analysis/log-management skill, but it explicitly states that execution and GUC operations depend on CLI commands that can run SQL and change settings. That expands the operational scope from read-only diagnosis into state-changing administration, which increases the chance an agent could perform unintended writes or config changes under the guise of analysis.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill documents privilege-changing operations like SUPERUSER assignment and role grants without clear warnings, impact statements, or strong least-privilege guidance. In practice, this can lead operators or agents to apply dangerous permission changes as routine setup, unnecessarily expanding attack surface and blast radius.

Description-Behavior Mismatch

Medium
Confidence
96% confidence
Finding
The configuration section instructs users to change database and session parameters, including logging thresholds and retention, which are write operations that alter system behavior. For a skill whose main purpose is diagnosis, embedding mutating commands increases the risk of unintended operational impact, such as excessive logging, retention changes, or policy drift.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The documented query returns `usename` and full `query` text from `hologres.hg_query_log`, which can expose sensitive SQL, embedded literals, business data references, and user-identifying information to anyone using the skill without any warning or minimization guidance. In a diagnostic skill, this is especially risky because operators may run the query broadly during troubleshooting and then copy, share, or store the results in tickets, chats, or logs, increasing privacy and data-leakage exposure.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The document instructs users to export `hg_query_log` contents, which can include full SQL text, error messages, client metadata, and table access details, into other tables without any warning about sensitive data handling, retention, or access control. In a log-analysis skill, this is risky because operators may routinely move highly sensitive workload data into broader-access storage, increasing exposure of credentials, PII embedded in queries, or proprietary business logic.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The MaxCompute export workflow moves query log data from Hologres into an external system, but the guide does not warn that this is a cross-system transfer of potentially sensitive operational data. Because the exported fields include raw query text, plans, messages, and table metadata, this materially expands the attack surface and can create compliance, confidentiality, and over-retention risks if the external environment has different access policies.

Static analysis

No suspicious patterns detected.