Ende September 2025 schoss die App Neon im US‑Apple‑App‑Store auf Platz zwei, getragen von einem ungewöhnlichen Geschäftsmodell: Nutzer erhielten 0,30 US‑Dollar pro Minute für Gespräche zwischen Neon‑Abonnenten und bis zu 30 US‑Dollar pro Tag für weitere Anrufe, während die so gewonnenen Audioaufnahmen und Transkripte an KI‑Unternehmen für Trainings- und Testzwecke verkauft wurden. Kurz nach dem rasanten Wachstum wurde jedoch eine schwerwiegende Sicherheitslücke publik, die fremden Zugriff auf Telefonnummern, Mitschnitte und Transkripte erlaubte. Der Dienst wurde daraufhin vorübergehend deaktiviert.
Monetarisierung, Growth-Spurt und Reichweite der App
Laut Anbieterförderte eine Referral‑Struktur das Wachstum. Nach Zahlen von Appfigures wurde Neon am 24. September 2025 mehr als 75.000‑mal heruntergeladen und stieg in der Kategorie „Soziale Netzwerke“ in die Top‑5. Das Geschäftsmodell adressierte zugleich eine heikle Grauzone: die systematische Monetarisierung von Sprachdaten, die in KI‑Pipelines einfließen.
Technische Ursache: Broken Access Control (IDOR) im Backend
Recherchen von TechCrunch zeigen, dass die Server‑API keine wirksame objektbezogene Autorisierung erzwang. Mit einem frisch registrierten Account und Traffic‑Analyse via Burp Suite ließen sich Endpunkte ansprechen, die fremde Ressourcen zurückgaben – ein klassischer Fall von Insecure Direct Object Reference (IDOR). Damit konnte ein angemeldeter, aber unprivilegierter Nutzer auf Datensätze anderer Accounts zugreifen.
Welche Daten exponiert waren und warum das kritisch ist
Über API‑Antworten waren direkte URLs zu Audiomitschnitten und Transkripten abrufbar. Diese konnten, sofern bekannt, ohne zusätzliche Prüfung geöffnet werden. Zudem ließen sich Anruflisten beliebiger Nutzer samt Metadaten wie Telefonnummern beider Parteien, Zeitstempel, Dauer und Auszahlungsbeträge einsehen. In mehreren Fällen betrafen Aufzeichnungen offenbar primär Neon‑Nutzer selbst, wodurch Risiken für unwissende Dritte nochmals stiegen.
Einordnung nach Best Practices und OWASP
Der Befund korrespondiert mit der OWASP‑Kategorie Broken Access Control – seit OWASP Top 10 (2021/2023) Rang 1 der häufigsten Web‑Risiken. IDOR‑Fehler entstehen, wenn Ressourcen‑IDs ohne serverseitige Eigentums‑ und Berechtigungsprüfung verarbeitet werden. Folgen sind Identitäts- und Inhaltslecks mit Potenzial für Phishing, Erpressung, Doxxing und Social Engineering. Referenz: OWASP Top 10 2021/2023.
Reaktion des Anbieters und ungeklärte Aspekte
Nach Hinweis der Presse deaktivierte Neon die Server und kündigte „zusätzliche Sicherheitsebenen“ an – ohne Details zur Schwachstelle. Offen bleibt, ob vor dem Launch Security‑Reviews, Penetrationstests oder unabhängige Audits stattfanden und ob Logdaten eine belastbare Forensik über potenziellen Fremdzugriff ermöglichen. Aussagen von Apple und Google zur Richtlinienkonformität liegen laut Berichten nicht vor.
Risikominderung: Was Plattformen jetzt umsetzen sollten
Zentral sind objektfeingranulare Autorisierung (z. B. ACL/ABAC) und strikter Owner‑Check bei jedem Request. Direkt zugängliche Medienlinks sind zu vermeiden; stattdessen kurzlebige, signierte URLs mit Token‑Bindung und erneuter Authentifizierung verwenden. Daten sollten segmentiert und Umgebungen isoliert werden. Least Privilege und Defense‑in‑Depth sind Pflicht.
Secure SDLC und operative Kontrollen
Sicherheit gehört in den SDLC: Threat Modeling, Tests auf Fremdobjektzugriffe, regelmäßige SAST/DAST, API‑Reviews, strukturierte Pentests und Bug‑Bounty‑Programme. Ergänzend sind zentralisiertes Logging, Analyse anomal hoher Download‑Raten und Alerting unerlässlich, um Datenabflüsse früh zu erkennen. Verschlüsselung in Transit und at Rest ist wichtig, ersetzt aber keine korrekte Autorisierung. Für Sprachdaten gilt: Privacy‑by‑Design, klare Einwilligungsflüsse und transparente Löschkonzepte.
Der Vorfall verdeutlicht, wie riskant fehlende Zugriffskontrollen in Apps sind, die personenbezogene Sprachinhalte verarbeiten. Plattformbetreiber sollten Autorisierung als „Blocker‑Kriterium“ im Releaseprozess etablieren und regelmäßig gegen OWASP‑Standards prüfen. Nutzer wiederum sollten die Datenverarbeitungsbedingungen genau lesen, App‑Berechtigungen restriktiv setzen und zweifelhafte Zugriffe zeitnah entziehen. Wer Anwendungen mit sensiblen Kommunikationsdaten betreibt, sollte umgehend ein Access‑Control‑Audit durchführen und signierte, kurzlebige Medien-URLs einführen.
