aliyun-oidc-cert-renew

• Outcome: Review
• Latest audit: Sep 13, 2026 · 8:46 AM UTC
• Version: 0.1.0

Overview

The skill appears purpose-built for Alibaba Cloud certificate automation, but its defaults can grant broad cloud access and overly broad GitHub OIDC trust, so it should be reviewed before use.

Install only after narrowing the RAM policy to exact required APIs and resources, replacing the wildcard OIDC subject with exact allowed subjects where possible, pinning dependencies, and ensuring only trusted workflow steps run after STS credentials are written to GITHUB_ENV. Treat this as production infrastructure automation, not a generic SSL helper.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (4)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: scripts/setup_oidc.py:108
• Finding: Overly Broad GitHub OIDC Subject Pattern Permits Unintended Repositories<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup_oidc.py`, lines 108-109 **Vulnerability Type**: Overly broad federated identity trust policy **Risk Level**: High ### Vulnerable Code ```python 'StringLike': {'oidc:sub': 'repo:%s*/%s*:ref:refs/heads/%s' % (owner, repo, branch)}, ``` ### Technical Analysis The generated Alibaba Cloud RAM trust policy places wildcards immediately after both the expected GitHub owner and repository names. This creates prefix matching rather than restricting role assumption to one exact repository. For example, a configuration intended for owner `acme` and repository `certs` produces a pattern equivalent to: ```text repo:acme*/certs*:ref:refs/heads/main ``` This may also match subjects associated with similarly prefixed identities, such as: ```text repo:acme-attacker/certs-copy:ref:refs/heads/main ``` The audience and issuer checks do not independently establish that the token belongs to the exact intended repository. GitHub workflows can request a custom audience, so accepting the configured audience does not compensate for an overly broad `sub` condition. ### Attack Path 1. The victim runs `setup_oidc.py` and creates a RAM role using the wildcard subject condition. 2. An attacker creates or controls a GitHub owner and repository whose names share the configured prefixes. 3. The attacker creates a workflow on the configured branch. 4. The workflow requests a GitHub OIDC token using the audience accepted by the Alibaba Cloud OIDC provider. 5. The token contains the legitimate GitHub issuer and requested audience, while its subject matches the prefix-wildcard condition. 6. The attacker submits the token to Alibaba Cloud `AssumeRoleWithOIDC`. 7. If Alibaba Cloud evaluates the subject as matching, it returns temporary STS credentials for the victim's role. ### Impact Assessment Successful exploitation grants the attacker all permissions attached to the OIDC role. With the defa ...[truncated 441 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Use an exact repository subject whenever possible: ```python 'StringEquals': { 'oidc:iss': ISSUER, 'oidc:aud': audience, 'oidc:sub': 'repo:%s/%s:ref:refs/heads/%s' % (owner, repo, branch), } ``` Additional hardening measures: 1. Avoid prefix wildcards for owner, repository, branch, environment, and workflow identity fields. 2. If multiple subject formats must be supported, enumerate separately verified exact subject values. 3. Consider restricting tokens through a protected GitHub environment and matching its exact environment-based subject. 4. Protect the authorized branch and workflow files with branch protection and mandatory review. 5. Test the resulting trust policy with both accepted and intentionally similar rejected subjects before deployment. 6. Rotate or revoke the role and review cloud audit logs if the broad policy has already been deployed. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: scripts/setup_oidc.py:125
• Finding: Default RAM Policy Grants Account-Wide Wildcard Permissions<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup_oidc.py`, lines 125-126 **Related Location**: `scripts/setup_oidc.py`, line 42 **Vulnerability Type**: Excessive cloud permissions and failure to enforce least privilege **Risk Level**: High ### Vulnerable Code The default action list grants every operation in four Alibaba Cloud service namespaces: ```python DEFAULT_ACTIONS = ['oss:*', 'fc:*', 'alidns:*', 'yundun-cert:*'] ``` Those actions are applied to every resource: ```python doc = {'Statement': [{'Action': actions, 'Effect': 'Allow', 'Resource': ['*']}], 'Version': '1'} ``` ### Technical Analysis The Skill's legitimate function is certificate issuance, state persistence, and certificate distribution. It does not inherently require every OSS, Function Compute, DNS, and certificate-management API operation across the entire account. The generated policy combines: - Service-wide wildcard actions, such as `oss:*`. - Account-wide resource scope through `Resource: ["*"]`. - A single role used across several distinct operational functions. This permits destructive and administrative operations unrelated to certificate renewal. It also substantially increases the impact of any trust-policy error, compromised workflow, malicious dependency, or leaked STS credential. The optional `--actions` argument can reduce service namespaces, but it does not provide a secure default and does not solve resource-wide access. Users following the documented default receive the broad policy automatically. ### Attack Path 1. A malicious actor compromises an authorized workflow, obtains a matching GitHub OIDC token, exploits the broad trust policy, or otherwise obtains the temporary STS credentials. 2. The actor uses the credentials during their validity period. 3. Because the policy allows wildcard actions on wildcard resources, the actor invokes destructive or administrative APIs unrelated to certificate renewal. 4. The actor modifies or delet ...[truncated 843 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Replace wildcard service permissions with an explicit allowlist of the exact APIs used by the implemented workflow. Recommended hardening plan: 1. Inventory every Alibaba Cloud API request made during DNS validation, certificate upload, OSS persistence, and deployment. 2. Allow only those specific actions rather than `oss:*`, `fc:*`, `alidns:*`, and `yundun-cert:*`. 3. Scope resources to the intended bucket, domain, DNS zone, function, and certificate resources wherever Alibaba Cloud supports resource-level authorization. 4. Use conditions such as resource tags, region, source identity, or service-specific conditions where available. 5. Separate duties into narrowly scoped roles, for example: - DNS validation role. - Certificate storage role. - Certificate deployment role. 6. Do not make the broad policy the default. Require explicit opt-in if an operation cannot be resource-scoped. 7. Set the shortest practical STS session duration. 8. Enable Alibaba Cloud audit logging and alert on destructive APIs, policy changes, and access outside expected resources. 9. Review existing role activity before replacing the policy, particularly if the broad trust pattern was also deployed. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/oidc_sts_env.py:30
• Finding: GitHub Actions Bearer Token Is Sent to an Unvalidated Environment-Provided URL<![CDATA[ ## Vulnerability Details **File Location**: `scripts/oidc_sts_env.py`, lines 30-35 **Vulnerability Type**: Unvalidated credential transmission endpoint **Risk Level**: High ### Vulnerable Code ```python def fetch_oidc_token(audience): # URL already contains ?job_id=...; append rather than starting another query url = os.environ['ACTIONS_ID_TOKEN_REQUEST_URL'] + '&audience=' + audience req = urllib.request.Request(url, headers={ 'Authorization': 'Bearer ' + os.environ['ACTIONS_ID_TOKEN_REQUEST_TOKEN']}) with urllib.request.urlopen(req, timeout=30) as r: return json.load(r)['value'] ``` ### Technical Analysis Sending the GitHub Actions request token to GitHub's OIDC endpoint is necessary for the declared functionality. The unsafe aspect is that the destination is read directly from `ACTIONS_ID_TOKEN_REQUEST_URL` and used without validation. The code does not verify: - That the URL uses HTTPS. - That the hostname belongs to an expected GitHub Actions endpoint. - That the URL does not contain embedded credentials. - That the port is expected. - That redirects remain on approved HTTPS hosts. The `Authorization` header contains the sensitive `ACTIONS_ID_TOKEN_REQUEST_TOKEN`. If the process environment is influenced by a malicious wrapper, preceding workflow step, or unsafe local invocation, the script can send that bearer token to an attacker-controlled server. The audience is also appended through string concatenation rather than safe query-string construction. This can produce malformed or ambiguous parameters if the audience contains reserved characters. ### Attack Path 1. An attacker gains the ability to alter the environment used to invoke the script, such as through a compromised preceding workflow step, wrapper, or workflow configuration. 2. The attacker changes `ACTIONS_ID_TOKEN_REQUEST_URL` to an endpoint they control. 3. The workflow invokes `scripts/oidc_sts_env.py`. 4. The script creates an HTTP request ...[truncated 1110 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Validate and safely construct the OIDC request URL before attaching the bearer token. Recommended controls: 1. Parse the URL with `urllib.parse.urlsplit`. 2. Require the `https` scheme. 3. Reject URLs containing usernames or passwords. 4. Reject unexpected ports. 5. Enforce an allowlist of documented GitHub Actions OIDC endpoint hostnames or hostname suffixes. 6. Disable redirects or validate every redirect destination before forwarding the authorization header. 7. Build the query string using `urllib.parse.parse_qsl`, `urlencode`, and `urlunsplit`. 8. Reject control characters and malformed URLs. 9. Avoid logging the URL if it may contain sensitive job-specific parameters. 10. Ensure only trusted workflow steps run before and after the credential exchange. A hardened construction should follow this pattern: ```python from urllib.parse import parse_qsl, urlencode, urlsplit, urlunsplit raw_url = os.environ['ACTIONS_ID_TOKEN_REQUEST_URL'] parts = urlsplit(raw_url) if parts.scheme != 'https': raise ValueError('OIDC request URL must use HTTPS') if parts.username or parts.password: raise ValueError('Embedded URL credentials are prohibited') if parts.port not in (None, 443): raise ValueError('Unexpected OIDC endpoint port') allowed_hosts = { # Populate from current GitHub Actions documentation. } if parts.hostname not in allowed_hosts: raise ValueError('Unexpected OIDC endpoint host') query = dict(parse_qsl(parts.query, keep_blank_values=True)) query['audience'] = audience url = urlunsplit((parts.scheme, parts.netloc, parts.path, urlencode(query), '')) ``` ]]>

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:106
• Finding: Security-Sensitive Dependencies Are Installed Without Version or Hash Pinning<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 106-107 **Related Locations**: `SKILL.md`, line 53; `README.md`, line 32 **Vulnerability Type**: Unpinned runtime dependencies in a privileged CI workflow **Risk Level**: Medium ### Vulnerable Code ```yaml - run: pip install alibabacloud_sts20150401 alibabacloud_alidns20150109 \ alibabacloud_cas20200407 alibabacloud_fc_open20210406 oss2 acme cryptography ``` The setup instructions similarly install unpinned packages: ```bash pip install alibabacloud_ims20190815 ``` ```bash pip install alibabacloud_ims20190815 alibabacloud_ram20150501 alibabacloud_sts20150401 ``` ### Technical Analysis The documentation instructs CI and operators to install the latest available versions of security-sensitive packages at execution time. No exact versions, package hashes, lock file, or reviewed dependency snapshot is provided. A future compromised, malicious, or unexpectedly incompatible package release could execute code during installation or import. In this workflow, dependencies run in an environment that can contain: - A GitHub OIDC request capability. - Temporary Alibaba Cloud access keys and security tokens. - Repository checkout contents. - GitHub workflow permissions. - Certificate private keys and persisted ACME state. This finding does not establish that any currently named package is malicious. The risk arises from allowing package contents to change after the Skill has been reviewed. ### Attack Path 1. An upstream package account, release process, or distribution channel is compromised, or an unsafe future release is published. 2. A scheduled or manually triggered workflow executes the documented unpinned `pip install` command. 3. The package manager selects the newly published version. 4. Malicious code executes during installation, import, or normal SDK use. 5. The code reads available workflow tokens, cloud credentials, repository data, certificate keys, or state files. ...[truncated 881 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Adopt reproducible, reviewed dependency management: 1. Pin every direct and transitive dependency to an exact version. 2. Generate and commit a lock file from a trusted environment. 3. Record package hashes and install with: ```bash pip install --require-hashes -r requirements.txt ``` 4. Separate provisioning dependencies from runtime certificate-renewal dependencies. 5. Review dependency updates through pull requests rather than resolving latest versions during scheduled runs. 6. Use automated vulnerability scanning, but require human review for security-sensitive SDK changes. 7. Prefer a prebuilt, signed, immutable runner image or artifact containing reviewed dependencies. 8. Verify package names and official publishers to reduce typosquatting and dependency-confusion risk. 9. Minimize workflow permissions during dependency installation and obtain cloud credentials only after dependencies are installed. 10. Avoid making repository write tokens, cloud credentials, and private keys available to the same step that resolves packages from the public package index. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Taint Tracking: Direct Taint Flow, Variable-Mediated Taint Flow, Credential Exfiltration Chain
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (11)

Tainted flow: 'req' from os.environ.get (line 54, credential/environment) → urllib.request.urlopen (network output)

Critical

• Category: Data Flow

Content

url = os.environ['ACTIONS_ID_TOKEN_REQUEST_URL'] + '&audience=' + audience
    req = urllib.request.Request(url, headers={
        'Authorization': 'Bearer ' + os.environ['ACTIONS_ID_TOKEN_REQUEST_TOKEN']})
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.load(r)['value']

• Confidence: 90% confidence
• Finding: Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 93% confidence
• Finding: The skill documents code paths that read environment variables, write files such as $GITHUB_ENV, and perform network/API operations, but it does not declare an explicit tool/permission scope. In an agent setting, that mismatch can cause the skill to be invoked with broader effective capabilities than users expect, increasing the risk of unauthorized external calls, credential handling, or state changes.

Vague Triggers

Medium

• Confidence: 90% confidence
• Finding: The trigger phrases are broad enough to match common SSL, GitHub Actions, and Alibaba Cloud help requests, so the skill may activate in contexts where the user only wants advice rather than automation affecting production infrastructure. Over-broad activation is dangerous here because the skill covers credential exchange, DNS validation, certificate distribution, and cloud-side changes.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill describes impactful actions including certificate issuance, certificate deletion and replacement, DNS TXT creation, OSS/FC/CDN distribution, and repository writes, but it does not prominently warn that these operations can alter production traffic and trust chains. In the security context, silent or insufficiently signposted production-impacting automation can lead to outages, domain validation issues, or unintended certificate rotation.

Vague Triggers

Medium

• Confidence: 88% confidence
• Finding: The trigger phrase at line 11 is broad enough to match many ordinary certificate-renewal requests without clearly constraining the environment, provider, or intended workflow. In a skill-routing system, this can cause the skill to activate for users who only asked generic SSL renewal questions, leading to misrouting, irrelevant operational guidance, or accidental application of Aliyun/GitHub-specific steps in the wrong context.

Vague Triggers

Medium

• Confidence: 93% confidence
• Finding: The trigger phrase '通配证书申请' is too generic and lacks context tying it to Aliyun, OIDC, or this specific automation workflow. Because wildcard certificate issuance is a common request across many platforms, the skill may be invoked outside its intended scope and provide cloud-specific operational instructions that do not fit the user's environment.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The script writes temporary Alibaba Cloud STS credentials into $GITHUB_ENV, which makes them available to all subsequent steps in the job. While this is a common GitHub Actions pattern, it increases exposure risk because later steps, third-party actions, debug output, or accidental environment dumping can leak usable cloud credentials during their validity window.

Natural-Language Policy Violations

Low

• Confidence: 97% confidence
• Finding: The file is entirely written in Chinese and the manifest description is also Chinese, but it does not indicate that the skill is intentionally limited to Chinese-speaking users or provide an opt-in language choice. Under the policy, forcing a specific language without user choice is a natural-language locale violation unless the constraint is clearly justified.

Natural-Language Policy Violations

Low

• Confidence: 74% confidence
• Finding: The manifest's user-facing name, category, and description are presented only in Chinese, while the skill does not state that it is intended exclusively for a Chinese-speaking or China-region audience. This can constitute a locale-policy issue because the skill appears to impose a language choice without opt-in or documentation of the constraint.

Natural-Language Policy Violations

Low

• Confidence: 90% confidence
• Finding: The natural-language documentation and runtime messages in this file are presented exclusively in Chinese, with no indication that language choice is configurable or intentional for a specific audience. This can violate a language/locale policy when a skill forces one language without offering user choice or documenting the constraint.

Natural-Language Policy Violations

Low

• Confidence: 97% confidence
• Finding: This code file contains natural-language instructions, usage guidance, and operational prompts only in Chinese, which forces a specific language for users. The policy allows locale constraints only when they are optional, user-selectable, or clearly justified, which is not present here.

Static analysis

No suspicious patterns detected.