CVE-2026-54891 Erlang/OTP Vulnerability
Improper Enforcement of Message Integrity During Transmission in a Communication Channel vulnerability in Erlang/OTP ssl (tls_gen_connection module) allows a network-positioned attacker to inject unauthenticated plaintext that the TLS client application later treats as authenticated server data. The function tls_gen_connection:handle_protocol_record/3 rejects APPLICATION_DATA records that arrive in pre-handshake states when the TLS endpoint acts as a server, but does not apply the same check when the endpoint acts as a client. A network-positioned attacker can send plaintext APPLICATION_DATA records to the client during the handshake. The records are buffered and, once the handshake completes successfully, delivered to the application as if they were authenticated post-handshake data. The attacker cannot observe the client's response or steer the connection, so the impact is limited to blind injection of unauthenticated bytes. The injection window is wider for TLS versions prior to TLS 1.3 than for TLS 1.3. This vulnerability is associated with program file lib/ssl/src/tls_gen_connection.erl. This issue affects OTP from OTP 17.0 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 5.3.4 before 11.7.3, 11.6.0.3 and 11.2.12.10. TLS 1.3 is affected starting with OTP 22.0, when TLS 1.3 support was added.
Quick answer
Erlang/OTP should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.
Who is affected
Affected versions
- Erlang/OTP 17.0 through 29.0.2
- Erlang/OTP 28.x before 28.5.0.3
- Erlang/OTP 27.x before 27.3.4.14
Fixed versions
- Erlang/OTP 29.0.3 or later
- Erlang/OTP 28.5.0.3 or later
- Erlang/OTP 27.3.4.14 or later
How to fix it
CVE-2026-54891 affects Erlang/OTP. The affected range is Erlang/OTP 17.0 through 29.0.2, Erlang/OTP 28.x before 28.5.0.3, Erlang/OTP 27.x before 27.3.4.14. Update to Erlang/OTP 29.0.3 or later, Erlang/OTP 28.5.0.3 or later, Erlang/OTP 27.3.4.14 or later. Fix exposed systems first, especially where internet-facing services, admin panels, and trusted internal users can be reached. If abuse is suspected, review logs and rotate secrets that may have been exposed.
- Inventory every Erlang/OTP install and note the exact version.
- Compare each install with the affected range: Erlang/OTP 17.0 through 29.0.2, Erlang/OTP 28.x before 28.5.0.3, Erlang/OTP 27.x before 27.3.4.14.
- Update to Erlang/OTP 29.0.3 or later, Erlang/OTP 28.5.0.3 or later, Erlang/OTP 27.3.4.14 or later.
- If you cannot patch today, restrict internet-facing services, admin panels, and trusted internal users to trusted users and networks.
- Back up the current configuration before changing production systems.
- Review recent logs for crashes, strange admin actions, failed logins, or unexpected access.
- Rotate passwords, tokens, certificates, or keys if compromise is suspected.
- Document the change, owner, date, and final version.
Scan now. Google sign-in is only needed to unlock fix guidance.
Verify the fix
- Confirm the installed version now matches the fixed guidance: Erlang/OTP 29.0.3 or later, Erlang/OTP 28.5.0.3 or later, Erlang/OTP 27.3.4.14 or later.
- Confirm old affected versions are no longer deployed: Erlang/OTP 17.0 through 29.0.2, Erlang/OTP 28.x before 28.5.0.3, Erlang/OTP 27.x before 27.3.4.14.
- Confirm internet-facing services, admin panels, and trusted internal users is limited to the smallest needed group.
- Rerun the relevant Fixnx scan or internal security check after the change.
- Save logs, screenshots, or package output as proof of the fix.
Related categories
Trusted references
FAQ
What is affected by CVE-2026-54891?
Erlang/OTP versions listed as affected should be reviewed: Erlang/OTP 17.0 through 29.0.2, Erlang/OTP 28.x before 28.5.0.3, Erlang/OTP 27.x before 27.3.4.14.
What should I fix first?
Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.
How do I confirm the fix worked?
Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.
How are Fixnx security risk categories chosen?
Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.