Hi everyone! As part of the Erlang/OTP vulnerability reporting efforts, Erlang/OTP is going to start testing the creation of OpenVEX statements for OTP 26, 27, and 28. This test with OpenVEX will be conducted on the master branch, under the vex statements folder. For now, do not trust the contents until we have finished our evaluation.
What is OpenVEX
OpenVEX is an implementation of the Vulnerability Exploitability Exchange (VEX).
OpenVEX statements will be published in this testing phase on a per release basis, meaning that we group statements per release.
Erlang/OTP OpenVEX files provide information about our own- and third-party vulnerabilities, e.g., pcre2, openssl, asmjit, etc. As an example:
{
"@context": "https://openvex.dev/ns/v0.2.0",
"@id": "https://openvex.dev/docs/public/otp/vex-otp-27",
"author": "vexctl",
"timestamp": "2025-06-18T12:18:10.731951+02:00",
"last_updated": "2025-06-18T12:18:16.706806968+02:00",
"version": 19,
"statements": [
{
"vulnerability": {
"name": "CVE-2023-45853"
},
"timestamp": "2025-06-18T12:18:16.441327823+02:00",
"products": [
{
"@id": "pkg:github/madler/zlib@04f42ceca40f73e2978b50e93806c2a18c1281fc"
}
],
"status": "not_affected",
"justification": "vulnerable_code_not_present"
},
...
In this statement, Erlang/OTP declares to not be vulnerable to CVE-2023-45853, which affected Zlib (commit on which Erlang/OTP vendors the Zlib version 04f42ceca40f73e2978b50e93806c2a18c1281fc). The statement declares that the vulnerable code is not present in Erlang/OTP. For the cases where Erlang/OTP is vulnerable, a remediation strategy can be provided in the OpenVEX statement.
As there is no good way to declared version ranges in the OpenVEX specification, Erlang/OTP prefers to opt for verbosity and conciseness rather than a loose format. As an example, CVE-2023-48795 is at the moment written as follows,
which mentions all OTP release versions affected as well as the applications versions.
{
"vulnerability": {
"name": "CVE-2023-48795"
},
"timestamp": "2025-06-18T12:18:04.385308178+02:00",
"products": [
{
"@id": "pkg:otp/erlang@26.2"
},
{
"@id": "pkg:otp/erlang@26.2.2"
},
{
"@id": "pkg:otp/erlang@26.2.3"
},
{
"@id": "pkg:otp/erlang@26.2.4"
},
{
"@id": "pkg:otp/erlang@26.2.5"
},
{
"@id": "pkg:otp/erlang@26.2.5.1"
},
{
"@id": "pkg:otp/erlang@26.2.5.2"
},
{
"@id": "pkg:otp/erlang@26.2.5.3"
},
{
"@id": "pkg:otp/erlang@26.2.5.4"
},
{
"@id": "pkg:otp/erlang@26.2.5.5"
},
{
"@id": "pkg:otp/erlang@26.2.5.6"
},
{
"@id": "pkg:otp/erlang@26.2.5.7"
},
{
"@id": "pkg:otp/erlang@26.2.5.8"
},
{
"@id": "pkg:otp/erlang@26.2.5.9"
},
{
"@id": "pkg:otp/erlang@26.2.5.10"
},
{
"@id": "pkg:otp/erlang@26.2.5.11"
},
{
"@id": "pkg:otp/erlang@26.2.5.12"
},
{
"@id": "pkg:otp/erlang@26.2.5.13"
},
{
"@id": "pkg:otp/ssh@5.1"
},
{
"@id": "pkg:otp/ssh@5.1.2"
},
{
"@id": "pkg:otp/ssh@5.1.3"
},
{
"@id": "pkg:otp/ssh@5.1.4"
},
{
"@id": "pkg:otp/ssh@5.1.4.1"
},
{
"@id": "pkg:otp/ssh@5.1.4.2"
},
{
"@id": "pkg:otp/ssh@5.1.4.3"
},
{
"@id": "pkg:otp/ssh@5.1.4.4"
},
{
"@id": "pkg:otp/ssh@5.1.4.5"
},
{
"@id": "pkg:otp/ssh@5.1.4.6"
},
{
"@id": "pkg:otp/ssh@5.1.4.7"
},
{
"@id": "pkg:otp/ssh@5.1.4.8"
},
{
"@id": "pkg:otp/ssh@5.1.4.9"
},
{
"@id": "pkg:otp/ssh@5.1.4.10"
}
],
"status": "affected",
"action_statement": "Mitigation: If strict KEX availability cannot be ensured on both connection sides, affected encryption modes(CHACHA and CBC) can be disabled with standard ssh configuration. This will provide protection against vulnerability, but at a cost of affecting interoperability",
"action_statement_timestamp": "2025-06-18T12:18:04.385308178+02:00"
},
Scope of OpenVEX
It is important to understand that any claims that Erlang/OTP makes in OpenVEX refers to the actual source code included in OTP. For example, Erlang/OTP can claim to not be vulnerable to some openssl CVE because the openssl code that OTP vendors are not vulnerable. However, one can build OTP linking to openssl and be affected such CVE. The claims in the OpenVEX files are only related to Erlang/OTP source code
Erlang/OTP will do a new announcement once we have finished this testing phase.
Why is this important to me?
-
You do not need to act on this.
-
This announcement is important if you use vulnerability scanning tools on your software.
OpenVEX statements allows you to filter out false positives, and check if your Erlang/OTP is vulnerable (since we are reporting also vulnerabilities in these statements).
