xbridge-ext-helper

• Outcome: Review
• Latest audit: Sep 16, 2026 · 5:23 AM UTC
• Version: 1.0.0

Overview

The skill is a developer documentation helper, but its financial transaction reference code contains unsafe access-control, logging, and audit-trail patterns that should be reviewed before use.

Review this skill before installing if you expect agents to copy its DAO or processor examples. Require tenant-scoped queries and updates, avoid logging full transaction objects, and decide whether audit-history saves must be mandatory for your compliance model.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/TransactionDAO.java:95

Finding

Tenant Scope Is Missing from ID-Based Transaction Access

Content

View full analysis

Vulnerability Details

File Location: references/TransactionDAO.java, lines 95–99 and 168–170
Vulnerability Type: Missing tenant-level authorization in ID-based database operations
Risk Level: High

Vulnerable Code

java

EntityQueryWrapper queryWrapper = EntityQueryWrapper.columnNameQuery(transactionEntityManager.getEntityTable());
queryWrapper.eq("id", transaction.getId());
if (!expectedStatus.isEmpty()) {
  queryWrapper.in("transaction_status", expectedStatus.stream().map(TransactionStatus::getStatus).toList());
}

java

public Transaction findByTransactionId(Long transactionId) {
  return transactionMapper.selectById(transactionId);
}

Technical Analysis

The update query and ID-based lookup constrain access using only the transaction ID. Neither operation includes a tenant_id predicate derived from a trusted tenant context.

The same DAO applies an explicit tenant condition when looking up a transaction by UUID:

java

public Transaction findByTransactionUuid(Long tenantId, String transactionUuid) {
  return transactionMapper.selectOne(
      Wrappers.lambdaQuery(Transaction.class)
          .eq(Transaction::getTenantId, tenantId)
          .eq(Transaction::getTransactionUuid, transactionUuid)
  );
}

This inconsistency indicates that tenant isolation is not uniformly enforced by the DAO. If transaction IDs can be discovered, predicted, leaked, or supplied by a client, ID-only operations may access records belonging to another tenant.

A global, independently verified tenant interceptor could reduce the risk, but no such enforcement mechanism is present in the audited project. DAO methods should therefore enforce tenant ownership explicitly rather than relying on unverified external behavior.

Attack Path

1. An authenticated user obtains or guesses the ID of a transaction owned by another tenant.
2. The user causes an application endpoint or se ...[truncated 1087 chars]

Remediation

View remediation

Remediation Suggestions

1. Require a trusted tenant identifier for every transaction read, update, and delete operation.

2. Add the tenant condition directly to all database predicates:

   java

   queryWrapper.eq("id", transaction.getId());
   queryWrapper.eq("tenant_id", trustedTenantId);
   

3. Replace selectById with a tenant-scoped query:

   java

   public Transaction findByTransactionId(Long trustedTenantId, Long transactionId) {
     return transactionMapper.selectOne(
         Wrappers.lambdaQuery(Transaction.class)
             .eq(Transaction::getId, transactionId)
             .eq(Transaction::getTenantId, trustedTenantId)
     );
   }
   

4. Obtain trustedTenantId from authenticated server-side security context, not from a request DTO or other client-controlled field.

5. Apply the same tenant predicate to transaction lines, extension records, history records, and deletion operations.

6. Consider centralized database-level tenant enforcement as defense in depth, but do not use it as a substitute for explicit ownership checks.

7. Add integration tests proving that one tenant cannot read, update, or delete another tenant's records even when a valid foreign transaction ID is supplied.

8. Return a generic not-found or access-denied response without revealing whether a foreign transaction ID exists.

T09 · Insecure Skill Coding Practices

Warning

• Location: references/VNTransactionProcessor.java:198

Finding

Complete Financial Transaction Object Is Written to INFO Logs

Content

View full analysis

Vulnerability Details

File Location: references/VNTransactionProcessor.java, line 198
Vulnerability Type: Sensitive information exposure through application logging
Risk Level: Medium

Vulnerable Code

java

log.info("整单折扣处理完成，transaction:{}", JSON.toJSONString(transaction));

Technical Analysis

The code serializes the complete Transaction object and writes it at INFO level. Based on the audited transaction conversion and extension models, this object can contain sensitive financial and personal information, including names, tax identifiers, addresses, phone numbers, email addresses, bank information, invoice data, transaction values, and country-specific extension fields.

INFO logs are commonly enabled in production and forwarded to centralized logging or observability systems. Such systems frequently have broader access permissions and longer retention periods than the underlying transaction database. Logging the complete object therefore creates an additional, unnecessary copy of sensitive data outside the primary data store.

User-controlled string fields may also contain line breaks or other formatting characters. Depending on the logging pipeline, this may make log records misleading or interfere with downstream parsing, although the directly evidenced issue is sensitive-data exposure.

Attack Path

1. A user submits or updates a Vietnam transaction containing personal, banking, tax, or other sensitive information.
2. processCommercialDiscount processes the transaction.
3. The processor serializes the entire transaction using JSON.toJSONString.
4. The resulting JSON is emitted at INFO level and may be retained locally or forwarded to a centralized logging platform.
5. A user with log access, an overly privileged support account, or an attacker who compromises the logging platform can retrieve sensitive transaction data without accessing the primary transaction database.

Imp

...[truncated 529 chars]

Remediation

View remediation

Remediation Suggestions

1. Do not serialize or log the complete transaction object.

2. Replace the statement with a structured allowlist containing only non-sensitive operational identifiers:

   java

   log.info(
       "Commercial discount processing completed, transactionId={}, transactionType={}",
       transaction.getId(),
       transaction.getTransactionType()
   );
   

3. Avoid logging buyer, seller, banking, tax, contact, invoice-content, and extension-field values.

4. Where diagnostics require additional context, use a dedicated redacted representation rather than generic object serialization.

5. Sanitize user-controlled values to remove control characters before including them in logs.

6. Restrict access to production logs according to least privilege and enable access auditing.

7. Configure retention periods appropriate for potentially sensitive financial metadata.

8. Review existing retained logs and remove or protect historical records containing complete serialized transactions.

9. Add automated tests or static-analysis rules that reject logging of complete transaction, DTO, request, or customer objects.

SkillSpector

Vulnerability Patterns

• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (5)

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

The skill description and heading are written entirely in Chinese and present the skill as operating in that language, without offering a language choice or noting that Chinese is optional. This can violate language/locale policy when users have not opted into Chinese-language assistance.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 97% confidence

Finding

The prompts and expected outputs are entirely written in Chinese, which implicitly constrains the skill's interaction language. There is no indication that users may choose another language or that the language restriction is required for a region-specific compliance or operational reason.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The code and comments describe preserving the original transaction in a history table as a key audit step, but the actual save calls in both create and update flows are commented out. This creates an audit-trail gap: original pre-discount/pre-modification data may be lost, undermining non-repudiation, forensic investigation, and compliance requirements for invoice changes.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

The processor logs the full serialized transaction object after discount handling, which can expose invoice contents, identifiers, pricing, tax data, and possibly customer-related fields into application logs. Logs are often broadly accessible and long-retained, so full-object logging increases the risk of sensitive data leakage and secondary compromise through log aggregation systems.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

SQP-3 applies to all file types and covers natural-language language/locale policy violations. This markdown file presents all guidance in Chinese from the title onward, with no indication that the user can choose another language or that the document is intentionally limited to a Chinese-speaking or region-specific audience.

Content

No source excerpt is available for this finding.