## Issue Triage — 2026-04-21 ### 1) Private security vulnerabilities disclosure (awaiting maintainer triage) — **SEC-PRIV-2026-04-18** - **Current Status:** Privately disclosed by researcher “kullai” to **odilitime**; receipt acknowledged; no public tracking issue. - **Impact Assessment:** - **User Impact:** High (unknown scope until reproduced) - **Functional Impact:** Partial (could become “Yes” depending on exploitability) - **Brand Impact:** High (security posture + community trust) - **Technical Classification:** - **Category:** Security - **Component Affected:** Core Framework (unspecified), possibly Plugin System/runtime surfaces - **Complexity:** Complex solution (pending details); could require architectural hardening - **Resource Requirements:** - **Required Expertise:** Security triage, secure coding, threat modeling, responsible disclosure handling - **Dependencies:** Needs reproducible steps / PoC details from reporter; may require coordinated patch + release - **Estimated Effort:** 4/5 (triage + fix + regression + coordinated release) - **Recommended Priority:** **P0** - **Specific Actionable Next Steps:** 1. Create a private security advisory/workspace (GitHub Security Advisory) and track as embargoed. 2. Request PoC, affected versions, and impact statement (CIA triad) from reporter. 3. Reproduce in a clean environment; determine exploit preconditions (local/remote, auth required, default config). 4. Implement fix + add regression tests; prepare patched releases and backports if needed. 5. Publish a concise security notice post-fix with upgrade guidance. - **Potential Assignees:** **odilitime** (security intake), **lalalune** (core/runtime), **stan0473** (core dev review) --- ### 2) PR includes malware-like autonomous shell agent package (“virus”) — **elizaos/eliza PR #6613** - **Current Status:** Open/unmerged; automated review flags RAT-like behaviors (persistence, stealth/idle activation, unrestricted shell exec). - **Impact Assessment:** - **User Impact:** Medium (only if merged/distributed), but **risk is extreme** - **Functional Impact:** No (not core), but introduces dangerous surface area - **Brand Impact:** **Critical** (association with malware patterns; potential platform trust collapse) - **Technical Classification:** - **Category:** Security - **Component Affected:** Repository governance / packages distribution - **Complexity:** Simple fix (reject/remove) + process follow-up - **Resource Requirements:** - **Required Expertise:** Security + maintainership/governance - **Dependencies:** None - **Estimated Effort:** 2/5 - **Recommended Priority:** **P0** - **Specific Actionable Next Steps:** 1. Close PR with explicit rationale (unsafe behavior; violates security policy). 2. Add/clarify contribution policy prohibiting persistence + autonomous shell exec examples in core repo. 3. If educational examples are desired, move to an external “unsafe-research” repo with prominent warnings and no branding. 4. Add CI checks / review gates for packages that execute shell commands or add persistence hooks. - **Potential Assignees:** **odilitime**, **stan0473** (policy + final decision), **lalalune** (repo hygiene/guardrails) --- ### 3) Discord phishing/airdrop/support-ticket scams impacting users (recurring) — **DISCORD-SEC-2026-04 (ongoing)** - **Current Status:** Multiple scam incidents; users lost funds; scammers banned, but pattern persists. - **Impact Assessment:** - **User Impact:** High (broad community exposure; demonstrated losses) - **Functional Impact:** Partial (community support channel reliability degraded) - **Brand Impact:** High (perceived as unsafe ecosystem) - **Technical Classification:** - **Category:** Security / UX - **Component Affected:** Discord operations, community support workflows, moderation automation - **Complexity:** Moderate effort - **Resource Requirements:** - **Required Expertise:** Discord moderation, anti-phishing ops, basic automation/bot configuration - **Dependencies:** Discord permissions, possibly bot tooling; coordination with mods - **Estimated Effort:** 3/5 - **Recommended Priority:** **P0** - **Specific Actionable Next Steps:** 1. Pin a single canonical “No airdrops / no tickets / official links” security banner in high-traffic channels. 2. Disable/limit automated “support ticket” flows if they can be spoofed; enforce verified-only support entry points. 3. Add AutoMod rules: block known scam keywords/domains; rate-limit new accounts; restrict link posting for newcomers. 4. Publish a short “How to verify staff + official channels” doc and link it in Discord server description. 5. Create an incident intake template for mods (screenshots, user ID, message link) for faster takedowns. - **Potential Assignees:** **odilitime** (Community Ops), **spankyxn** (security comms), **satsbased** (mod escalation), **stackvector** (community support) --- ### 4) Memory corruption/incorrect room association on update — **elizaos/eliza PR #6965** (“handle roomId changes in InMemoryDatabaseAdapter.updateMemories”) - **Current Status:** Fix implemented; needs verification in release artifacts and regression coverage. - **Impact Assessment:** - **User Impact:** Medium–High (agents with multi-room usage; memory appears “missing” or cross-contaminated) - **Functional Impact:** Partial (core memory correctness; affects agent behavior quality) - **Brand Impact:** Medium (agents appear unreliable) - **Technical Classification:** - **Category:** Bug - **Component Affected:** Core Framework (InMemory DB adapter / memory layer) - **Complexity:** Simple fix (already coded) + tests - **Resource Requirements:** - **Required Expertise:** TypeScript core, memory semantics, regression testing - **Dependencies:** Ensure downstream adapters follow same semantic contract - **Estimated Effort:** 2/5 - **Recommended Priority:** **P1** - **Specific Actionable Next Steps:** 1. Add/confirm a regression test that updates a memory’s `roomId` and asserts removal from old room + presence in new room. 2. Audit other adapters (SQL, etc.) for equivalent “move room” semantics. 3. Ensure this is included in next alpha/stable release notes as a behavior correctness fix. - **Potential Assignees:** **lalalune**, **avasis-ai** (author), **odilitime** (release coordination) --- ### 5) app-lifeops Discord routing regressions — **elizaos/eliza PR #6971** - **Current Status:** Fix landed (routing + submodule bumps); needs deployment validation and monitoring. - **Impact Assessment:** - **User Impact:** Medium (lifeops users; missed/incorrect routing breaks reliability) - **Functional Impact:** Yes (messaging/routing is core for lifeops workflows) - **Brand Impact:** Medium–High (communication reliability is user-facing) - **Technical Classification:** - **Category:** Bug - **Component Affected:** App (app-lifeops) + Discord integration - **Complexity:** Moderate effort (integration + routing edge cases) - **Resource Requirements:** - **Required Expertise:** app-lifeops, Discord event routing, submodule management - **Dependencies:** Release pipeline / deployment environment - **Estimated Effort:** 3/5 - **Recommended Priority:** **P1** - **Specific Actionable Next Steps:** 1. Run an end-to-end routing test matrix (DMs, guild channels, threads, cross-channel send). 2. Add logging/metrics around route selection to catch misroutes quickly. 3. Confirm submodule versions are pinned and reproducible in CI. - **Potential Assignees:** **lalalune**, **odilitime**, **RemilioNubilio** (Discord UX context) --- ### 6) Registry integration review for Elisym marketplace plugin — **elizaos-plugins/registry PR #346** (`@elisym/plugin-elizaos-elisym`) - **Current Status:** PR open for review; plugin renamed per naming convention; claims strong test coverage + provenance. - **Impact Assessment:** - **User Impact:** Medium (ecosystem growth; paid-provider capability) - **Functional Impact:** No (non-core), but strategic value for monetization narrative - **Brand Impact:** Medium (quality of third-party plugin acceptance process) - **Technical Classification:** - **Category:** Feature Request / Integration - **Component Affected:** Plugin System + Registry - **Complexity:** Moderate effort (security review + registry compliance) - **Resource Requirements:** - **Required Expertise:** Plugin registry standards, supply-chain/security review (Nostr + payments), CI validation - **Dependencies:** Registry policy checks; documentation updates for new plugin name - **Estimated Effort:** 3/5 - **Recommended Priority:** **P2** - **Specific Actionable Next Steps:** 1. Review registry PR for metadata correctness, naming, versioning, and install instructions. 2. Perform a lightweight security review: key handling, payment flows, encrypted job request handling, dependency audit. 3. Require a minimal “Capabilities + Threat model” section in README for marketplace/payment plugins. 4. Merge + announce once verified; add to “officially listed plugins” page. - **Potential Assignees:** **stan0473** (standards), **odilitime** (final approval), **igor.peregudov** (follow-ups) --- ### 7) Missing provider plugin guidance: MiniMax “token plan key” integration request — **DISCORD-REQ-2026-04-20** - **Current Status:** Unanswered request in Discord; no GitHub issue created. - **Impact Assessment:** - **User Impact:** Medium (blocks a subset of builders using MiniMax) - **Functional Impact:** Partial (model/provider integration path unclear) - **Brand Impact:** Medium (perception: “hard to integrate providers”) - **Technical Classification:** - **Category:** Documentation / Feature Request - **Component Affected:** Model Integration / Provider plugins - **Complexity:** Moderate effort - **Resource Requirements:** - **Required Expertise:** Provider/plugin authoring, secrets management, docs - **Dependencies:** Confirm MiniMax API auth patterns; decide whether official plugin is desired - **Estimated Effort:** 3/5 - **Recommended Priority:** **P2** - **Specific Actionable Next Steps:** 1. Create a GitHub issue with: expected behavior, config schema, example character config, environment variables. 2. Decide: (a) community plugin template, or (b) official provider plugin. 3. Add a “How to add a new provider” doc page including key storage + rotation guidance. - **Potential Assignees:** **NubsCarson** (model/provider stability), **dutchiono** (docs + integration polish), **odilitime** (triage) --- ### 8) Docs gap: “What you can build” page doesn’t explain how to build examples — **DOCS-UX-2026-04-20** - **Current Status:** Users ask for tutorials; redirected to `examples/` directory, but docs flow remains confusing. - **Impact Assessment:** - **User Impact:** Medium–High (new users onboarding) - **Functional Impact:** No (but slows adoption) - **Brand Impact:** Medium (developer experience perception) - **Technical Classification:** - **Category:** Documentation / UX - **Component Affected:** Docs site + examples - **Complexity:** Simple fix - **Resource Requirements:** - **Required Expertise:** Technical writing, examples validation in CI - **Dependencies:** Ensure examples build commands are current for v2.x and bun/node requirements - **Estimated Effort:** 2/5 - **Recommended Priority:** **P2** - **Specific Actionable Next Steps:** 1. Add a “Run these examples” section: prerequisites, exact commands, common failure modes. 2. Link each showcased build to a specific example folder + pinned version/tag. 3. Add CI smoke tests for top 3 examples to prevent doc rot. - **Potential Assignees:** **vincent067** (docs contributor), **lalalune** (DX/CI), **odilitime** (docs approval) --- ### 9) Ecosystem/token utility confusion (ElizaOS vs ElizaOK vs elizacloud) — **DOCS-ECOSYSTEM-2026-04** - **Current Status:** Repeated community confusion; partial clarification given; detailed explanation deferred. - **Impact Assessment:** - **User Impact:** High (broad community; recurring questions) - **Functional Impact:** Partial (affects adoption, purchasing decisions, support load) - **Brand Impact:** High (trust + legitimacy concerns in web3 context) - **Technical Classification:** - **Category:** Documentation / UX - **Component Affected:** Product docs, official comms - **Complexity:** Moderate effort (requires alignment + precise language) - **Resource Requirements:** - **Required Expertise:** Product/tech leadership alignment, documentation, community ops - **Dependencies:** Internal clarity on token utility messaging + chain deployments + user flows - **Estimated Effort:** 3/5 - **Recommended Priority:** **P1** - **Specific Actionable Next Steps:** 1. Publish a single canonical “Ecosystem map” doc: products, user flow, tokens (or lack thereof), supported chains. 2. Add an FAQ entry for token tickers/chains and official contract addresses (where appropriate). 3. Ensure Discord auto-replies or pinned messages link to this canonical doc. - **Potential Assignees:** **odilitime** (source-of-truth), **baogerbao** (context), **satsbased** (announcement amplification) --- ### 10) Standardizing agent commerce for tool/service payments (new proposal) — **A2A-COMMERCE-PROP-2026-04-20** - **Current Status:** New proposal opened; prior Merxex-specific proposals reviewed/closed; direction shifting toward a standard. - **Impact Assessment:** - **User Impact:** Medium (builders shipping paid agents; ecosystem integrators) - **Functional Impact:** Partial (not required for core operation; important for v3 monetization story) - **Brand Impact:** Medium–High (positions elizaOS as “commerce-ready”) - **Technical Classification:** - **Category:** Feature Request / Architectural change - **Component Affected:** Core Framework (action execution receipts), Plugin System, Payments interfaces - **Complexity:** Architectural change - **Resource Requirements:** - **Required Expertise:** Protocol design, security (signing/receipts), plugin APIs, payments - **Dependencies:** Decide on identity primitives, receipt format, escrow/payment rails, threat model - **Estimated Effort:** 5/5 - **Recommended Priority:** **P2** (design now; implement iteratively) - **Specific Actionable Next Steps:** 1. Define minimal spec: payment intent, quote, execution receipt, dispute/timeout semantics. 2. Decide the “core vs plugin” boundary (what must be in core to standardize?). 3. Produce a reference implementation plugin + conformance tests. - **Potential Assignees:** **odilitime**, **lalalune**, **stan0473**, plus marketplace plugin authors (e.g., **igor.peregudov**) for feedback --- ## Highest-Priority Summary (Top 5–10 to address immediately) 1. **P0:** **SEC-PRIV-2026-04-18** — Triage and remediate privately disclosed vulnerabilities (coordinate fix + release). 2. **P0:** **PR #6613** — Prevent merging/distributing malware-like package; add governance guardrails. 3. **P0:** **DISCORD-SEC-2026-04** — Reduce phishing/scam surface area with AutoMod + pinned canonical guidance. 4. **P1:** **DOCS-ECOSYSTEM-2026-04** — Publish canonical ecosystem/token utility explanation to reduce confusion and support load. 5. **P1:** **PR #6971** — Validate lifeops Discord routing fix in production-like tests and monitor post-deploy. 6. **P1:** **PR #6965** — Ensure memory roomId move fix has regression tests and is shipped in next release notes. 7. **P2:** **Registry PR #346** — Review Elisym plugin integration (security + compliance) and merge if clean. 8. **P2:** **DOCS-UX-2026-04-20** — Add build/run tutorial for examples to improve onboarding. 9. **P2:** **DISCORD-REQ-2026-04-20** — Create issue and guidance for MiniMax provider integration. 10. **P2:** **A2A-COMMERCE-PROP-2026-04-20** — Start standard spec work for agent commerce; avoid fragmented one-off integrations. --- ## Patterns / Themes Indicating Deeper Issues - **Security surface area is expanding faster than policy/process:** third-party plugins + autonomous agents + payments + shell/tool access need clearer boundaries and review gates. - **Docs and “source of truth” gaps are driving repeated community questions:** ecosystem/token utility ambiguity and example build steps create ongoing support burden. - **Operational trust is being attacked externally (Discord scams):** community channels need systematic hardening, not just reactive bans. - **Reliability bugs cluster around state/routing/memory semantics:** room-scoped memory and Discord routing show that correctness in “multi-context” operation remains a recurring risk area. --- ## Process Improvement Recommendations 1. **Adopt a formal Security Policy + Disclosure workflow** (SECURITY.md, security@ contact, GitHub Security Advisories, SLA targets). 2. **Introduce a “high-risk contribution” review checklist** for PRs involving: shell execution, persistence, wallet/payment handling, dynamic code execution, or credential storage. 3. **Create canonical docs + pinned comms**: - “Official links + no-airdrops” page for Discord - “Ecosystem map + token utility” page - “Run examples” quickstart with versioned commands 4. **Add regression tests for multi-context correctness** (room changes, routing selection, cross-channel send) and require them for related fixes. 5. **Registry acceptance criteria for commerce/security-sensitive plugins** (threat model section, key handling guidelines, dependency audit expectations, provenance/signing encouragement).