T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:5- Finding
Skill Grants Tools Beyond Its Read-Only Football Data Function
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This football data skill is mostly purpose-aligned, but it requests broad file-editing and shell authority that is not needed for a read-only sports lookup tool.
Review before installing. The football data behavior itself is not deceptive, but the skill should ideally remove Write/Edit/Grep/WebSearch, constrain Bash to the bundled scripts, restrict network use to documented football APIs, and pin dependencies. Expect the zero-config OpenLigaDB features to work better than the advertised API-key player/H2H features.
SKILL.md:5Skill Grants Tools Beyond Its Read-Only Football Data Function
requirements.txt:1Unbounded Third-Party Dependency Versions Create Supply-Chain Exposure
The description generally matches the domain and broad intent: this is indeed a football information query tool, and there is no evidence of betting, exfiltration, or unrelated malicious behavior. However, there is a material description-to-behavior mismatch because key advertised capabilities are not actually implemented in the code path that runs. The main function only provides real functionality for standings, fixtures, leagues, and limited team lookup through OpenLigaDB. For players and h2h, the script explicitly prints that OpenLigaDB does not support them and suggests configuring API-Football, but the API-Football and football-data.org modes are themselves marked '待实现' and do not execute those features. So the declared description overstates current functionality, especially around player data and H2H/pre-match preview. This is a meaningful mismatch in capabilities, though not a safety issue.
The primary skill description is written in Chinese with no indication that other languages are supported or that the user can opt into a preferred language/locale. Under the stated policy, forcing a specific language without user choice is a natural-language policy violation.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
The description lists generic triggers such as “查赛程”, “球队信息”, “球员数据”, and “查排名”, which are common football-related requests rather than narrowly scoped activation phrases. There are no exclusion conditions or context limits, so the skill could be invoked unintentionally during ordinary conversation about football.
The dedicated trigger section provides a list of example phrases, but it does not explain when the skill should not activate or how these triggers differ from general sports discussion. This lack of specificity makes the invocation boundary unclear and increases the chance of accidental activation.
The file presents all user-facing guidance in Chinese and sets a default timezone of Asia/Shanghai, which imposes a specific language/locale context without offering alternatives or documenting that the skill is region-specific. This matches the policy category for language or locale constraints lacking user choice or clear justification.
The module docstring and usage examples present this as a three-tier football data hub capable of standings, fixtures, teams, players, H2H, and multiple providers. In practice, the main execution path only implements OpenLigaDB queries, while API-Football and football-data.org branches merely print '待实现', and OpenLigaDB explicitly does not support players or H2H.
This is a natural-language policy issue because the file forces a specific language for usage examples and CLI guidance. The policy says to flag language or locale constraints unless the skill offers user opt-in or clearly documents a justified regional scope, which is not present here.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# ──────────────────────────────────────────────────────────────────────────
class FootballDataClient:
BASE_URL = "https://api.football-data.org/v4"
def __init__(self, api_key: str):
self.session = requests.Session()
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# ──────────────────────────────────────────────────────────────────────────
class FootballDataClient:
BASE_URL = "https://api.football-data.org/v4"
def __init__(self, api_key: str):
self.session = requests.Session()
This code file contains natural-language instructions and output strings only in Chinese, starting with the module docstring and continuing throughout the CLI interface. Under the policy, forcing a specific language without offering user choice or documenting a justified locale restriction is a natural-language policy violation.
The H2H summary counts every historical home win as a win for team1 and every away win as a win for team2, instead of checking whether team1 or team2 was actually the home side in each prior match. This produces objectively incorrect comparative stats in a script presented as a factual pre-match analysis, which can mislead users and downstream agents relying on the report.
This markdown file uses Chinese headings and labels throughout, which can amount to a language-policy concern when a skill or reference forces a specific language without user opt-in. There is no indication that the content is intentionally region-specific or that alternative language support is offered.
The dependency specifier requests>=2.28.0 is unpinned, so builds may resolve to different versions over time and can inadvertently pull in a vulnerable or incompatible release. This weakens supply-chain reproducibility and makes it hard to verify whether deployed environments are protected from known advisories affecting Requests.
requests>=2.28.0
pyyaml>=6.0
Requests has multiple historical advisories, and because the manifest does not pin an exact version, it is not possible to verify from this file whether the installed package is affected. While this file alone does not prove exploitation, the lack of version pinning creates supply-chain uncertainty and may expose the skill to known flaws depending on resolution time.
The dependency specifier pyyaml>=6.0 is unpinned, which allows non-deterministic installs and makes it uncertain which exact release will be used. Given PyYAML's history of deserialization-related issues, leaving the version open increases the chance of introducing a vulnerable release into the environment.
requests>=2.28.0
pyyaml>=6.0
PyYAML has several known advisories, including unsafe deserialization risks, and the unpinned requirement prevents determining whether a safe release will be installed. In a data-query skill that may parse external data or configuration, this uncertainty is a real though low-severity supply-chain concern from the manifest alone.
The docstring for get_client describes returning a client by priority, implying those returned clients will support the advertised behavior. However, when source is 'api-football' or 'football-data', main only prints that those modes are not implemented, so the documented intent of operational provider selection contradicts actual behavior.
No suspicious patterns detected.