T09 · Insecure Skill Coding Practices
- Location
axiom_luhn_check.py:124- Finding
Full Sensitive Account Numbers Are Returned and Exposed in JSON Output
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a local checksum tool, but it can expose full card numbers in output and overstates what it validates.
Review before installing or using with real card numbers. The tool appears local and non-persistent, but use only synthetic/test numbers unless it is changed to accept safer input and to mask or omit full identifiers from output. Do not rely on it for ISBN validation or PCI-grade payment validation.
axiom_luhn_check.py:124Full Sensitive Account Numbers Are Returned and Exposed in JSON Output
SKILL.md:32Documentation Encourages Supplying Sensitive Numbers Through Command-Line Arguments
axiom_luhn_check.py:103Overly Permissive Input Normalization Silently Accepts Arbitrary Non-Digit Characters
The skill documentation claims support for validation schemes that are not actually implemented correctly, especially ISBN-10 and ISBN-13, which use different checksum rules than Luhn. This can cause consumers to trust false validation results for financial, inventory, or identity-related data, leading to downstream logic errors, acceptance of invalid identifiers, or rejection of valid ones.
The file’s user-facing description and instructions are fully in Chinese, and there is no indication that the user can choose another language or that the locale restriction is intentional and justified. This can violate language/locale policy expectations when skills are expected to be accessible without forcing a specific language.
This Python file contains user-facing natural-language text in French in the module docstring, including usage guidance and limitations, while other parts are in English. The skill does not offer any language selection or state that it is intentionally restricted to French users, which creates a language/locale policy concern under the natural-language policy rule.
The module claims ISBN-10 support under a Luhn validator even though ISBN-10 uses a different checksum algorithm and this implementation only applies Luhn. This can cause consumers to accept or reject identifiers incorrectly, creating integrity and business-logic risk where validation decisions gate account creation, payments, or record processing.
The public API suggests comprehensive validation with type detection, but validity is effectively based on a Luhn pass plus a heuristic type guess rather than authoritative per-format rules. In security-sensitive or compliance-sensitive workflows, this can lead to false trust in malformed identifiers and enable bypass of business checks that rely on strong validation semantics.
The function docstring and runtime error output include French phrases such as 'Valide un numéro' and 'Erreur', which means end users may receive French-only guidance and errors. Because the file does not provide a language choice or declare a justified region-specific scope, this is a policy violation for forced language/locale behavior.
The skill description and usage guidance are primarily presented in French, which effectively imposes a specific language on users. The file does not indicate that the skill is region-specific or provide an opt-in or alternative language option.
The file is written entirely in French and is named as a French variant, but it does not state that the skill is region-specific or offer language/locale choice. Under the policy rule, forcing a specific language without user opt-in is a natural-language policy concern.
The manifest describes a Luhn validator for credit cards, SIRET/SIREN, IMEI, and ISBN-10/13, but the code also detects a 23-digit 'rib' type. RIB is not mentioned in the manifest description, so this is extra user-facing behavior outside the declared scope.
The class docstring "Tests de l'algo Luhn." is French-only natural-language text. Under the policy, forcing a specific language without user choice can be a locale/language policy violation, and this file does not indicate any opt-in or justification for using French.
No suspicious patterns detected.