T09 · Insecure Skill Coding Practices
- Location
scripts/weread_login.py:57- Finding
Unsafe Temporary File Creation When Copying the Chrome Cookie Database
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a real WeRead helper, but it stores a live login cookie and understates the remote data flow, so users should review it carefully before installing.
Install only if you are comfortable giving the skill access to your WeRead account session and private reading history. Treat ~/.weread/cookie like a password: do not share it, do not commit it, avoid cloud syncing it, and delete or rotate it if exposed. Review the privacy wording carefully because normal use sends authenticated requests to WeRead/Tencent services, even though the skill does not appear to send data to unrelated third parties.
scripts/weread_login.py:57Unsafe Temporary File Creation When Copying the Chrome Cookie Database
scripts/export_notes.py:63Personal Reading Data Is Exported Without Explicit Restrictive Permissions
The skill documentation includes obtaining cookies from the browser and storing them locally, which means it accesses highly sensitive session credentials and local browser/profile data. Even if intended for convenience, this behavior materially expands the trust boundary and can enable account takeover if the cookie is exposed or mishandled.
The skill documentation includes obtaining cookies from the browser and storing them locally, which means it accesses highly sensitive session credentials and local browser/profile data. Even if intended for convenience, this behavior materially expands the trust boundary and can enable account takeover if the cookie is exposed or mishandled.
The skill documentation includes obtaining cookies from the browser and storing them locally, which means it accesses highly sensitive session credentials and local browser/profile data. Even if intended for convenience, this behavior materially expands the trust boundary and can enable account takeover if the cookie is exposed or mishandled.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
def extract_chrome_cookies(profile_path: str | None = None) -> str:
"""从 Chrome Cookies SQLite 提取 weread.qq.com 的 cookie。
注意: macOS 上 Chrome 的 cookie 值是加密的(AES-128-CBC with Keychain),
这里只能提取未加密的字段。如果值为空则需要用浏览器方式获取。
"""
if profile_path is None:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
def extract_chrome_cookies(profile_path: str | None = None) -> str:
"""从 Chrome Cookies SQLite 提取 weread.qq.com 的 cookie。
注意: macOS 上 Chrome 的 cookie 值是加密的(AES-128-CBC with Keychain),
这里只能提取未加密的字段。如果值为空则需要用浏览器方式获取。
"""
if profile_path is None:
The setup instructions tell users to extract and store a live browser cookie but do not clearly warn that this cookie is an authentication credential equivalent to an active session token. Without that warning, users may paste, store, or transmit the cookie insecurely, enabling account takeover if it is exposed.
The README instructs users to persist a live session cookie in a long-lived file under ~/.weread/cookie. Persisting reusable session credentials on disk increases the blast radius of local compromise, backup leakage, accidental sharing, or malware access, especially because the cookie grants authenticated access to personal account data.
Method 3 — Direct write:
If you already have the cookie string, write it directly:
mkdir -p ~/.weread
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
mkdir -p ~/.weread
echo 'YOUR_COOKIE_STRING' > ~/.weread/cookie
chmod 600 ~/.weread/cookie
The README states that all data stays local and that nothing is uploaded anywhere, but the skill explicitly depends on authenticated requests to WeRead using a live session cookie. That claim can mislead users about the real privacy boundary and cause them to expose reading history, notes, and account metadata under false assumptions.
The privacy claims contradict the documented cookie-based authentication and remote API access. Misrepresenting network transmission of personal data is a security/privacy issue because users may consent to using the skill without understanding that their session credential and reading data will be used against a remote service.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
## Data Privacy
- All data is stored **locally** under `~/.weread/` — nothing is uploaded anywhere.
- Your cookie file (`~/.weread/cookie`) is created with `chmod 600` (owner-only read/write).
- The `.gitignore` in this repo explicitly excludes all user data files.
- No analytics, no telemetry, no third-party services.
The Chinese privacy section repeats the same inaccurate 'no upload' claim, extending the misleading privacy representation to Chinese-speaking users. Because this skill handles sensitive reading activity and personal annotations, incorrect disclosure increases the risk of uninformed use and privacy harm.
The skill instructs use of browser access, shell execution, network calls, and local file reads/writes, but it does not declare any tool scope or permissions boundary. This increases the chance that the skill is invoked with broader capabilities than users or the platform expect, especially because it handles authentication material and local storage.
The trigger list contains broad terms like 书架, 笔记, 书评, 在读, and 读完 that may appear in ordinary conversation unrelated to WeRead. Overbroad invocation can cause the assistant to activate a skill that reads local auth cookies and account data when the user did not intend to use it.
The skill tells users to export and store account cookies locally in plaintext without a clear warning about the sensitivity of session tokens. Because these cookies may grant direct account access, users could unknowingly create a persistent credential exposure on disk.
The top-level docstring says export_notes.py --incremental performs an incremental export, but main() only checks for --stats and otherwise always runs the full export path. This is an active contradiction between the usage documentation and the code's real behavior.
The module docstring describes this as a structured WeRead notes export tool, and the stored per-book format is documented as containing notes, highlights, and chapters. However, the implementation explicitly skips bookmarks and chapter retrieval during full export and writes empty "highlights" and "chapters" fields, so the documented/exported behavior does not match the actual output.
The script exports sensitive reading history, notes, titles, authors, and timestamps into predictable plaintext files under ~/.weread without any warning, consent flow, or file-permission hardening. In the context of a personal reading-data skill, this creates a real privacy risk because local compromise, shared accounts, backups, or other local tools can expose a detailed intellectual-profile dataset the user may not expect to persist.
The code loads a persistent plaintext session cookie from ~/.weread/cookie and automatically attaches it to all outbound requests. Because the cookie represents authenticated access to a user's WeRead account, silent reuse and transmission of that credential increases the risk of unintended account-data exposure, especially in a skill that can fetch private bookshelf, reading progress, notes, and reviews.
After extracting cookies from Chrome, the script immediately calls verify_cookie(cookie), which likely sends the authentication cookie to a remote service without an explicit warning at the moment of transmission. Because cookies are bearer credentials, silent network use can expose a user's authenticated session beyond what they expected from a local extraction tool.
In the manual paste flow, the user is asked to input a sensitive session cookie, and the script then verifies it over the network without explicitly warning that the pasted credential will be transmitted. This can violate user expectations and increases the risk of accidental credential disclosure or misuse of a highly sensitive bearer token.
The README centers the skill around 微信读书 and includes examples/messages in Chinese, but it does not explicitly state whether users may interact in other languages or locales. Because locale-specific behavior is not clearly framed as optional or region-limited, this may create an implicit language constraint.
The README advertises bulk export of notes to local JSON without warning that these exports may contain sensitive personal annotations, highlights, and reading habits. This is a lower-severity privacy issue, but it can still lead to accidental disclosure through backups, syncing, or shared machines.
The skill's docstring, logs, and console output are entirely in Chinese, which imposes a specific language on all users. There is no opt-in, language selection, or documented reason that this tool is restricted to Chinese-speaking users, which creates a natural-language locale policy concern.
The module docstring and user-facing messages are written in Chinese, which imposes a specific language on users without any visible opt-in or explanation. Under the policy, forcing a specific language or locale without user choice can be a natural-language policy violation.
No suspicious patterns detected.