In November 2022, OpenSSL 3.0.7 fixed two high-severity vulnerabilities, CVE-2022-3602 and CVE-2022-3786, first announced as a single critical flaw. For payment operators such as PSPs, PayFacs and ISVs, the episode remains a template for incident response: assess exposure, assign owners across security and engineering, patch the most exposed systems first and report on a fixed schedule.
This article was first published by Damien Fleuriot in November 2022, as the industry waited for the patch. It was updated in October 2026 as a retrospective: what the vulnerability was, why a flaw in a cryptographic library matters to a payment platform, how leadership should respond to a critical CVE, how a payment infrastructure limits its exposure, and what the episode taught about disclosure.
What was the OpenSSL 3.x vulnerability of November 2022?
On October 25, 2022, the OpenSSL project pre-announced the release of OpenSSL 3.0.7 for November 1, fixing a vulnerability rated critical, the highest level, and the first of its kind in years. The announcement started a week of intense preparation across the industry.
On release day, the issue turned out to be two high-severity vulnerabilities: CVE-2022-3602 and CVE-2022-3786, buffer overflows in certificate verification. Both could crash a process, and the first could in theory allow remote code execution, but only on systems verifying client certificates, which is not the default, and with exploitation made unlikely by common stack protections, as Datadog Security Labs showed.
Why does a flaw in OpenSSL matter to a payment platform?
OpenSSL is one of the most widely used cryptographic libraries in the world. It implements the encryption, decryption, signing and verification behind TLS connections in web servers, load balancers, API gateways, network equipment and countless embedded devices.
A payment platform relies on such libraries at every hop: between shoppers and checkout pages, between merchants and APIs, and between the platform and acquirers. A critical flaw anywhere in that chain starts a race between teams patching their systems and attackers reverse-engineering the fix, and card data is the prize.
How should a PSP's CEO, CISO and CTO respond to a critical CVE?
- CEO and COO: ask the CISO, or the CTO if there is no CISO, for the organization's exposure and a step-by-step remediation plan, with a clear reporting schedule.
- CISO: assess which systems are exposed and what the risk is, explain it to leadership, and do not close the meeting before roles, responsibilities and tasks are agreed.
- CTO: bring infrastructure, security operations and software teams together, assign owners per product line, agree on progress reports and stay available while patches roll out.
Teams will work long hours during such a window: plan for it, and recognize it.
How can a payment infrastructure limit its exposure to library vulnerabilities?
By reducing how many components hold sensitive cryptography and how quickly they can be patched. Terminating TLS at managed edge and cloud services, keeping cardholder data encryption in hardware security modules, minimizing third-party cryptographic libraries in application code, and enforcing automatic patching and device posture checks on workstations all shrink the attack surface.
In 2022, NORBr's platform did not use the affected OpenSSL versions. The same principles, applied continuously, are described in platform operations and security, and the TLS configuration checklist covers the protocol side.
What did the episode teach about vulnerability disclosure timing?
That pre-announcements work. The week between the announcement and the release let organizations inventory their OpenSSL 3.x usage, prepare patches and plan maintenance windows before details were public. When the severity was downgraded on release day, the preparation was not wasted: it tested inventories and response plans for the next critical issue.
For payment operators, the lesson is to keep an up-to-date software inventory, know which systems use which libraries, and rehearse the response before the next disclosure. Those practices also support the vulnerability management requirements in the PCI DSS compliance cost article.
_%2520a%2520game%2520changer%2520for%2520digital%2520transactions_-Cover.webp){kind=spacer}
