Why VC Funded Security Firms Miss a Critical Vulnerability

CVE-2025-32433, an Unauthenticated Remote Code Execution in Erlang/OTP SSH recently had every organization using Elixir asking the same question: Can a bad guy hack our internet facing web applications and cause a data breach? If you are responsible for the security of Elixir projects (which use the Erlang VM), and you are currently a customer of the legacy application security firms, you were likely disappointed with their inability to detect CVE-2025-32433. Why is it that firms specialized in application security will claim Elixir support, yet fail to deliver when the chips are down? The answer can be found by examining the incentive structure between investors and security vendors.

James Berthoty, a cybersecurity industry expert, noted the lack of support in a recent post.

CVE-2025-32433 is a vulnerability in the Erlang/OTP SSH server. Basically if your application is using Erlang’s SSH server somehow, and it is exposed to the public internet, you are vulnerable. What about this vulnerability is so hard to detect from the perspective of most AppSec vendors?

1. Their major customers do not use Elixir yet, so limited demand.
2. You cannot determine if a project is vulnerable by looking at the source code or dependency lockfile.
3. Most AppSec vendors rely on source code + lockfile only, because shipping runtime support is expensive.

What is required to determine if a project is vulnerable?

1. The security platform has to support Elixir, most do not.
2. At runtime, you have to check if the Erlang SSH library is loaded. If it is not, the project is safe. If it is loaded, it may be vulnerable.
3. If the Erlang SSH library is loaded, port scan the server to determine if the SSH daemon is exposed.

Why would a billion dollar VC backed security firm miss this? A simple reason: the company does not think it is profitable to spend the time supporting Elixir. Nobody working at that firm wants to be in charge of improving Elixir support. The customers they are after don’t care about Elixir, leadership wants large enterprise deals, and the last thing investors want to hear is “we are spending money on this smaller market rather than chasing a big one”. Maybe investors that understand The Innovator’s Dilemma (companies that focus on emerging markets dominate in the long run) would support this initiative, realistically they will vote no.

CVE-2025-32433 illustrates the main point: if you have to defend a company on X tech stack from hackers, you are going to buy the application security product with the best support for X. Does your company rely on a WordPress instance for an e-commerce site doing millions in revenue? You want the best WordPress security vendor. Is your entire SaaS startup dependent on an Elixir/Phoenix backend that handles all customer data? You go with a vendor that actually wants business from companies using Elixir.

The VC backed security firms are acting rationally: they have to chase large deals, they have to go after the largest market possible, they must have thin broad support for many stacks. Perhaps this is only rational on the surface level: when I worked as a security engineer I was often disappointed by how bad AppSec vendors were and would never invest a dollar of my own money in the tools I had to use. The motivation for buying the product seemed to be ticking a checkbox, deep support of the tech stack I had to defend was rare. This experience led me to starting Paraxial.io with the goal of creating a product that would be maximally useful in helping customers prevent a breach, which led to a feature set able to detect CVE-2025-32433.

There are some firms in cloud security / endpoint detection and response (EDR) where I think the VC model has worked well, those companies seem to both grow at a rate investors are happy with and stop breaches. From where I’m standing in application security, it seems that model may not fit. When I talk to Paraxial.io customers, they tend to be thrilled to have finally found a security vendor that actually knows what Elixir is and understands their security problems. It’s incredibly fulfilling to have built Paraxial.io to directly address the frustrations Elixir teams face with generic security tools, and the positive feedback from customers is the best possible affirmation.

---

Paraxial.io stops data breaches by helping developers ship secure applications. Get a demo or start for free.