Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent Gitea workflow skill with explicit cron-based automation, but users should treat its token and scheduled-agent behavior carefully.
Install only in an environment where recurring OpenClaw cron jobs are acceptable. Use a least-privilege Gitea token, keep it in a local 600-permission file or secret store, and verify each cron target, role, repository, and group destination before enabling the loop.
The file presents itself as a non-API, non-implementation workflow description, but the documented loop model materially depends on runtime state, issue polling, and operational decision logic. In practice, this can mislead downstream agents into performing automation and reading environment-specific context under the guise of passive guidance.
The file presents itself as a non-API, non-implementation workflow description, but the documented loop model materially depends on runtime state, issue polling, and operational decision logic. In practice, this can mislead downstream agents into performing automation and reading environment-specific context under the guise of passive guidance.
The file presents itself as a non-API, non-implementation workflow description, but the documented loop model materially depends on runtime state, issue polling, and operational decision logic. In practice, this can mislead downstream agents into performing automation and reading environment-specific context under the guise of passive guidance.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
"persistence": null,
"credentialSetup": {
"type": "none",
"description": "No credentials required. Gitea token is read at runtime by each agent from their own configuration file (e.g. ~/.config/gitea/{agent}.json, mode 600). Each agent is responsible for managing their own Gitea personal access token."
},
"requires": {
"anyBinaries": [],
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.
GITEA_TOKEN_FILE="${GITEA_TOKEN_FILE:-$HOME/.config/gitea/token}"
if [ -f "$GITEA_TOKEN_FILE" ] && [ "$REPO" != "(待定)" ] && [ "$REPO" != "(跨所有仓库)" ] && [ "$REPO" != "(未配置)" ]; then
TOKEN=$(cat "$GITEA_TOKEN_FILE")
open_count=$(curl -s -H "Authorization: token $TOKEN" \
"http://127.0.0.1:3000/api/v1/repos/${REPO}/issues?state=open&limit=50" 2>/dev/null \
| python3 -c "import json,sys; print(len(json.load(sys.stdin)))" 2>/dev/null || echo "?")
echo "open: $open_count issues"
The skill references executable shell-based operational commands (gitea-workflow loop-on, loop-off, status) but does not declare any tool scope, permissions, or allowed-tools boundaries. That creates an authorization and review gap: an agent or operator may believe this is documentation-only, while the skill implicitly depends on command execution that can alter scheduler state.
The manifest description and the full instructional content are presented in Chinese, and the file does not indicate that the user can choose another language or that the skill is intentionally limited to a Chinese-speaking environment. This can violate language/locale policy when a skill effectively forces a specific language without user opt-in.
The metadata claims no credentials are required while the description explicitly states that each agent reads a Gitea personal access token from a local configuration file at runtime. This inconsistency can mislead users, scanners, and deployment controls, causing the skill to bypass credential review or be installed in environments that prohibit secret access.
The document tells users where to store a Gitea token and notes file permissions, but it does not clearly warn that the token is a sensitive credential with repository/API access that must never be exposed in chat, logs, screenshots, shell history, or committed into a repository. In a multi-agent workflow with cron jobs and shared collaboration channels, this omission increases the chance of accidental disclosure and subsequent unauthorized repository access.
This code accesses a credential from a token file and uses it in a network call, which falls under sensitive credential access and data transmission. While the script prints status output, it does not disclose that it will read a local token and authenticate to the Gitea API, and there is no confirmation prompt, explanatory comment, or other user-facing warning about that behavior.
The file’s human-readable comments are written only in Chinese, which indicates a fixed language choice in the skill content. Under the policy, language constraints should be optional or clearly justified; this file does not provide any opt-in or rationale for the locale restriction.
Natural-language instructions and comments in the file are presented exclusively in Chinese, with no indication that language choice is optional or contextually required. Under the policy, forcing a specific language without user opt-in is a language/locale policy violation.
No suspicious patterns detected.