When Code Does Not Evolve: The Dangers of Doing it the Way It’s Always Been Done.

Business literature and motivational quotes often push for transformative thinking by encouraging people to "think outside the box." Forbes even ran a headline stating: The Most Dangerous Phrase In Business: We've Always Done It This Way. Yet even in an industry that insists on rapid change (and noticing how every new startup will somehow “disrupt” the status quo) we see real risks associated with not evolving software development lifecycles to address an ever-changing risk landscape. Enter the Object Lesson: the Telemessage data breach.

There’s more to unpack in this episode than originally anticipated. If you’re not familiar with Telemessage, it is a “clone” of the popular encrypted messaging service Signal except that it was designed to archive conversations. It was recently made infamous because of its unauthorized use by high level government officials, which led to security researchers testing publicly available access points and finding significant security failures – covered best in this Wired article.  Let’s look into the issues that were uncovered from the point of view of an early-stage tech startup.

The Vulnerabilities

As is often the case, hardcoded secrets were found within GitHub’s published code. The operational model compounded this mistake by including glaring vulnerabilities that allowed those secrets to be discovered and exploited without requiring access rights to GitHub. If a penetration test was ever performed on this service (which is unlikely), it was so insufficient that it could hardly be considered competent.

Hardcoded secrets were not the only problem, though.  Further compromising access was the process by which passwords were hashed. Telemessage used MD5, an algorithm widely deemed insecure since 2008. The security industry has moved well beyond MD5, and even beyond its successor (SHA-1) to SHA-2. Telemessage clearly neglected to update its codebase or remediate vulnerabilities as they were discovered and published, causing it to fall far behind modern security standards.

Still, while legacy decisions like this are suboptimal, they’re not necessarily fatal by themselves. But that brings us to even more password-related vulnerabilities in the hashing decisions.  Hashing protects passwords from discovery by converting them into irreversible data (it’s ‘one-way’ encryption). However, when hashing occurs solely on the client side  without further hashing on the server (as was implemented by Telemessage), the hash effectively becomes the password. An attacker simply has to present the hash as a password to access the system. Worse, if the server itself is compromised and the password hashes discovered, all of the discovered hashes could be used as login credentials. This decision reflects inadequate to nonexistent threat modeling, possibly even a complete lack of structured risk management when it came to application security.

That brings us, alas, to the state of the servers, where evidence continues to compound regarding the culture of security (or lack thereof) at Telemessage. A vulnerable, publicly accessible URL was discovered by a common security tools (feroxbuster). The vulnerable and accessible URL allowed the researchers (and would have allowed any attacker) to dump server memory into a file containing all data that was in memory at the time, including secrets and sensitive data. While such URLs are often used in restricted development environments for testing applications pre-production, their continued use after deploying to a production environment is a large risk. These test configurations should never be deployed to production, especially when handling actual customer data, and standard security practices would test for this before releasing code to a production environment so that errors like this could be identified and fixed before customer data was put at risk.

The Coding

And, finally…the underlying coding. Telemessage relied on Java Server Pages (JSP), an outdated technology for creating web apps in Java. While useful in 2000 (the year after Telemessage’s founding in 1999), JSP’s advantages have long since faded. Using JSP in 2025 is akin to dusting off Windows 98 and putting it online, or – in this case – continued use of Windows 98 well past its support date while the rest of the industry moved on.

Earlier versions of JSP (pre-2017) were known for insecure default configurations, exposing unencrypted data without authentication. In 2017, it was frustratingly common practice for software to be released with insecure configurations. Several high-profile incidents highlighted the risks of insecure configurations, prompting the industry to adopt more secure practices, and as a result, most developers ensured that their software is 'secure by default' upon release. JSP updates in 2017 addressed this, moving to a ‘secure by default’ configuration, but some companies persisted in using insecure configurations, often for no other reason than testing convenience. Telemessage failed to set their configurations to secure states when launching in production. Why? We can only assume it was an oversight that was not mitigated through enforced security controls. Without good processes, enforced controls, and proper oversight, compliance with even basic security standards becomes a challenge.

Insecurity by Design

Finally, Telemessage undermined the end-to-end (E2E) encryption present in the Signal app to support their business model, which differentiated itself from Singal with the ability to archive messages. The archiving of messages does not necessarily require non-encrypted data but does create new security risks.  Their first challenge was that true E2E encryption ensures that no intermediary system can access message content. This works only if the archived messages are stored only in an encrypted format for which only the sender and receiver have decryption capability, which may not meet the archiving requirements of government customers.

Unfortunately, the Telemessage service not only had access to unencrypted messages, but it stored those messages in its servers in an unencrypted state, fully negating the benefits of any encryption, much less end-to-end. This would have been a design-level decision to have both access to and storage of unencrypted customer messages. Perhaps this was a decision based on legal requirements for archiving of government content, although such decision would not explain why the service was marketed as “secure”.

How We Learn From This

The point here is not to bask in the schadenfreude of yet-another-data-breach, but to see what we can learn from it. Startups often prioritize rapid scaling and Minimum Viable Products (MVPs), sacrificing security controls to reduce costs and maximize sales. However, designing security into code from the outset is far less costly than retrofitting it post-launch. But bolt-on security rarely works - it’s akin to strapping wings onto a fish and expecting it to fly. The resources spent on security during development are minimal compared to reworking entire products after a breach. Not to mention the brand damage, loss of customer trust, and potential impact to exit strategy.

Consider that the damage done to Telemessage is still not calculable. Telemessage services were suspended on May 5, 2025. As of this writing (May 21, 2025), it appears that those services are still suspended, and their website, while up, is non-functional. The app is no longer on the Apple App Store.  This means it’s likely they’re not making any new sales right now. There’s no word yet on how many existing customers are leaving, and we probably never will know the full extent of the financial impact. Telemessage is now owned by Smarsh, which in turn is owned by private equity firm K1. While this is interesting because it indicates that the technology would have even have gone through some level of diligence under an acquisition arrangement (more info at Forstai Cyber Kinetics on that) but also means that the financial impact of this event will remain private.

The V4 Final Difference

Our company, V4 Final, was founded by individuals who highly value the security of business-critical data and our customers. We understand that a significant reason for mistrust in software – particularly new AI software – is due to its perceived hastiness in development and complexity in use. Our goal is to redefine the legal team as a valuable business asset, while also challenging the notion that early-stage technology companies must compromise the security of customer data simply to meet inflated valuations and growth targets. We firmly believe that the best path to growth is through providing exceptional solutions for our customers, with security being an essential requirement.

Telemessage’s case underscores the importance of thoughtful security governance, robust threat modeling, and prioritizing long-term viability over short-term expediency. Without these, startups risk losing much more than just money—they risk losing credibility entirely.