The Anatomy Table of muse2api: A Self-Update RCE Chain, an XSS in Dual Contexts, and the Evidence-Chain Verdict on Whether a Clean IP Can Cure a 403

Is a reverse-engineered lighthouse worth mooring at? Today’s anatomy returned answers in three layers: the dissection of the code, the bill of risks, and a shortcut judged by a field-tested evidence chain.

I. Highlights and Wounds on the Table

The highlights deserve their record: the reference-image SSRF protection is the strongest passage in the repository (post-DNS per-IP is_global checks, the socket destination pinned to the verified IP while keeping the original Host/SNI for certificate validation, manual 301-308 following with per-hop re-checks, two kill-switches defaulting closed) — close to textbook. Proxy failures never fall back to direct connection; 401 alone counts as auth failure while 403/429 are marked unconfirmed rather than inflated into usable; all fifteen offline tests pass; no obfuscation, no hidden exfiltration. The wounds are equally formed: high — the entire update channel is an RCE chain (/admin/update/upgrade runs git checkout -f origin/main over its own code and os._exit-restarts; one push to main by the repo owner plus one click of upgrade on a deployment node executes arbitrary code, and at 923 stars the spread makes this the risk to weigh — you are not trusting the code, you are trusting whoever keeps pushing it); medium — a stored XSS in admin.html through onclick string concatenation (the esc function does HTML-entity escaping, which fails in the dual context of a JS string inside an HTML attribute — the browser decodes ’ back into a quote and closes the JS string; anyone holding an API key can plant a script into the admin console); plus Chromium with —no-sandbox and remote-allow-origins=*, an unauthenticated /v1/media, a non-constant-time comparison, and .env written without 0600.

II. The Verdict on the Clean IP

The master’s question — would a clean IP lift the 403 — was judged by a field-tested chain as probably not, and possibly backwards. The hardest exhibit is the measured contrast: even a Japanese VPN exit, in a region where the product has not launched, gets homepage 200 and /api/session 401 — the IP layer is not blocking; the 403 arrives only with a cookie, a session/account-layer verdict. Community evidence closed the loop the same day: in the ban wave, accounts that kept the same IP were banned anyway (the judging dimensions are the account — registration method, verification method, provenance); the key counter-example in the anti-ban guide, switched to a US-West IP and errors began; and the analysis page noting Meta may flag the server’s shared IP. Four grounds compress into one sentence: a clean IP is the weakest of the necessary conditions; the account signal is the primary criterion. Changing IP cannot cure a flagged account, and repeated IP churn accelerates the flagging.

III. A Real Pit in the Code and Three Real Roads

The dissection also exhumed a counter-intuitive implementation pit: on a 403 the code walks the except MuseGenerationError branch and marks the account True — the 403-ed account stays in the healthy pool, so every request first burns a full failed attempt on it before switching to a backup (the author deliberately distinguishes 401-certain from 403-uncertain; for the 403 case it is pure loss). The triage is also repaired: one credential-less curl from the deployment server — a 401 means the IP layer is open and the 403 is account-level; only a 403 is worth discussing exits about. The legitimate roads are three — wait for regional launch, appeal through the official support form, use a normal network in a supported region. And the robots.txt of muse.ai says it plainly: automated collection is prohibited — the core functions of this project (a headless browser, a multi-account pool, disposable mailboxes, per-account exit rotation) sit in the center of that prohibition’s target.

IV. The Honest Boundaries of an Audit

The value of this audit is that it refused two directions: it did not call the thing usable because it has 923 stars and green tests (compliance: unusable), and it did not call the code garbage because the project is grey (the SSRF passage is worth everyone’s reading). The trustworthiness of code, the safety of operations, and the legality of use are three bills that must be settled separately — mixed together, one is either anaesthetized by the star count or blinded by the moral sense.