What our analysis found

Three Card Poker is rated caution by Extension Auditor. Our code review reported 2 findings (1 critical, 1 high), led by remote code loading. It comes from a publisher with 28 extensions and was last updated in April 2026.

Key findings

• critical· remote code loading —Every time the player presses Deal (onDeal at:1949 awaits fetchSettings), the extension beacons to mines.cloudapi.stream and then injects the server-supplied HTML string into document.body through innerHTML, with an optional server-controlled removal timer. This hands the remote operator a persistent channel to render arbitrary markup inside the extension's own chrome-extension:// page: the extension_pages CSP (script-src 'self') stops injected <script>, but iframes, forms, links and images are unrestricted, which is sufficient for credential-harvesting overlays or redirects that inherit the trust of an extension page. An offline card game needs no server round-trip per hand, the destination is the documented shared C2 of the Socket 108-extension campaign, and the same response also sets the win rate, so the channel is clearly operator-driven rather than a static game asset.
• high· other —The bundled manifest for 2.2.1 declares no permissions and no host_permissions, but the live Chrome Web Store listing for this item declares permissions identity, alarms, notifications and storage plus host_permissions for and The identity permission combined with the host grants OAuth access-token acquisition, which a self-contained three-card-poker game has no account or sync feature to justify, and top.rodeo is a domain that appears nowhere in the code I could read. The divergence means the shipped build exercises capability that is not reviewable in this package, the classic delayed-malicious update pattern, and it compounds the externally_connectable <all_urls> surface shown here, which any web page can message once a listener is added.

3708-3741 defines fetchSettings(), which POSTs {user_id, extension_id} to on every hand (called from onDeal at:1949) and then takes the server's string, writes it into a div via innerHTML and appends the result to document.body. That is a live, per-deal remote-content channel from cloudapi.stream into a chrome-extension:// page; the extension_pages CSP (:12) blocks injected scripts but not injected iframes, forms or links, so the operator can render arbitrary markup inside a privileged-origin tab at will. The published listing also declares identity, alarms, notifications, storage and hosts for, and top.rodeo, while the bundle I read declares permissions: [] and host_permissions: [] (:30-31): identity plus is OAuth-token capability that an offline three-card-poker game has no feature to justify, and it is absent from the build in hand. Corroborating: chrome-stats flags access-to-specific-domain for cloudapi.stream and top.rodeo, and the internal IoC notes tie cloudapi[.]stream to the Socket 108-extension shared-C2 campaign; contradicting: our own risk engine scored 0.00 on a zero-permission manifest, the game code itself is a stock template, and nothing in the files I could read actually reads cookies, tokens or browsing data. I withheld a `malicious` verdict for that reason, and because 9 of the 17 JS files listed in (jquery-3.1.1., createjs-2015.11.26., howler., CLang. and the.min bundles that:13-15 actually loads) were not present in the extracted bundle, so a trojanized vendor library cannot be ruled out and most of the model's js_innerhtml / js_file_count hits come from files I never saw. Non-finding hygiene notes::17 and beacon with the extension id to cloudapi.stream, which is first-party per the publisher's own privacy-policy URL on that domain, so it is not exfiltration under the disclosure rules even though that "first-party" domain is the campaign C2; externally_connectable matches <all_urls> (:17-19) with no onMessageExternal listener anywhere, `let user_id = null` at:1 is never used, localStorage "user_id" is never written so the POSTed value is always null, play_token (:3707) is assigned and never read, and the sandbox CSP's unsafe-eval is inert because no sandbox.pages are declared. Those four dormant hooks are consistent with staging for a later update rather than with present-tense theft.