AISLE Discovers Three of the Four OpenSSL Vulnerabilities of 2025

By Stanislav Fort, Founder & Chief Scientist, AISLE

Published October 29, 2025

Autonomous AI securing the world's most hardened cryptographic library

So far in 2025, only four security vulnerabilities received CVE identifiers in OpenSSL, the cryptographic library that secures the majority of internet traffic. AISLE's autonomous system discovered three of them.

Discovering a genuine security flaw in OpenSSL today is extraordinarily difficult. The codebase has been refined by thousands of contributors, audited by security researchers worldwide, and hardened through years of real-world deployment. Even a single accepted OpenSSL vulnerability represents a rare achievement for an experienced security researcher. The library's maturity and the community's vigilance make new discoveries exceptionally uncommon.

OpenSSL is one of the most consequential software projects ever written. It provides the cryptographic foundation for the majority of HTTPS websites, the SSL/TLS layers embedded in operating systems and cloud infrastructure, and countless applications that depend on secure communications. Few codebases have endured the level of scrutiny that OpenSSL has faced over more than two decades; any vulnerability in it reverberates through the entire digital ecosystem.

Which is why these findings matter: AISLE's autonomous system not only discovered three vulnerabilities (CVE-2025-9230, CVE-2025-9231, and CVE-2025-9232) that had gone undetected by years of expert review, but also proposed the fixes that were used to remediate them. These findings represent concrete validation of our mission: to secure the software foundation of modern civilization by building systems that can operate at superhuman scale, depth and speed.

The Discoveries

Between August 9 and August 16, 2025, AISLE's system identified three distinct security vulnerabilities in OpenSSL's codebase. All three were reported responsibly to the OpenSSL maintainers within hours of detection, assigned CVE identifiers on August 20, and publicly disclosed on September 30 after coordinated patching across seven active release branches.

To put this in perspective: in 2025, only four CVEs with the format CVE-2025-* have been publicly assigned to OpenSSL. Three of them came from AISLE's autonomous research. The library's maturity and the community's vigilance make new discoveries exceptionally uncommon.

Across these three issues, the time the vulnerabilities remained undetected ranged from about a year to more than 15 years, illustrating how a legacy code path, an architecture‑specific fast path, and a subtle parsing edge case can each evade scrutiny in different ways.

CVE-2025-9230: Out-of-Bounds Read/Write in RFC 3211 KEK Unwrap

Severity: Moderate

The first vulnerability affected OpenSSL's handling of CMS (Cryptographic Message Syntax) messages encrypted using password-based encryption, specifically the RFC 3211 Key Encryption Key unwrap operation. Under specific conditions, the decryption routine could perform out-of-bounds memory reads and writes, potentially leading to memory corruption, application crashes, or, in theory, execution of attacker-supplied code.

While the vulnerable code path (PWRI CMS) is rarely used in production, the potential impact was significant. The bug had persisted through multiple major versions, a remnant of early design assumptions that escaped detection due to its confinement to an infrequently invoked legacy code path.

AISLE's system flagged the anomaly through deep analysis of memory access patterns and control flow, identifying the boundary violation that could occur under specific input conditions. We reported the issue with a proposed fix, and OpenSSL adopted the logic of our patch, reformulated for clarity, in their September 2025 release. The bug had been present since late 2009 and lingered in the codebase for over fifteen years.

Affected file: crypto/cms/cms_pwri.c

Vulnerable code (before):

C
1/* should reject when 4 + tmp[0] > inlen */
2if (inlen < (size_t)(tmp[0] - 4))           /* BUG */
3    goto err;
4memcpy(out, tmp + 4, tmp[0]);               /* OOB read/write <=4 B */

In plain terms: the original check could underflow and accept invalid lengths; the fix requires the total payload length to be at least 4 + the declared length byte.

Fixed code (current):

C
1/* Check check bytes */
2if (((tmp[1] ^ tmp[4]) & (tmp[2] ^ tmp[5]) & (tmp[3] ^ tmp[6])) != 0xff)
3    goto err;
4
5if (inlen < 4 + (size_t)tmp[0]) {  /* FIX: Correct boundary check */
6    goto err;
7}
8*outlen = (size_t)tmp[0];
9memcpy(out, tmp + 4, *outlen);     /* Now safe */

CVE-2025-9231: Timing Side-Channel in SM2 Signatures on 64-bit ARM

Severity: Moderate

The second vulnerability was conceptually different and far more subtle: a timing side-channel in the SM2 elliptic-curve signature implementation, observable only on 64-bit ARM architectures. Variations in execution time during modular arithmetic operations created a measurable timing signal that could, in principle, allow private key recovery through careful remote observation.

This optimization-era bug lived for ~2 years before being corrected.

While OpenSSL doesn't natively enable SM2 certificates in TLS, custom cryptographic providers could expose this algorithm in deployed contexts. The flaw required extraordinarily precise timing measurements and statistical analysis to exploit. More importantly, detecting it required reasoning about subtle algorithmic properties and architecture-specific execution behavior. This was not a simple typo or buffer miscalculation, but a logic-level vulnerability where the correctness of the code obscured a timing side-channel that only emerged under specific hardware conditions.

Affected file: crypto/ec/ecp_sm2p256.c

The timing signal originated from variable-time modular inversion operations. This behavior arrived with the SM2 aarch64 optimization and remained in releases for about two years. After our report, which included a detailed proposed patch and proof-of-concept demonstrating a potential for remote exploitability, the OpenSSL team adopted our approach of replacing the variable-time inversion paths with constant-time primitives in their September 2025 release.

Vulnerable path:

C
1static void ecp_sm2p256_point_get_affine(P256_POINT_AFFINE *R, const P256_POINT *P)
2{
3    /* ... */
4    ecp_sm2p256_mod_inverse(z_inv3, P->Z);  /* Calls variable-time inversion */
5    /* ... */
6}

Variable-time inversion (vulnerable):

C
1while (!is_one(u) && !is_one(v)) {
2    while (is_even(u)) {                   /* Timing varies with data */
3        bn_rshift1(u);
4        mod_div(x1, x1);
5    }
6    while (is_even(v)) {                   /* Timing varies with data */
7        bn_rshift1(v);
8        mod_div(x2, x2);
9    }
10    if (is_greater(u, v) == 1) {           /* Branch on secret data */
11        bn_sub(u, u, v);
12        mod_sub(x1, x1, x2);
13    } else {
14        bn_sub(v, v, u);
15        mod_sub(x2, x2, x1);
16    }
17}

Fixed code (current): The SM2 method now uses constant-time field inversion:

C
1const EC_METHOD *EC_GFp_sm2p256_method(void)
2{
3    static const EC_METHOD ret = {
4        /* ... */
5        ecp_sm2p256_field_mul,
6        ecp_sm2p256_field_sqr,
7        0 /* field_div */,
8        ossl_ec_GFp_simple_field_inv,  /* Now uses constant-time inversion */
9        /* ... */
10    };
11    return &ret;
12}

CVE-2025-9232: Out-of-Bounds Read in HTTP Client no_proxy Handling

Severity: Low

The third vulnerability was narrower in scope but demonstrated how even mature, heavily audited code can regress at specification boundaries. When the no_proxy environment variable was set and an HTTP URL contained an IPv6 host, the parsing routine could read past the buffer boundary, triggering a controlled crash.

This regression lived for ~1 year before being corrected.

Although exploitation conditions were narrow, requiring both an attacker-controlled URL and a specific environment configuration, the bug exemplified how subtle edge cases can introduce vulnerabilities even in well-maintained codebases. After our report, OpenSSL used our proposed patch, a single line adding the missing null terminator, directly. The regression was present for roughly a year, from mid‑2024, until it was corrected in September 2025.

Affected file: crypto/http/http_lib.c

Vulnerable code (before):

C
1/* Missing terminator after bracket-stripping */
2sl -= 2;
3strncpy(host, server + 1, sl);
4server = host;             /* host may be unterminated here */
5...
6found = strstr(no_proxy, server);  /* needle reads past buffer */

Because later checks index found[sl], the unterminated needle can cause strstr() to scan past the stack buffer while searching for a delimiter or terminator.

Fixed code (current):

C
1if (sl >= 2 && sl < sizeof(host) + 2 && server[0] == '[' && server[sl - 1] == ']') {
2    /* strip leading '[' and trailing ']' from escaped IPv6 address */
3    sl -= 2;
4    strncpy(host, server + 1, sl);
5    host[sl] = '\0';              /* FIX: Null-terminate the string */
6    server = host;
7}
8/* ... */
9if (no_proxy != NULL)
10    found = strstr(no_proxy, server);  /* Now safe: server is terminated */

Impact and Propagation

These vulnerabilities aren't isolated research artifacts. They affected infrastructure at global scale. OpenSSL powers encryption for the majority of internet traffic, is integrated into every major operating system, and runs on millions of servers, embedded devices, and cloud services worldwide.

The fixes were applied across seven OpenSSL release branches (3.5.4, 3.4.3, 3.3.5, 3.2.6, 3.0.18, 1.1.1zd, 1.0.2zm) and immediately propagated through downstream distributions. Ubuntu's security notice USN-7786-1, published September 30, 2025, delivered patches across seven Ubuntu releases from 25.04 back through 14.04 LTS. Similar coordinated updates rolled out through Red Hat, Debian, Alpine, and other major distributions.

While all three vulnerabilities were assessed as Moderate or Low severity according to OpenSSL's security policy, this reflects narrow attack surfaces rather than trivial impact. CVE-2025-9230 carried the possibility of memory corruption and code execution. CVE-2025-9231 could theoretically enable private key recovery in specialized deployment contexts. Even the Low-severity CVE-2025-9232 could cause denial of service under specific conditions.

Given OpenSSL's ubiquity, even narrow vulnerabilities require system-wide remediation. The fact that patches were applied to seven active branches demonstrates the scope of coordination required to secure foundational infrastructure.

Beyond CVEs: Proactive Prevention

While we discovered and reported these three CVEs, there was a fourth finding that never became public: a double-free vulnerability in OpenSSL's OCSP (Online Certificate Status Protocol) implementation. AISLE detected the issue in PR #28300, reported it to the maintainers, and the fix was merged before the vulnerable code ever appeared in a release.

The commit message reads: "Issue and a proposed fix reported by Stanislav Fort (Aisle Research)."

This is exactly the outcome we're working toward: vulnerabilities prevented, not merely patched after deployment. By integrating autonomous analysis directly into development workflows, security issues can be identified and resolved before they reach users. The OpenSSL PR demonstrates what's possible when AI-driven analysis becomes part of the software lifecycle rather than an external audit step.

Responsible Disclosure and Collaboration

From the moment our system flagged these anomalies, we approached this as a partnership with the OpenSSL community. We submitted detailed technical reports through their coordinated security reporting process, providing not just vulnerability descriptions but complete reproduction steps, root cause analysis, and concrete patch proposals. In each case, our proposed fixes either informed or were directly adopted by the OpenSSL team.

The OpenSSL team's responsiveness was exceptional. Under the leadership of Tomáš Mráz, Public Support and Security Manager at the OpenSSL Foundation, the maintainers engaged technically at every stage – validating findings, refining patches, coordinating releases across multiple branches, and synchronizing with downstream distributions. That level of stewardship enabled all three vulnerabilities to be patched effectively throughout the ecosystem within weeks.

We're profoundly grateful to Tomáš and the entire OpenSSL team for their professionalism and collaboration. Their work ensures that when security researchers, human or autonomous, report issues, the fixes reach users quickly and reliably.

What This Means

Building autonomous systems that can analyze codebases at this depth, identify subtle vulnerabilities that have evaded human review, propose production-ready fixes, and operate responsibly within coordinated disclosure frameworks is exactly what we set out to achieve.

But the significance extends beyond any single company's capabilities. OpenSSL represents one of the most scrutinized, battle-tested, and carefully maintained open-source projects in existence. The fact that three previously unknown vulnerabilities could still be found there, and that an autonomous system found them systematically rather than through isolated lucky discoveries, suggests we're entering a new phase in software security.

The asymmetry that AI created for attackers, the ability to weaponize vulnerabilities at machine speed, is beginning to shift. Autonomous defense systems like AISLE can now operate at comparable scale, speed and depth, scanning millions of lines of code, reasoning about subtle edge cases, and identifying vulnerabilities that would require months or years of expert human effort to discover.

At AISLE, we believe deeply that advances in AI security must serve the collective good. When autonomous systems contribute to protecting the infrastructure that underpins the modern internet, from HTTPS connections to encrypted messaging to secure financial transactions, everyone benefits. The OpenSSL vulnerabilities we discovered and helped remediate represent one milestone in a much longer journey.

Learn More

Interested in AISLE's autonomous security platform? Visit us at aisle.com or reach out to [email protected].

For technical details about these vulnerabilities:

Our deep appreciation goes to Tomáš Mráz and the OpenSSL Foundation for their exceptional collaboration, and to the entire open-source security community for maintaining the infrastructure we all rely on, with additional thanks to Matt Caswell and Neil Horman for their coordination behind the scenes.