A mistakenly published password exposed Mercedes-Benz source code
A leaked authentication token in a public GitHub repo reportedly granted access to extensive Mercedes‑Benz source code and internal secrets, raising alarms about basic security hygiene at a major automaker. Commenters debate the ethics and risks of reporting such vulnerabilities directly versus via journalists, especially under restrictive German anti‑hacking laws. The incident also fuels broader concerns about how safety‑critical automotive software is developed, whether it should be open source or more tightly regulated, and why large manufacturers still struggle to manage credentials and secure development practices.
Responsible Disclosure & Legal Risk
- Debate over why the researcher went via TechCrunch instead of Mercedes’ published security contact.
- Some see involving media as clout‑seeking and unnecessarily increasing risk to Mercedes.
- Others argue that even with bug bounty/vuln disclosure programs, companies can still react with legal threats, especially in jurisdictions like Germany where reporting vulnerabilities has led to fines and criminal exposure.
- Journalists are viewed both as potential protection for sources and as a liability, since involving the press has itself been cited as “damage” in German cases.
Open-Source / Transparency for Automotive Software
- Strong contingent argues that automotive (and other safety‑critical) software should be open-source or at least source-available, for public or professional audit and to avoid “security through obscurity.”
- Others counter that open source alone doesn’t guarantee review; serious auditing requires incentives, skills, and often professional firms.
- Concern that fully allowing modifications to car control software could create safety and liability nightmares; comparison to existing physical “unsafe mods” shows we already tolerate risk and regulate via inspections.
- Right‑to‑repair and owner control over vehicles are recurring themes; some propose starting with optional “tinkerable” models rather than universal mandates.
Secrets Management & Mercedes’ Software Culture
- Many are alarmed that repositories contained passwords, API keys, SSO tokens, and design documents, calling this below even junior‑developer hygiene.
- Explanations offered: legacy mechanical‑engineering culture, lack of modern software/security practices, overreliance on private repos and endpoint security.
- Commenters note this is common across industries; plaintext secrets show up in most consulting engagements.
- Multiple mentions of secret managers and GitHub secret scanning, and speculation that such controls either weren’t adopted or weren’t enforced.
- Some blame a lack of accountability and security culture more than individual developers.
Spare Parts, Signing Keys, and Market Control
- Speculation about whether any cryptographic keys used to authenticate genuine parts leaked, which could weaken automakers’ control over the aftermarket.
- Discussion of high OEM markups on generic components and nostalgia for older Mercedes models with better parts support and engineering.
User Experiences with Car Software and Safety
- Frustration with modern Mercedes UX and software reliability, described as “unreliable and sometimes dangerous.”
- Anecdotes of both Mercedes and Tesla driver-assistance systems behaving unpredictably or dangerously, suggesting industry‑wide challenges.
General Security Observations
- Several note that exposure of keys, credentials, and internal documents is much more serious than leaking source code alone.
- Emphasis that passwords and tokens will leak sooner or later, so architectures must assume compromise and avoid single‑string “gates” to critical assets.