ClawHub
Back to skill

Security audit

Huabei

Security checks for vulnerabilities and agentic risk

Overview

This is a coherent Huabei finance guide with a local IRR calculator; its main issues are calculation robustness and language usability, not hidden or privileged behavior.

Install only if you want a Chinese-language Huabei guide and a simple local APR calculator. Use ordinary positive inputs, do not rely on it for unusual or edge-case financing scenarios, and confirm actual fees, credit-report treatment, and account options in Alipay before making financial decisions.

A.I.G

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/irr.py:37
Finding

Missing Validation for Financial Input Parameters

Content
View full analysis

Vulnerability Details

File Location: scripts/irr.py, lines 37-41 and 54-59
Vulnerability Type: T09: Insecure Skill Coding Practices
Risk Level: Medium

Vulnerable Code

python
def show(principal: float, months: int, total_fee: float) -> None:
    pay = (principal + total_fee) / months
    r = irr_monthly(principal, months, pay)
    apr = r * 12 * 100
    surface = total_fee / principal / months * 12 * 100
python
if a[0] == "fee" and len(a) == 4:
    p, n, rate = float(a[1]), int(a[2]), float(a[3]) / 100
    show(p, n, p * rate * n)
elif a[0] == "total" and len(a) == 4:
    show(float(a[1]), int(a[2]), float(a[3]))

Technical Analysis

Values supplied through command-line arguments are converted to numeric types but are not checked against valid financial constraints. In particular:

  • principal is not required to be greater than zero.
  • months is not required to be a positive integer.
  • Fees and rates can be negative.
  • Floating-point values such as NaN and positive or negative infinity are accepted by float().
  • Arithmetic exceptions are not handled because the exception handler only catches ValueError.

A zero principal causes division by zero when calculating surface. A zero installment count causes division by zero when calculating both pay and surface. Negative and non-finite values may propagate through the IRR calculation and produce nonsensical or misleading financial results instead of a validation error.

Attack Path

  1. An attacker, user, or upstream agent supplies an invalid calculator request.
  2. For example, the process is invoked with python3 scripts/irr.py fee 12000 0 0.6 or python3 scripts/irr.py fee 0 12 0.6.
  3. The arguments successfully pass numeric conversion.
  4. show() divides by months or principal.
  5. An uncaught ZeroDivisionError terminates the process.

Alternatively, an invocation such as `python3 sc ...[truncated 615 chars]

Remediation
View remediation

Remediation Suggestions

  • Require principal to be finite and strictly greater than zero.
  • Require months to be a positive integer and impose a reasonable upper bound.
  • Require the fee and periodic rate to be finite and nonnegative unless negative-cost financing is intentionally supported.
  • Validate the resulting monthly payment before invoking the solver.
  • Reject NaN and infinity explicitly with math.isfinite().
  • Catch expected arithmetic failures and return a clear error message with a nonzero exit status.
  • Keep validation in a shared function so both fee and total modes enforce identical constraints.
  • Add automated tests covering zero, negative, non-finite, extremely large, and valid boundary values.

Example validation pattern:

python
import math

def validate_inputs(principal: float, months: int, total_fee: float) -> None:
    if not math.isfinite(principal) or principal <= 0:
        raise ValueError("Principal must be a finite value greater than zero")
    if months <= 0:
        raise ValueError("Months must be a positive integer")
    if not math.isfinite(total_fee) or total_fee < 0:
        raise ValueError("Total fee must be a finite nonnegative value")

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/irr.py:21
Finding

IRR Solver Returns Boundary Values Without Verifying That a Root Exists

Content
View full analysis

Vulnerability Details

File Location: scripts/irr.py, lines 21-31
Vulnerability Type: T09: Insecure Skill Coding Practices
Risk Level: Medium

Vulnerable Code

python
def irr_monthly(principal: float, months: int, pay_per_month: float) -> float:
    lo, hi = 0.0, 1.0
    for _ in range(200):
        mid = (lo + hi) / 2
        pv = sum(pay_per_month / (1 + mid) ** k for k in range(1, months + 1))
        if pv > principal:
            lo = mid
        else:
            hi = mid
    return (lo + hi) / 2

Technical Analysis

The binary-search solver assumes that the monthly IRR is within the fixed interval from 0.0 to 1.0, corresponding to a monthly rate between 0% and 100%. It does not evaluate the objective function at both endpoints to confirm that the interval brackets a root.

Binary search is only valid when a root is bracketed and the objective function satisfies the expected monotonic behavior over that interval. If the actual IRR is negative or greater than 100% per month, the algorithm repeatedly moves toward an interval boundary and returns that boundary as if it were a successfully calculated root.

The function also has no convergence check, residual check, or explicit failure state. Running 200 iterations therefore creates false confidence without proving that the returned rate satisfies the present-value equation.

Attack Path

  1. An attacker, user, or upstream agent supplies a negative or extremely large total fee.
  2. The input reaches irr_monthly() because the program does not validate the supported rate domain.
  3. The actual root lies outside the hardcoded interval, or no valid root exists in that interval.
  4. The loop converges toward 0.0 or 1.0.
  5. The boundary value is annualized and printed as a valid IRR without an error or warning.
  6. A user or decision-making agent may compare this incorrect result with other credit products and make a fin ...[truncated 542 chars]
Remediation
View remediation

Remediation Suggestions

  • Define the IRR objective function explicitly as the present value of payments minus principal.
  • Evaluate the objective at both interval endpoints and verify that their signs bracket a root.
  • Dynamically expand the upper bound within a documented safety limit when the initial interval does not contain the root.
  • Return an explicit calculation error if no supported root can be bracketed.
  • Check the final residual against a numerical tolerance before accepting the result.
  • Reject unsupported negative-payment or negative-fee scenarios unless the calculator is deliberately extended to model them.
  • Consider reporting both nominal annualized IRR and effective annual rate, clearly labeling each value.
  • Add regression tests for roots below zero, above the initial upper bound, extreme fees, zero fees, and ordinary installment plans.

A hardened solver should follow this sequence:

  1. Validate all inputs.
  2. Calculate objective values at the lower and upper bounds.
  3. Expand the upper bound when necessary and safe.
  4. Refuse to calculate when no root can be bracketed.
  5. Iterate until both interval width and objective residual meet defined tolerances.
  6. Return a result only after confirming convergence.

SkillSpector

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
93% confidence
Finding

The module docstring, usage text, and all user-facing output are entirely in Chinese, with no indication that another language is available or that the locale is intentionally region-specific. Under the stated policy, forcing a specific language without offering user choice is a natural-language policy violation.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.