T09 · Insecure Skill Coding Practices
- Location
scripts/publish_post.py:247- Finding
Moltbook API Key Exposed Through Command-Line Arguments
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a mostly coherent Moltbook publishing helper, but it needs review because it can publish public content with an account API key and handles that key unsafely.
Review before installing. Use a dedicated Moltbook API key with limited permissions if available, avoid passing it via --api-key in commands, preview final post text before running live publishing, and be aware that content may be truncated and then posted publicly to Moltbook.
scripts/publish_post.py:247Moltbook API Key Exposed Through Command-Line Arguments
The supplied code is narrowly focused on formatting and validating content text. It reads content from a file or CLI argument, applies Markdown and bilingual spacing fixes, optimizes long URLs, enforces spacing, truncates overlong content, validates common formatting issues, and extracts a title. It does not connect to Moltbook, call any API, authenticate, schedule posts, solve verification challenges, or manage publication workflows. While content preparation is one supporting part of the declared description, the declared purpose substantially overstates the implemented behavior and omits that this chunk is only a formatter utility. Therefore this is a clear description-behavior mismatch.
The declared description promises a comprehensive Moltbook publishing skill, including creating/scheduling/managing posts, authentication, verification challenge handling, and end-to-end publication. The supplied code only computes timezone-adjusted posting schedules and prints strategy recommendations based on hardcoded time windows. It does not access Moltbook, perform network/API operations, manage credentials, create or publish content, or solve any verification/math challenges. While cross-timezone scheduling is one small subset of the declared scope, the actual code's primary purpose is materially narrower and different from the claimed full publishing workflow.
The code substantially supports posting to Moltbook, API authentication verification, and solving math verification challenges, which align with key parts of the description. However, the declared description overstates the implemented scope: there is no scheduling logic, no timezone-aware publishing, no broader post management (such as editing, deleting, listing, or rescheduling), and no content optimization features. Thus the description does not accurately represent the actual behavior, even though the core publish workflow is real and consistent.
The README instructs users to pass an API key directly on the command line and describes automatic content formatting/truncation, but it does not clearly warn that content will be transmitted to an external service or that the tool may alter post content before publication. This is risky because command-line secrets may be exposed via shell history or process listings, and silent content modification can cause unintended or misleading posts to be published.
The skill advertises and documents network access, local scripts, and content synchronization workflows, but it does not declare any explicit tool scope or permissions boundaries. In practice this creates an overbroad execution surface where an agent may use file and network capabilities without a least-privilege contract, increasing the risk of unintended data access or exfiltration.
The skill is explicitly designed to transmit data to an external network service using curl and an API key. External transmission is expected for a publisher skill, but it is still security-relevant because agent-produced content, account identifiers, and authentication headers may be sent off-platform, making misuse or accidental disclosure more dangerous in this context.
- MOLTBOOK_API_KEY
bins:
- python3
- curl
primaryEnv: MOLTBOOK_API_KEY
emoji: "📬"
homepage: https://github.com/yanxi1024-git/moltbook-publisher-skill
The skill provides concrete instructions to send user content and a bearer API key to an external service, but it does not clearly warn that posts, metadata, and authentication material will leave the local environment. This can lead to inadvertent disclosure of sensitive prompts, unpublished material, or account credentials through normal skill use.
The example code encourages placing an API key directly in source, which increases the chance of accidental leakage via logs, screenshots, shell history, repos, or copied snippets. Hardcoded credential patterns are especially risky in agent ecosystems where artifacts may be persisted or shared automatically.
This code sends user-supplied content and authorization headers to an external endpoint. While external transmission is required for publishing, it remains security-relevant because the skill can move potentially sensitive data off-system to a third party, and the context is more dangerous in an agent workflow that may act on behalf of a user with limited visibility.
}
try:
response = requests.post(
f"{BASE_URL}/posts",
headers=self.headers,
json=payload,
The script transmits title and content to a remote service, which is the core purpose of the tool, but it does so without an explicit user-facing disclosure at the point of action. In an agent skill context, this matters because a caller may not realize local text is being sent off-host to a third-party API, creating privacy and data-handling risk if sensitive content is posted unintentionally.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
}
try:
response = requests.post(
f"{BASE_URL}/verify",
headers=self.headers,
json=payload,
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
print(f" Please solve manually and call verify_post()")
return result
else:
print(f"\n✅ Post published (no verification needed)")
return result
Accepting the API key via a command-line argument can expose the secret through shell history, process listings, logs, or job runners. This is a real credential-handling weakness even though it appears unintentional, and in an automation context it increases the chance of token leakage to other local users or monitoring systems.
The text states the post was 'Posted 10:00 AM Asia time,' which imposes a specific regional time reference without offering localization or an alternate timezone. This can conflict with language/locale policy expectations when content is presented to a broad audience without user opt-in or conversion.
This code reads arbitrary local file contents from the path provided via --file, but there is no print/log message, confirmation, or inline warning disclosing that local file data will be accessed and then used in the publishing workflow. Because the script later submits content to a remote API, the file-read step is part of a data-handling operation that would benefit from explicit user disclosure.