Security audit
Security checks for vulnerabilities and agentic risk
Review is recommended because the skill includes consequential account changes and saves login sessions without enforcing private file permissions.
Before use, require a specific user request for every account change or message and replace example values with the intended values while preserving existing preferences. Store cookies in a private directory with owner-only permissions, avoid entering passwords into shell history, and remove session files afterward. Both bundled files were reviewed to investigate scanner coverage gaps; actual portal responses and host permissions remain unverified.
The declared purpose describes accessing and retrieving portal data. The supplied code instead performs an account-changing POST to /accounts/update/. Writing profile fields and changing notification settings are substantive capabilities not disclosed by the read-oriented description; the subsequent verification request does not make those changes a supporting retrieval detail.
The description presents the skill as retrieving portal information, with login as a supporting POST operation. This code instead posts a customer service report. Although it targets the same portal, reporting a missed pickup is a distinct write capability rather than a supporting detail of data retrieval.
The declared purpose covers accessing portal data, with a login POST as a supporting authentication step. This snippet instead performs a separate support-form submission. Although the inquiry concerns pickup information, sending a message is an additional write action not disclosed in the description.
The portal resources are consistent with the description, but the code performs a state-changing operation. Although the description mentions skips, it frames the skill as retrieving data after login and does not disclose the ability to create or change skips. The subsequent calendar request verifies the requested modification.
The endpoint is consistent with the declared portal, but the operation changes account service state. Although the description mentions skips, it frames the capability as accessing data and fetching JSON or rendered pages; it does not declare submitting skip requests. The supplied chunk therefore adds an undeclared write capability.
Referenced artifact was not completely inspected
## Writes (all POST; see `references/endpoints.md` for full field lists)
The setup creates a persistent session-cookie file without enforcing private permissions; with a common umask of 022 and traversable home directories, other local users could read it and reuse the authenticated session. Typing the literal password export can also retain it in shell history, while exporting it unnecessarily propagates it to child processes.
Session persistence is legitimate here, but the cookie jar is created through ordinary shell redirection without a restrictive umask or explicit permissions. Where filesystem permissions allow another local user to read it, the stored session cookie can grant access to private portal data and account-changing operations.
export CROWNTOWN_PASSWORD='your-portal-password' # or: op read "op://Private/CrownTown/password" export CT=https://portal.crowntowncompost.com JAR=~/.cache/crowntown-cookies.txt mkdir -p ~/.cache && : > "$JAR"
## Log in (get the session cookie)
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# 2. POST the credentials. Do NOT follow redirects (-L) here: the 302's
# Set-Cookie carries the sessionid, and success is "302 away from login".
printf '%s' "$CROWNTOWN_PASSWORD" | curl -s -c "$JAR" -b "$JAR" \
-H "X-CSRFToken: $CSRF_COOKIE" -H "Origin: $CT" \
-H "Referer: $CT/accounts/login/?next=/accounts/" \
--data-urlencode "csrfmiddlewaretoken=$CSRF_FORM" \
The manifest at L004–L010 describes accessing customer data by logging in and fetching JSON endpoints and server-rendered pages. However, L211–L217 instruct POST operations for modifying account details and notification preferences, reporting missed pickups, contacting support, and requesting cancellation. These consequential writes and sends exceed the described data-access workflow.
The manifest describes retrieving Crown Town Compost data through JSON endpoints and server-rendered pages. However, the executable recipes submit missed-pickup reports (L184–L187), overwrite account identity/contact fields and disable an email preference (L196–L200), and send support messages (L212–L215). These create remote side effects rather than merely retrieving the declared account and service information.