Skip to content
DnsLister Forum

Where domain hunters compare notes

Abandoned chrome extensions in your B2B stack: auditing Piwaa after backend deletion and delisting

Piwaa is a LinkedIn messaging inbox overlay designed for snippets, scheduled messages, and follow-up reminders—is officially dead. The backend is gone, the Chrome Web Store listing has been removed, and Google left every existing copy sitting inside roughly 1,000 browsers untouched.

I pulled the final shipped build (v1.0.30, untouched since September 2021) and audited its source. When running a lean stack, vendor abandonment is the dependency failure mode we rarely build a threat model for, especially when the vendor simply evaporates while high-privilege code remains installed on your machine.

The Takedown & Infrastructure Status Two separate trackers recorded the store removal independently: Extpose flagged the delisting on 2026-08-27 citing a "Minor Policy Violation," while chrome-stats recorded the takedown on 2026-08-31. When I ran network and DNS checks on 2026-09-07, piwaa-api.herokuapp.com returned Heroku's default "No such app" error, and neither the marketing website nor the vendor web app resolved at all. The underlying feature set had essentially been folded into Waalaxy as "Inbox Waalaxy," leaving the standalone tool abandoned.

The Clean Part: Session Handling Credit where it is due: the original session architecture was surprisingly clean. Piwaa never read li_at by value and never exfiltrated it to a remote database. Its cookie listeners and authentication checks reduced session cookies to a simple boolean (present vs. absent). Native Voyager API calls used credentials: "include", allowing the local browser to attach the session natively without exposing the raw cookie to third-party endpoints. The only cookie value extracted was JSESSIONID, which was routed strictly to LinkedIn as a CSRF token header. From an identity theft standpoint, this means uninstalling fully resolves the issue—there is no lingering vendor-side token pool to revoke or passwords to reset.

The Security Liabilities Still Running Locally Despite clean cookie hygiene, the code carries several architectural risks that make leaving it installed dangerous:

  1. Suppression of LinkedIn's CSP Reports: The background worker cancelled LinkedIn's CSP-violation reports outright (background.js:82205-82226). Attempting to block security telemetry with a static list of four URL patterns created in 2021 creates an immediate anomaly. The moment LinkedIn introduces a single new reporting endpoint, the mismatch between suppressed and unsuppressed reports reveals the tampering. This directly contradicts marketing copy on third-party mirrors claiming the tool "does not generate suspicious behavior with LinkedIn."
  2. Server-Directed Actions Without Local Pacing: The vendor web app and an internal socket channel were built to dispatch profile and conversation actions for the extension to execute automatically (background.js:51560-51607). While none of the eight accepted action types ever leaked li_at, remote server-driven commands execute as user-driven activity directly through your active session, completely bypassing local pacing controls or rate caps.
  3. Abandoned High-Level Permissions: Delisting does not trigger an automatic browser uninstall; Chrome only forcibly uninstalls extensions during confirmed malicious malware takedowns, not for policy flags. That means roughly 1,000 active installations still grant this dead extension webRequestBlocking, webRequest, cookies, storage, and tabs permissions, host access to linkedin.com, a content script running on <all_urls>, 'unsafe-eval' in its CSP, and an externally_connectable bridge tied to a vendor domain that no longer resolves.

This static code analysis reflects the v1.0.30 build alongside the HTTP/DNS probes from September 2026. Looking across the 26 public reviews on record, there were zero reported bans or restrictions—the complaints were entirely about stability and bugs.

However, leaving unmaintained, privileged extensions installed when their vendor endpoints go dark is an unforced error for any bootstrapped pipeline. The immediate fix is straightforward: go to chrome://extensions and hit Remove, and definitely avoid sideloading old mirror packages.

How often do you audit your browser's installed extension permissions to prune abandoned tools from your stack?

Source: r/BootstrappedStacks · by /u/Matthew_Watkins

Leave a Reply

Your email address will not be published. Required fields are marked *