Skip to content

Whistleblowersoftware.com: confidentiality and anonymity leakage to third parties

Chimera readability score 83 out of 100, Specialist reading level.

Full Disclosure mailing list archives
Whistleblowersoftware.com: confidentiality and anonymity leakage to third parties
From: Red Nanaki via Fulldisclosure
Date: Sun, 21 Jun 2026 11:07:14 +0000
Whistleblowersoftware.com: confidentiality and anonymity leakage to third parties ## Summary The anonymous reporting flow on `whistleblowersoftware.com` encrypts report text end-to-end in the browser but does not extend the same guarantee to attachments and exposes the reporter's network identity and timing to a US-based third party. Together these weaken the confidentiality and anonymity properties the platform is expected to provide. ## Components - `api.whistleblowersoftware.com`: public reporting and mailbox endpoints - `ws-api-production-occurrence-data.s3.eu-central-1.amazonaws.com`: attachment storage - Front-end SPA on `whistleblowersoftware.com` ## Findings ### 1. Attachments are processed in plaintext by third parties (High) Report text (title, description, and message responses) is encrypted in the browser before transmission using a hybrid scheme (RSA public key plus AES, with a PBKDF2-derived passphrase key at 600,000 iterations). Attachments are not handled the same way. To strip file metadata, the client uploads the **original, unencrypted** file to a third-party storage bucket (Amazon S3, `eu-central-1`), the file is processed off the user's device, and the client then retrieves the cleaned file in **cleartext** before encrypting and re-uploading it. The plaintext attachment is therefore handled by parties other than the recipient organisation: the platform operator, anyone with access to the storage bucket, and Amazon as the cloud provider can read the full contents of every attachment, and a plaintext copy persists in the temporary storage prefix until it is removed. No evidence of a data protection agreement (DPA) between the operator and Amazon was found, so there is no documented contractual basis constraining how the cloud provider may process or retain the plaintext attachments it receives. Endpoints involved: ```text POST /api/companies/file-entries/signed-s3-url/public # request upload URL POST / # upload original file POST /api/companies/file-entries/remove-metadata/public # server strips metadata GET /tmp/ # cleaned file, in cleartext ``` On a whistleblowing platform, attachments are frequently the most sensitive and most deanonymizing part of a disclosure (documents, photos, embedded EXIF/author/GPS metadata). Stripping that metadata off the user's device means the very data a reporter needs hidden is exposed to third parties before it is removed. **Impact:** loss of confidentiality for all uploaded evidence; exposure of deanonymizing file metadata to the operator and the third-party cloud provider; residual plaintext copies in temporary storage; no documented data protection agreement governing the cloud provider's handling of that plaintext. **Recommendation:** perform metadata removal client-side, in the browser, before encryption, so the server never receives plaintext. If server-side processing cannot be avoided, stop presenting attachments as end-to-end encrypted, guarantee immediate verifiable deletion of temporary plaintext objects (lifecycle in minutes), and treat the metadata-stripping service as an in-scope, trusted component that sees plaintext. ### 2. Third-party telemetry on the anonymous reporter flow (Medium) The reporter pages load a third-party error/telemetry SDK that transmits session data to an externally hosted, US-operated endpoint during the submission flow. Each session sends the reporter's source IP address, user agent, application release, and millisecond-precision session start/stop timestamps with correlatable session identifiers. No report content was transmitted in this channel, but it discloses the reporter's network identity and submission timing to a party outside the recipient organisation, raises cross-border personal-data-transfer concerns for an EU-targeted service, and is a latent content-leak vector should error capture or breadcrumbs ever be enabled with default settings. **Recommendation:** remove third-party telemetry from the reporter flow, or self-host it within first-party, EU-resident infrastructure; disable PII, session tracking, and breadcrumb capture on these pages; review all cross-origin connection targets permitted on the reporter flow against the anonymity threat model. ## Positive observations - Report text, message responses, and file names are encrypted client-side (RSA + AES; PBKDF2 at 600,000 iterations with a per-report salt). - Strong transport and browser hardening: HSTS with preload, a strict Content Security Policy (`default-src 'none'` on the API, `frame-ancestors 'none'`, `object-src 'none'`, mixed content blocked), `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff`, a restrictive `Referrer-Policy` and `Permissions-Policy`. - CORS restricted to the exact application origin rather than a wildcard. - Attachment storage uses short-lived temporary credentials, a private ACL, and upload policies that pin bucket, key, content type, and a content-length range, with short upload and download expiry windows. - Rate limiting is applied to report submission. - The reporting flow uses no cookies, authorization headers, or other identifying request metadata. ## Severity ranking 1. Attachments processed in plaintext by third parties: High 2. Third-party telemetry on the anonymous reporter flow: Medium _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
Current thread:
- Whistleblowersoftware.com: confidentiality and anonymity leakage to third parties Red Nanaki via Fulldisclosure (Jul 02)

Sentinel — Human

Confidence

This text presents a highly detailed technical disclosure, demonstrating the specific implementation vulnerabilities in a reporting platform concerning data handling and anonymity leakage.

Signals Detected
low severity: Sentence length and flow are technical yet varied; there is idiosyncratic emphasis on specific findings (e.g., the metadata stripping consequence), suggesting a human focus rather than uniform AI rhythm.
low severity: The text maintains high logical coherence, moving smoothly from technical implementation details (encryption scheme) to specific operational flaws (S3 handling), demonstrating a deep, focused understanding of the subject matter.
low severity: The structure is highly organized (Components -> Findings 1 & 2 -> Positive Observations -> Severity Ranking). While formulaic, this mimics high-quality forensic reporting rather than generic LLM output.
low severity: All claims are concrete and refer to specific technical components (S3 bucket names, API endpoints) and operational procedures. There is no evidence of common LLM confabulation or poorly attributed statistics.
Human Indicators
The detailed forensic breakdown linking specific code flows (POST/GET requests) to abstract legal concepts (DPA, confidentiality) suggests a human intent focused on actionable security flaws.
The pragmatic nature of the 'Recommendation' sections—offering concrete steps for system architects and developers—lacks the often generalized tone of pure synthetic summarization.