Security & Vulnerability Disclosure

What FrogTalk is

Pre-alpha notice: FrogTalk is experimental software. Features change quickly, backups and uptime are not guaranteed, and not every code path has been reviewed for security. Do not rely on it for high-stakes or life-critical communications until we leave pre-alpha. Production deploys use the master branch; active development happens on dev.

FrogTalk is a censorship-free chat platform where messages can stay private. No company sits in the middle; anyone can run a node; DMs are end-to-end encrypted so the server cannot read them even if it is seized.

The codebase is MIT-licensed and fully public on GitHub. We publish the security model, encryption details, and API reference so operators and researchers can verify behaviour instead of trusting marketing copy.

The encryption primitives are standard (ECDH-P256 → SHA-256 → AES-GCM-256 for channels; Signal Protocol for DMs; DTLS fingerprint signing for calls). As with any fast-moving open-source project, we welcome audits and responsible disclosure.

Threat model: we assume the server can be compromised. DM bodies are end-to-end encrypted, keys never touch the server, and recovery keys are bcrypt-hashed at rest. Private channels use per-room AES-256-GCM with AAD-bound ciphertext (room id + key version) and automatic key rotation on ban/kick — a captured ciphertext cannot be replayed against another room or an older key, and a banned user cannot read messages sent after the rotation. Bridges to Discord/Telegram are blocked for private rooms (they would leak plaintext to a third party). If you find a way around any of that — please report it loudly.

How you can help:

🐛 File a bug or vulnerability report via the form below — anonymous is fine.
🔎 Audit the code on GitHub and open an issue with file paths and repro steps.
🛠️ Send a pull request with a focused fix — see CONTRIBUTING.md.
📣 Run a node and join the federation. More nodes = more censorship-resistance.
💬 Spread the word. Community projects only work with a community.

How nodes are hardened

End-to-end encryption protects message contents even if a server is seized. Around that, the official nodes run defence-in-depth at the operating-system layer — and every operator gets the same playbook free (NODE_SECURITY.md):

Default-deny firewall (ufw) — only SSH and the web/TURN ports a node actually serves are open.
Intrusion detection + auto-ban — CrowdSec (behavioural detection + crowd-sourced blocklists) with an nftables bouncer, alongside fail2ban. Optional nginx / PHP / Cloudflare-edge bouncers add application-layer blocking.
Automatic security patching via unattended-upgrades.
Least privilege — the app runs as an unprivileged user, never root; SSH prefers keys.
Minimal surface — official nodes are stripped to "just a FrogTalk node": no desktop packages, no unrelated proxy/VPN software.
Privacy-respecting peer display — the admin federation view can redact peers' clearnet IPs, and push notifications never carry message content or ciphertext.

Operator panic button: the node admin panel has a gated Danger Zone → Nuke this node that securely shreds the database, keys and the install itself, best-effort wipes RAM, and powers the box off — for decommission, seizure risk, or a confirmed compromise.

What counts as a vulnerability

High-impact: account takeover, E2EE bypass, message tampering, server-side RCE, SQL injection, auth bypass.
Medium-impact: stored or reflected XSS, CSRF on state-changing endpoints, privilege escalation, IDOR, sensitive info leaks.
Lower-impact: rate-limit bypass, denial-of-service through unbounded inputs, info disclosure of non-sensitive data.
Not in scope: "you can DM yourself spam from your own account", missing security headers without a working exploit, automated scanner output without a PoC, social engineering of other users.

Report a vulnerability

Use the form below. You can submit anonymously — we don't require an account — but including a contact (email, Matrix, GitHub handle, or a FrogTalk nickname) lets us ask follow-up questions and credit you when it's fixed.

For critical issues you'd rather not put in a web form, email [email protected] with as much detail as you can.

Please don't test exploits against the live production server beyond what's needed to confirm the bug. For destructive PoCs (mass-account creation, DoS), spin up a local instance — docker compose up from the repo gets you a full stack in about a minute.

Even better: send a patch

FrogTalk is MIT-licensed and lives on GitHub. If you can write the fix, we'd much rather review a PR than relitigate the bug in an issue tracker.

Contributing: FrogTalk is MIT-licensed on GitHub. Keep PRs small and focused; include a PoC for security fixes. See CONTRIBUTING.md for branch workflow and review expectations.

Repo: github.com/deadinternetfox/frogtalk
Branch from dev (or master for production hotfixes), keep PRs small and focused, write a clear commit message.
Touched JS? Run node --check static/js/<file>.js before pushing — silent parse errors break every onclick on the page.
Touched Python? Run python -m py_compile on the changed files; the FastAPI app imports the whole tree at startup.
Security fixes: include a PoC in the PR description (or link to the bug-report ID you filed here) so the reviewer can verify the patch closes the hole.
Credit: add yourself to CONTRIBUTORS.md in the same PR, or tell us where to credit you in the security advisory.

Community projects are up to all of us. Every reviewed PR, every triaged report, every responsible disclosure makes the platform safer for the next person who logs in. We notice, and we say thank you.

Hall of fame

Security researchers who've responsibly disclosed issues. Want to be on this list? See above.

@frogtalk_is_insecure

Channel CSS audit May 2026

Audited public-channel custom CSS and theme handling. Found that a channel owner could fingerprint every visitor's IP by loading a background image from their own server — effectively turning the chat theme into ad-tracking pixels — plus several CSS-sandbox bypasses that let styles reach outside the channel scope.
In their own words, the core issue was blunt: "I can add my own adtracking to the chat — I can see anyone's IP now whenever they open this chat, just from loading the page." A hostile channel theme could point background-image at an attacker-controlled URL; every member who opened the channel would hit that server and leak their IP — no message send required.

They also flagged the CSS sanitizer as incomplete:
- :root not blocked — document-level selectors could escape the #main scope.
- [data-theme] not blocked — platform theme attributes were reachable from channel CSS.
- Namespaces wide open — @namespace and related rules were not rejected.
- Pseudo-elements unfiltered — modern selectors like ::column (and similar) were not on the deny list.
- Unicode whitespace mismatch — the sanitizer's space detection did not match browser behaviour, likely allowing a #main jailbreak via thousands of Unicode space-like characters.
- JSON API whitespace bugs — message requests with newlines or special characters were mishandled by the API layer.
Outcome: CSS sanitizer tightened (:root, [data-theme], forbidden pseudos, Unicode normalisation), external background images proxied through FrogTalk, custom CSS disabled entirely for private channels, message content whitespace preserved, and channel-theme UI warnings added. Issue resolved.