dsh-weixin-channel

An unattended detached process (started from index.mjs according to deploy.mjs comments) loops forever, and when mount-status is not 'running' it performs destructive string surgery on <DSH_HOME>/profiles/*/cordis.patch.yml: it truncates the file to `${prefix} ]` for 10s and then re-inserts the block under a new id. If the target YAML does not match the hard-coded MARKER shape, the write can truncate or corrupt the host's profile configuration while the host is live. It also keeps editing host config after the plugin itself has been unloaded (only a watchdog.off file or total absence of the ro

The scanned QR URL is the artifact that binds the account to whoever scans it first. It is written with default permissions into <DSH_HOME>/weixin/login-qr-url.txt and appended to login-progress.log (and channel.log via lib/log.mjs appendToFile, which also uses default mode), and nothing in the harvested code deletes these entries after login. Because the state directory is created with default 0755 and files with umask-derived 0644, another local user can read a still-valid QR URL and complete the scan, or read past URLs and login metadata. lib/log.mjs defines redact() but it is not applied t

When stdin is not a TTY the login flow polls <DSH_HOME>/weixin/verify-code.txt for 180s and forwards whatever is inside to the ilink server as the confirmation code. Any local process or user that can write into that directory can inject or race a code (and the file is read/returned with no ownership, permission or content-length check). Precondition is a login in progress plus local write access, so this is a local-trust hardening gap rather than a remote attack.

writeJson() only chmods when a mode argument is supplied; saveAccount passes 0o600, but setContextToken (and saveSyncBuf / appendAllowFrom / setSessionId) do not, so <accountId>.context-tokens.json, .sync.json, .allowFrom.json and sessions.json are created with umask-derived 0644 inside a 0755 directory. Context tokens are the per-conversation reply credentials used to send messages as the bot, so they are readable by other local users on a multi-user host.

login.mjs takes status.baseurl on 'confirmed' and https://<status.redirect_host> on 'scaned_but_redirect', and bin/weixin-login.mjs saves result.baseUrl into the account file; store.resolveAccount then returns it as account.baseUrl, which monitor sends the bot token to. Any response from the ilink endpoint (or a compromised/MITM'd TLS peer) can therefore redirect the persisted credential and all subsequent polling to an arbitrary host, with no allow-list check against *.weixin.qq.com.