CVE-2026-120250: How Missing TLS Verification, Exposed OpenAlgo’s SMTP Credentials

Hi, I’m Tommaso Bona, Security Researcher at SatoriCI. This article walks through CVE-2026-120250, a vulnerability we found in OpenAlgo, what it meant for anyone running the platform, and how it was reported and fixed.

How we found it

At SatoriCI we run an internal pipeline called “pyspector-monitor”, that continuously scans public repositories with PySpector, our preferred SAST tool for Python, looking for real security issues, rather than simple bugs. When PySpector flags something, it doesn’t get reported blindly, as every finding first goes through an automated triage pass with an LLM, which reads the surrounding code and rules out the obvious false positives. Then, anything that survives that pass gets a manual review from the security researcher running that pipeline, before it goes anywhere, and in this case that was me, reading the actual code path to confirm the certificate check really was disabled, and understanding what an attacker could do with it. Once a finding is confirmed as a true positive, our pipeline automatically creates a pre-filled GHSA, which gets reviewed and adjusted manually, depending on the case, and then auto-filed privately to the maintainers.

That’s exactly what happened with OpenAlgo.

What is OpenAlgo

OpenAlgo is a free, open source, self-hosted algorithmic trading platform built on Python and Flask, with a React frontend. Rather than acting as a thin bridge to a single broker, it positions itself as a full trading environment, connecting to over 30 broker integrations, mostly Indian securities brokers plus crypto derivatives through Delta Exchange, and exposes a unified REST API that tools like TradingView, Amibroker, ChartInk, and Excel can send signals to. On top of that API, it offers a Python strategy host for running scripts directly in the browser, a no-code drag and drop strategy builder with webhook triggers, an AI trading agent, and a set of options and portfolio analytics tools.

Because it is meant to be self-hosted by individual traders and small teams rather than run as a managed SaaS, OpenAlgo also handles its own account lifecycle, including sending password reset links by email, which is exactly where this vulnerability lived.

The vulnerability

PySpector flagged two occurrences of the same pattern in utils/email_utils.py, both setting up an SSL context like this:

context = ssl.create_default_context()
context.check_hostname = False
context.verify_mode = ssl.CERT_NONE

That combination builds a default, secure SSL context, and then immediately strips it of the two checks that make TLS meaningful: it stops verifying that *the certificate presented by the server, matches the hostnamebeing connected to, and it stops verifyingthe certificate itself** against any trusted authority. The same pattern showed up again in utils/email_debug.py, OpenAlgo’s SMTP debug tool.

In practice this meant every SMTP connection OpenAlgo made (whether for sending a password reset email, a test email, running a connection check, or using the debug tool), accepted any certificate from anything claiming to be the mail server, over both STARTTLS on port 587, and SMTPS on port 465. TLS without certificate validation, gives you encryption against a passive eavesdropper, but it gives you nothing against an active one (since there is no longer any check that you are actually talking to the mail server, and not to someone pretending to be it).

The practical attack is a Man-in-The-Middle (MiTM). Anyone positioned on the network path, between the OpenAlgo server and its configured mail server (for example on the same local network, on a compromised router, etc…), can present a self-signed or otherwise invalid certificate, and OpenAlgo will connect to them instead of the real mail server. At that point they get the full SMTP handshake, which includes the username and password used to authenticate to the mail account, in clear plain text. Since they are sitting in the middle, they can also simply let every email through to the real server after reading it, so the attack is persistent rather than a one time credential theft.

The part that actually turns this into an account takeover primitive, is OpenAlgo’s password reset flow, which sends its reset link over this same unverified connection. A trading platform typically holds API keys and broker credentials, so a reset link intercepted by an attacker, who then requests a password reset for a target account, hands them a direct path into that account, with no need to compromise anything else on the server itself. On top of that, the SMTP debug tool made things worse on its own. It enabled smtplib’s debug output, which writes every command sent to the server into the application log, including the AUTH command. The mail password went into that log base64 encoded, which is easily reversible, not encryption, so anyone able to read the server logs, through a separate vulnerability, misconfigured log access, or something else, could recover the mail password directly without needing to be on the network path at all.

Both problems come down to the same root cause: CWE-295 (Improper Certificate Validation), just applied in two different places in the same code, with the logging issue compounding the exposure once credentials were already at risk.

Reporting and the fix

We reported this to the OpenAlgo maintainers through our pipeline, and they moved really fast, as the fix landed in only 2 hours. Commit af5d5f2 replaces the manual, broken SSL context setup across all four affected code paths, with a shared helper that builds a context from the system trust store and adds certifi’s roots on top, without touching check_hostname or verify_mode, so the default correct behavior, stays in place. The debug output that leaked the password, was removed entirely, and proper error handling was added so that a certificate verification failure now produces a clear message to the user, instead of silently connecting anyway. The fix shipped in OpenAlgo v2.0.3.1.

Getting a CVE and the CVSS correction

Once the fix was out, we requested a CVE ID through VulnCheck, who assigned CVE-2026-120250, in less than 24 hours (huge thanks to the VulnCheck team for the fast turnaround on that). During review they also adjusted my original CVSS4 score from 7.1 High, down to 6.0 Medium, since our submitted vector wrongly scored Attack Requirements as AT:N, when it should have been AT:P, given that exploitation depends on the attacker already sitting on the network path between the OpenAlgo server, and its mail server. The final vector is CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. Last, we passed the CVE ID on to the OpenAlgo maintainers, who published the advisory as GHSA-4vvw-xw2w-38g8.

Conclusion

If you run OpenAlgo, update to 2.0.3.1 or later, and enter your SMTP host by name, rather than by IP address, so certificate verification can actually match it. If you used the SMTP debug tool before upgrading, change your mail password, since it may already be sitting in your server logs.

This is also a good example of what our pipeline is built for: a pattern that’s easy to write by accident, while trying to work around a certificate problem in testing, that sinlently turns off the one thing, that TLS is supposed to guarantee.