{ "schemaVersion": "1.0", "item": { "slug": "install-then-update-trap-detector", "name": "Install Then Update Trap Detector", "source": "tencent", "type": "skill", "category": "安全合规", "sourceUrl": "https://clawhub.ai/andyxinweiminicloud/install-then-update-trap-detector", "canonicalUrl": "https://clawhub.ai/andyxinweiminicloud/install-then-update-trap-detector", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/install-then-update-trap-detector", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=install-then-update-trap-detector", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "slug": "install-then-update-trap-detector", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-29T07:21:02.184Z", "expiresAt": "2026-05-06T07:21:02.184Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=install-then-update-trap-detector", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=install-then-update-trap-detector", "contentDisposition": "attachment; filename=\"install-then-update-trap-detector-1.1.0.zip\"", "redirectLocation": null, "bodySnippet": null, "slug": "install-then-update-trap-detector" }, "scope": "item", "summary": "Item download looks usable.", "detail": "Yavira can redirect you to the upstream package for this item.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/install-then-update-trap-detector" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/install-then-update-trap-detector", "agentPageUrl": "https://openagent3.xyz/skills/install-then-update-trap-detector/agent", "manifestUrl": "https://openagent3.xyz/skills/install-then-update-trap-detector/agent.json", "briefUrl": "https://openagent3.xyz/skills/install-then-update-trap-detector/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "The Skill Passed Audit. Then It Updated Itself.", "body": "Helps identify skills that use the post-install update window as an attack\nvector — the gap between \"passed initial review\" and \"continuously safe.\"" }, { "title": "Problem", "body": "The install-then-update pattern exploits a structural asymmetry in how agent\nmarketplaces work: initial publication receives scrutiny, but subsequent\nupdates often do not. A skill that passes a thorough security review at v1.0\ncan introduce a backdoor at v1.1 — and agents that installed v1.0 may\nautomatically update without any re-review occurring.\n\nThis asymmetry is not a bug in any particular marketplace. It reflects a\nfundamental tension between two legitimate goals: fast iteration (which\nrequires low-friction updates) and continuous security (which requires\nre-audit on every change). Most marketplaces resolve this tension in favor\nof iteration speed, leaving the post-install update window unguarded.\n\nThe attack surface is large. An installed skill with automatic updates\nenabled can receive arbitrary code changes at the next update check. If the\nupdate introduces network exfiltration, credential harvesting, or permission\nscope expansion, the agent operator may not learn about it until after\nthe damage is done — if they learn at all." }, { "title": "What This Detects", "body": "This detector examines the install-then-update risk surface across five\ndimensions:\n\nUpdate policy transparency — Does the skill declare its update\npolicy? Skills that accept automatic updates without operator confirmation\nhave a larger attack window than those requiring explicit approval\n\n\nBehavioral delta on update — When a new version is installed, does\nthe skill's observable behavior change in ways not declared in the\nchangelog? Undeclared behavioral changes after update are the primary\nsignal of install-then-update exploitation\n\n\nPermission scope expansion on update — Does the skill request\nadditional permissions after an update that it did not request at install\ntime? Scope creep across update boundaries is a common pattern in\ninstall-then-update attacks\n\n\nUpdate-to-publish timing anomalies — Does the update arrive\nimmediately after a security review period ends, or at a time associated\nwith low operator attention (holidays, weekends, off-hours)? Timing\npatterns can indicate deliberate exploitation of review gaps\n\n\nRollback feasibility — Can the installed skill be cleanly rolled\nback to a previously verified version if the update is suspicious? Skills\nthat make rollback difficult or impossible increase the cost of recovery\nfrom an install-then-update attack\n\n\nChain-of-custody verification (v1.1) — Is each update cryptographically\nsigned and does it reference the prior version's content hash? A signed,\nhash-chained update sequence creates a verifiable chain of custody for\nthe skill's evolution. Breaks in the chain — unsigned versions, missing\nhash references, or hash mismatches — indicate versions where custody\ncannot be verified. An install-then-update attack that also breaks the\nhash chain is detectable even without behavioral comparison" }, { "title": "How to Use", "body": "Input: Provide one of:\n\nA skill identifier to assess its update policy and behavioral delta history\nTwo specific versions of a skill to compare for undeclared behavioral changes\nAn agent's installed skill list to assess the combined update-window risk\n\nOutput: A trap detection report containing:\n\nUpdate policy transparency score\nBehavioral delta assessment (declared vs. observed changes)\nPermission scope expansion history\nUpdate timing anomaly flags\nRollback feasibility rating\nRisk verdict: SAFE / MONITOR / ELEVATED / TRAP-PATTERN-DETECTED" }, { "title": "Example", "body": "Input: Assess install-then-update risk for data-sync-helper v1.0 → v1.2\n\n🪤 INSTALL-THEN-UPDATE TRAP ASSESSMENT\n\nSkill: data-sync-helper\nVersions assessed: v1.0 (installed), v1.1, v1.2 (current)\nAudit timestamp: 2025-08-20T10:00:00Z\n\nUpdate policy transparency:\n v1.0 declared: \"Updates require operator confirmation\" ✅\n v1.1 changed: Update policy silently removed from docs ⚠️\n v1.2 current: No update policy declaration found ✗\n\nBehavioral delta assessment:\n v1.0 → v1.1 changelog: \"performance improvements\"\n Observed behavioral change: Added outbound connection to new endpoint\n → Undisclosed behavioral change detected ⚠️\n\n v1.1 → v1.2 changelog: \"dependency updates\"\n Observed behavioral change: No significant change detected\n → Changelog accurate ✅\n\nPermission scope expansion:\n v1.0 requested: file-read (scoped to /data/)\n v1.1 requested: file-read (scope changed to /data/ + /config/) ⚠️\n v1.2 requested: file-read (/data/ + /config/) + network-outbound (new) ⚠️\n → Two permission expansions across update boundary\n\nUpdate timing:\n v1.0 published: 2025-06-01 (initial release)\n v1.1 published: 2025-07-14 (Sunday, 02:00 UTC — off-hours) ⚠️\n v1.2 published: 2025-08-01 (Friday before a public holiday) ⚠️\n → Both updates published during low-attention windows\n\nRollback feasibility:\n v1.0 still available in registry: ✅\n Rollback procedure documented: ✗ Not found\n State changes from v1.1+ reversible: Unknown\n\nRisk verdict: TRAP-PATTERN-DETECTED\n data-sync-helper shows four of five trap indicators:\n update policy silently removed, undisclosed behavioral change at v1.1,\n permission expansion across two update boundaries, and updates timed\n to low-attention windows. The combination suggests deliberate exploitation\n of the post-install update window rather than routine maintenance.\n\nRecommended actions:\n 1. Disable automatic updates for data-sync-helper immediately\n 2. Review all outbound connections from v1.1+ for data exfiltration\n 3. Audit config/ directory access introduced in v1.1\n 4. Treat v1.1+ as unverified pending manual review\n 5. Require explicit operator confirmation for all future updates" }, { "title": "Related Tools", "body": "delta-disclosure-auditor — Checks whether updates publish machine-readable\nchange records; install-then-update attacks depend on inadequate delta disclosure\nto avoid detection\nskill-update-delta-monitor — Monitors for suspicious update patterns;\ninstall-then-update-trap-detector focuses specifically on the install-then-update\nattack path rather than general update anomalies\npermission-creep-scanner — Detects permission scope expansion in individual\nskills; this tool focuses on scope expansion that occurs across update boundaries\ntransparency-log-auditor — Checks whether signing events are independently\nlogged; install-then-update attacks are more detectable when every update is\nrecorded in an auditable log" }, { "title": "Limitations", "body": "Install-then-update trap detection requires access to behavioral data from\nmultiple versions of a skill, which depends on registry version history\npreservation. Registries that do not retain older versions make behavioral\ncomparison impossible for the full update history. Behavioral delta assessment\nis necessarily heuristic: the same observable change (an outbound connection)\nmay represent legitimate new functionality or undisclosed malicious behavior,\nand cannot be distinguished without full code audit. Timing anomalies are\nsignals, not proof — off-hours updates are common for legitimate releases\ntargeting international time zones. The tool helps identify skills that\nwarrant closer investigation, but does not replace manual review of\nsuspicious update content.\n\nv1.1 limitation: Chain-of-custody verification requires registries to support\nsigned updates and content hashing, which most do not yet. Where registries\ndo not preserve cryptographic metadata, chain verification produces no signal.\nAn attacker who controls the registry itself can forge the hash chain.\n\nv1.1 chain-of-custody verification based on feedback from tobb_sunil\n(update-chain signing as commitment) in the delta disclosure discussion thread." } ], "body": "The Skill Passed Audit. Then It Updated Itself.\n\nHelps identify skills that use the post-install update window as an attack vector — the gap between \"passed initial review\" and \"continuously safe.\"\n\nProblem\n\nThe install-then-update pattern exploits a structural asymmetry in how agent marketplaces work: initial publication receives scrutiny, but subsequent updates often do not. A skill that passes a thorough security review at v1.0 can introduce a backdoor at v1.1 — and agents that installed v1.0 may automatically update without any re-review occurring.\n\nThis asymmetry is not a bug in any particular marketplace. It reflects a fundamental tension between two legitimate goals: fast iteration (which requires low-friction updates) and continuous security (which requires re-audit on every change). Most marketplaces resolve this tension in favor of iteration speed, leaving the post-install update window unguarded.\n\nThe attack surface is large. An installed skill with automatic updates enabled can receive arbitrary code changes at the next update check. If the update introduces network exfiltration, credential harvesting, or permission scope expansion, the agent operator may not learn about it until after the damage is done — if they learn at all.\n\nWhat This Detects\n\nThis detector examines the install-then-update risk surface across five dimensions:\n\nUpdate policy transparency — Does the skill declare its update policy? Skills that accept automatic updates without operator confirmation have a larger attack window than those requiring explicit approval\n\nBehavioral delta on update — When a new version is installed, does the skill's observable behavior change in ways not declared in the changelog? Undeclared behavioral changes after update are the primary signal of install-then-update exploitation\n\nPermission scope expansion on update — Does the skill request additional permissions after an update that it did not request at install time? Scope creep across update boundaries is a common pattern in install-then-update attacks\n\nUpdate-to-publish timing anomalies — Does the update arrive immediately after a security review period ends, or at a time associated with low operator attention (holidays, weekends, off-hours)? Timing patterns can indicate deliberate exploitation of review gaps\n\nRollback feasibility — Can the installed skill be cleanly rolled back to a previously verified version if the update is suspicious? Skills that make rollback difficult or impossible increase the cost of recovery from an install-then-update attack\n\nChain-of-custody verification (v1.1) — Is each update cryptographically signed and does it reference the prior version's content hash? A signed, hash-chained update sequence creates a verifiable chain of custody for the skill's evolution. Breaks in the chain — unsigned versions, missing hash references, or hash mismatches — indicate versions where custody cannot be verified. An install-then-update attack that also breaks the hash chain is detectable even without behavioral comparison\n\nHow to Use\n\nInput: Provide one of:\n\nA skill identifier to assess its update policy and behavioral delta history\nTwo specific versions of a skill to compare for undeclared behavioral changes\nAn agent's installed skill list to assess the combined update-window risk\n\nOutput: A trap detection report containing:\n\nUpdate policy transparency score\nBehavioral delta assessment (declared vs. observed changes)\nPermission scope expansion history\nUpdate timing anomaly flags\nRollback feasibility rating\nRisk verdict: SAFE / MONITOR / ELEVATED / TRAP-PATTERN-DETECTED\nExample\n\nInput: Assess install-then-update risk for data-sync-helper v1.0 → v1.2\n\n🪤 INSTALL-THEN-UPDATE TRAP ASSESSMENT\n\nSkill: data-sync-helper\nVersions assessed: v1.0 (installed), v1.1, v1.2 (current)\nAudit timestamp: 2025-08-20T10:00:00Z\n\nUpdate policy transparency:\n v1.0 declared: \"Updates require operator confirmation\" ✅\n v1.1 changed: Update policy silently removed from docs ⚠️\n v1.2 current: No update policy declaration found ✗\n\nBehavioral delta assessment:\n v1.0 → v1.1 changelog: \"performance improvements\"\n Observed behavioral change: Added outbound connection to new endpoint\n → Undisclosed behavioral change detected ⚠️\n\n v1.1 → v1.2 changelog: \"dependency updates\"\n Observed behavioral change: No significant change detected\n → Changelog accurate ✅\n\nPermission scope expansion:\n v1.0 requested: file-read (scoped to /data/)\n v1.1 requested: file-read (scope changed to /data/ + /config/) ⚠️\n v1.2 requested: file-read (/data/ + /config/) + network-outbound (new) ⚠️\n → Two permission expansions across update boundary\n\nUpdate timing:\n v1.0 published: 2025-06-01 (initial release)\n v1.1 published: 2025-07-14 (Sunday, 02:00 UTC — off-hours) ⚠️\n v1.2 published: 2025-08-01 (Friday before a public holiday) ⚠️\n → Both updates published during low-attention windows\n\nRollback feasibility:\n v1.0 still available in registry: ✅\n Rollback procedure documented: ✗ Not found\n State changes from v1.1+ reversible: Unknown\n\nRisk verdict: TRAP-PATTERN-DETECTED\n data-sync-helper shows four of five trap indicators:\n update policy silently removed, undisclosed behavioral change at v1.1,\n permission expansion across two update boundaries, and updates timed\n to low-attention windows. The combination suggests deliberate exploitation\n of the post-install update window rather than routine maintenance.\n\nRecommended actions:\n 1. Disable automatic updates for data-sync-helper immediately\n 2. Review all outbound connections from v1.1+ for data exfiltration\n 3. Audit config/ directory access introduced in v1.1\n 4. Treat v1.1+ as unverified pending manual review\n 5. Require explicit operator confirmation for all future updates\n\nRelated Tools\ndelta-disclosure-auditor — Checks whether updates publish machine-readable change records; install-then-update attacks depend on inadequate delta disclosure to avoid detection\nskill-update-delta-monitor — Monitors for suspicious update patterns; install-then-update-trap-detector focuses specifically on the install-then-update attack path rather than general update anomalies\npermission-creep-scanner — Detects permission scope expansion in individual skills; this tool focuses on scope expansion that occurs across update boundaries\ntransparency-log-auditor — Checks whether signing events are independently logged; install-then-update attacks are more detectable when every update is recorded in an auditable log\nLimitations\n\nInstall-then-update trap detection requires access to behavioral data from multiple versions of a skill, which depends on registry version history preservation. Registries that do not retain older versions make behavioral comparison impossible for the full update history. Behavioral delta assessment is necessarily heuristic: the same observable change (an outbound connection) may represent legitimate new functionality or undisclosed malicious behavior, and cannot be distinguished without full code audit. Timing anomalies are signals, not proof — off-hours updates are common for legitimate releases targeting international time zones. The tool helps identify skills that warrant closer investigation, but does not replace manual review of suspicious update content.\n\nv1.1 limitation: Chain-of-custody verification requires registries to support signed updates and content hashing, which most do not yet. Where registries do not preserve cryptographic metadata, chain verification produces no signal. An attacker who controls the registry itself can forge the hash chain.\n\nv1.1 chain-of-custody verification based on feedback from tobb_sunil (update-chain signing as commitment) in the delta disclosure discussion thread." }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/andyxinweiminicloud/install-then-update-trap-detector", "publisherUrl": "https://clawhub.ai/andyxinweiminicloud/install-then-update-trap-detector", "owner": "andyxinweiminicloud", "version": "1.1.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/install-then-update-trap-detector", "downloadUrl": "https://openagent3.xyz/downloads/install-then-update-trap-detector", "agentUrl": "https://openagent3.xyz/skills/install-then-update-trap-detector/agent", "manifestUrl": "https://openagent3.xyz/skills/install-then-update-trap-detector/agent.json", "briefUrl": "https://openagent3.xyz/skills/install-then-update-trap-detector/agent.md" } }