Security Hall of Fame

Anupam Giri

• Hoch27. Sept. 2026, 10:50:48 UTCdjangoeurope Message Queue

  Mandantenübergreifendes Anhängen von RabbitMQ-Zugangsdaten

  CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.5, Hoch

  CWE-639 · CWE-862 — CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR). CWE-862 (Missing Authorization) ist die fehlende Besitzprüfung am Vhost.

  POST /rabbitmquser/ prüfte nicht, ob der Aufrufer den im Request-Body genannten Vhost besitzt. Ein authentifiziertes Konto konnte deshalb selbst gewählte Zugangsdaten an jeden Vhost anhängen, dessen UUID es kannte.

  Bestätigt und als Hoch akzeptiert. Den AMQPS-Schritt nehmen wir auf das Wort des Meldenden; wir mussten ihn nicht nachstellen. Intern haben wir Mittel erwogen, weil ein Angreifer eine Vhost-UUID braucht und der Bericht keinen Weg zeigt, eine zu beschaffen. Dieser zweite Punkt ist berechtigt, und wir haben ihn selbst geprüft statt ihn anzunehmen: die ID der RabbitMQ-Instanz ist eine UUID4-ID. Eine UUID4 hat 122 Bit Zufallsraum, deshalb ist Raten oder Enumerieren praktisch unmöglich, und ein fremdes RabbitMQ-Konto auf diesem Weg zu übernehmen ist sehr schwer. Der eine allgemein lesbare RabbitMQ-Endpunkt legt Cluster ohne ihre Vhosts offen, sodass wir auch keinen Disclosure-Pfad gefunden haben.

• In Prüfung27. Sept. 2026, 19:05:42 UTCwcenter / djangoeurope-Zahlungen

  Banküberweisungs-Referenz aus der URL übernommen

  CWE-639 · CWE-472 — CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR). CWE-472 (External Control of Assumed-Immutable Web Parameter) deckt ab, dass CID und Referenz aus der URL übernommen wurden.

  Gemeldet wurde, dass die Banküberweisungsseite CID und Zahlungsreferenz aus der URL-Query übernahm, ohne zu prüfen, ob sie zum eingeloggten Konto gehören. Ein präparierter Link könnte einen Kunden anweisen, die Referenz einer anderen Person auf eine echte Überweisung zu setzen. Karten- und PayPal-Aufladung auf derselben Seite waren nicht betroffen.

  Noch nicht behoben. In Prüfung.

Pramod Kumar Ravela

IndienLinkedInBugcrowd

• Mittel11. Sept. 2026, 11:52:40 UTCwcenter / djangoeurope

  Passwort-Reset-Token nach Gebrauch nicht ungültig

  CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N = 6.8, Mittel — oberes Ende der Bandbreite, knapp unter Hoch.

  CWE-640 · CWE-613 — CWE-640 (Weak Password Recovery Mechanism for Forgotten Password). CWE-613 (Insufficient Session Expiration) deckt ab, dass der Token nach erfolgreicher Änderung gültig blieb.

  Gemeldet wurde, dass ein Passwort-Reset-Token nach einer erfolgreichen Passwortänderung nicht ungültig wurde und der Reset-Link für den Rest seiner zweistündigen Lebensdauer erneut verwendet werden konnte.

  Reset-Tokens sind nun strikt einmalig verwendbar. Der Bericht hat uns zudem zu einer breiteren Prüfung des Passwort-Reset-Ablaufs veranlasst: Durchsetzung der Passwortrichtlinie auf diesem Pfad, Abmeldung bestehender Browser-Sitzungen beim Reset, Ungültigmachen älterer Reset-Links und Rate-Limiting am Endpunkt. Vielen Dank für eine klar geschriebene und reproduzierbare Meldung.

Gaurang Maheta

• Mittel15. Sept. 2026, 07:34:19 UTCdjangoeurope-Registrierung, Passwort-Reset, Testkonten und Kontaktformular

  Anti-Bot-Prüfung bei der Registrierung nur clientseitig

  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N = 5.3, Mittel

  CWE-602 · CWE-804 — CWE-602 (Client-Side Enforcement of Server-Side Security). CWE-804 (Guessable CAPTCHA) ist die treffendere Zuordnung und wird zusätzlich genannt.

  Die Anti-Spam-Prüfung der Registrierung liess sich vollständig im Client berechnen — kein Server-Secret, kein Nonce, kein Ablauf — und hat automatisierte Kontoerstellung nicht verhindert.

  Vollständig akzeptiert. Registrierung, Passwort-Reset, Testkonto-Erstellung und das Kontaktformular verlangen nun eine serverseitig ausgestellte Proof-of-Work-Challenge, gebunden an die Anfrage: von unserer eigenen Infrastruktur signiert und scoped, mit Ablauf, einmalig verwendbar und nicht offline fälschbar. Wir nutzen selbst gehostetes Proof-of-Work statt eines Drittanbieter-CAPTCHA, also keinen zusätzlichen Auftragsverarbeiter, kein Cookie und kein Fingerprinting. Proof-of-Work ist keine harte Barriere; Rate-Limits bleiben die eigentliche Obergrenze gegen Missbrauch. Die alte clientseitige Prüfung wird in einem gestuften Schritt entfernt, sobald das neue Verfahren stabil ist. Vielen Dank für eine saubere, korrekte Meldung, die ein lange offenes Thema behoben hat.

• Mittel15. Sept. 2026, 07:34:05 UTCdjangoeurope-Registrierung & Passwort-Reset

  Fehlendes Rate-Limiting bei Registrierung und Passwort-Reset

  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N = 6.4

  CWE-770 · CWE-799 — CWE-770 (Allocation of Resources Without Limits or Throttling). CWE-799 (Improper Control of Interaction Frequency) ist die frequenzbezogene Sicht derselben Lücke.

  Der Login ist begrenzt, Registrierung und Passwort-Reset waren es nicht. Die Registrierung konnte Konten anlegen und Willkommensmails ohne Limit senden; Passwort-Reset sandte bei jeder Anfrage eine Mail, sodass ein Postfach geflutet werden konnte.

  Als Mittel akzeptiert. Der gemeldete Vektor bleibt unverändert. Der Schaden liegt bei Mail-Volumen und Absender-Reputation, was CVSS schlecht abbildet, weil die Auswirkung das Postfach Dritter trifft und nicht unser eigenes System; das ändert die Bewertung nicht. Der Fix ist ausgerollt. Die Registrierung kann eine einzelne Adresse nicht bombardieren — eine Willkommensmail pro Adresse — konnte aber an viele verschiedene Adressen senden; Passwort-Reset konnte ein Postfach fluten. Beide Endpunkte haben nun Rate-Limits, inklusive einer Begrenzung pro Zieladresse beim Reset, sodass IP-Rotation gegen ein Postfach nicht mehr greift. Reset-Tokens bleiben unabhängig davon strikt einmalig. Vielen Dank für eine klare, reproduzierbare Meldung; sie hat uns bewogen, die ganze unauthentifizierte Fläche um Registrierung und Passwort-Reset zu prüfen.

• Mittel15. Sept. 2026, 07:33:50 UTCdjangoeurope-Registrierung

  Unauthentifizierte Kunden-E-Mail-Enumeration

  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N = 5.3

  CWE-204 — CWE-204 (Observable Response Discrepancy).

  Der Registrierungs-Endpunkt lieferte unterschiedliche Fehlermeldungen für bereits registrierte und unbekannte E-Mail-Adressen. So konnte ohne Login bestätigt werden, welche Adressen Kunden sind.

  Das Orakel ist geschlossen. Anonyme Registrierung antwortet nun gleich, ob die Adresse neu oder bereits Kunde ist; ein Duplikat legt nichts an. Der Adressinhaber kann einen Hinweis erhalten, dass bereits ein Konto existiert, mit Link zur Passwort-Reset-Seite ohne Reset-Token. Vielen Dank für die Meldung zusammen mit dem Rate-Limiting-Fund.