By ByteBot
Freedom Chat, a messaging app marketing itself as “super secure,” exposed approximately 2,000 users’ phone numbers and PIN codes through two critical vulnerabilities discovered by security researcher Eric Daigle on December 4, 2025. The flaws allowed unlimited phone number enumeration attacks and broadcast plaintext PINs to all members of the app’s default channel. This marks the second major security failure for founder Tanner Haas, whose previous app Converso was delisted from app stores in May 2023 for exposing users’ private messages.
How the Attacks Worked
Eric Daigle discovered two fundamental security flaws that Freedom Chat shipped without basic protections. The first vulnerability allowed phone number enumeration through the /user/numbers contact discovery endpoint. Daigle created a script that submitted batches of 40,000 phone numbers to the API with zero rate limiting or throttling. The entire enumeration of Freedom Chat’s ~2,000-user base completed in 27 hours, averaging 1.5 seconds per batch. No server failures, no timeouts, no blocking—just wide-open access to user data.
The second flaw was even more egregious. Freedom Chat’s /channel API endpoint returned complete user objects including plaintext PINs in its responses. Anyone in the default Freedom Chat channel—which users are automatically subscribed to upon signup—had their PIN broadcast to all 1,519+ other members. Using standard network traffic inspection tools, Daigle saw PIN codes structured as "pin": "<six digit code>" directly in API responses. The PINs weren’t visible in the app’s UI, but they were sitting in plaintext in every channel data request.
This enumeration technique is identical to the one University of Vienna researchers used to expose 3.5 billion WhatsApp users in November 2025, demonstrating that even major platforms struggle with rate limiting. The difference? WhatsApp eventually implemented fixes after an 8-year delay. Freedom Chat shipped without basic security hygiene from day one.
Not the First Time
This isn’t Tanner Haas’s first security rodeo—it’s his second failure. His previous app, Converso, was delisted from Apple and Google app stores in May 2023 after security researchers discovered it stored encryption keys in an open Firebase bucket and exposed users’ private messages despite end-to-end encryption claims. The Register documented how Converso implemented the Seald E2EE service so poorly that encrypted message keys could be derived from publicly available information.
One security failure can be a mistake. Two indicates systemic issues with security culture, not one-off bugs. Both Converso and Freedom Chat claimed “super secure” or E2EE protection, yet both shipped with fundamental architectural flaws that exposed user data. Haas’s quote to TechCrunch—”A recent backend update inadvertently exposed user PINs”—frames this as an accident rather than addressing the pattern of insecure implementations across two separate apps.
The pattern speaks for itself. Users evaluating messaging apps should recognize this as a red flag: apps claiming security without the track record to back it up often prove to be the least secure options available.
Missing: A Way to Report Security Flaws
Freedom Chat had no formal vulnerability disclosure program (VDP), forcing Eric Daigle to contact TechCrunch as an intermediary to report the flaws. The lack of security.txt, bug bounty program, or public security contact is itself a security warning sign. Industry standard practice includes establishing VDPs before launch—Signal, WhatsApp, and other major platforms all maintain formal bug bounty programs through HackerOne or Bugcrowd.
The absence of a VDP delayed disclosure and potentially extended user exposure. Daigle discovered the vulnerabilities in early December 2025, but had to spend time finding a contact path through media rather than reporting directly to the development team. Fixes were deployed by December 8-9, 2025, with all user PINs reset, but the multi-day disclosure delay could have been avoided with proper channels.
Security Basics That Would Have Prevented This
Three fundamental security practices would have prevented both Freedom Chat vulnerabilities: multi-layer rate limiting, minimal API responses, and formal vulnerability disclosure programs. None of these require advanced cryptography or massive security budgets—they’re basic hygiene for any app handling user data.
Rate limiting should operate on multiple layers: per IP address (100 contact queries per hour), per user account (500 queries per day), and global monitoring for anomaly detection. WhatsApp’s 8-year failure to implement effective rate limiting shows this isn’t trivial, but tools like AWS WAF, Cloudflare Rate Limiting, and language-specific libraries (express-rate-limit for Node.js, Flask-Limiter for Python) make implementation straightforward. The investment is minimal: most cloud providers include rate limiting in their standard API gateway offerings.
API security requires returning only the data clients absolutely need. Freedom Chat’s mistake—broadcasting PIN codes in channel membership responses—violates the principle of minimal data exposure. Authentication credentials should never appear in general-purpose API endpoints. PINs should only be transmitted during authentication flows, never in channel data, user profiles, or membership lists.
Formal VDPs cost nothing to establish. A security.txt file (RFC 9116) at /.well-known/security.txt provides a contact for security researchers. More comprehensive bug bounty programs through HackerOne or Bugcrowd cost $10K-$50K for initial security audits, but demonstrate serious commitment to security. For apps claiming “super secure” in their marketing, the lack of a VDP is disqualifying.
Key Takeaways
- Second failures indicate systemic issues: Tanner Haas’s pattern across Converso (2023) and Freedom Chat (2025) suggests fundamental security culture problems, not one-off mistakes.
- “Super secure” apps often aren’t: Verify security claims through third-party audits, open-source code, and established bug bounty programs before trusting marketing.
- Rate limiting and minimal APIs are basic hygiene: These aren’t advanced security measures—they’re foundational practices that prevent mass-scale data harvesting.
- No VDP is a red flag: Apps handling sensitive data should establish vulnerability disclosure channels before launch, not after breaches.
- Choose proven track records over promises: Signal’s open-source code and public security audits provide verifiable trust. Claims without evidence don’t.
