Click here for a list of the fixed issues.

The following table lists the release notes for this release:

Tip: To search for specific issues, enter keywords in the relevant filter.
Component Issue Number Description
Security OCTA-80321

Important Notice – Breaking Change

Do not install OpenEdge 12.2.19 or later before reviewing this information.

OpenEdge 12.2.19 introduces a breaking security change that permanently removes support for the OECH1 encoding algorithm. This change is required to remediate a known security vulnerability.

Once this update is applied, any use of OECH1‑encoded values will result in runtime errors and may prevent OpenEdge components from running. Progress strongly recommends that a migration plan is created and tested prior to installing this update in production to avoid service disruption. Progress Software strongly recommends taking a full backup of your system before applying the update to manage any migration errors where the update must be restarted.

Security Update Overview

The OECH1 encoding algorithm, historically used to obfuscate administrative system passwords and sensitive configuration values, has been identified as cryptographically weak and unsuitable for enterprise use. CVE‑2025‑8095 demonstrates that OECH1‑encoded values can be exploited and must be considered compromised.

Beginning with OpenEdge 12.2.19, OECH1 is permanently removed across the platform.

Key points:
  • OECH1 is no longer permitted at runtime.
  • All OpenEdge components will raise errors if OECH1‑encoded values are encountered.
  • Both platform‑managed and customer‑managed OECH1 values must be replaced with stronger encoding algorithms.
  • Re‑encoding existing values without changing the underlying secret is insufficient and remains insecure.
User accounts managed by OpenEdge (_USER) do not use OECH1 and are not affected.

Affected Versions

All OpenEdge 12.2.x versions prior to 12.2.19 are subject to this vulnerability.

Upgrading to 12.2.19 without first remediating OECH1 usage will result in system startup or runtime failures.

Behavior Changes in OpenEdge 12.2.19
  • Platform‑managed OECH1 usage has been replaced with stronger encoding.
  • All customer‑managed OECH1‑encoded values are rejected at runtime and must be changed.
  • OpenEdge will log explicit errors identifying the presence of OECH1 values.

This release is not backward compatible with deployments that rely on OECH1.

Customer Migration Requirements

Customers must identify and replace all customer‑managed OECH1‑encoded values prior to production deployment.

Common usage locations include:
  • OpenEdge configuration and property files
  • .pf files
  • Integration and system access credentials
Common OECH1 Use CasesCustomer‑managed OECH1 usage typically includes:
  • Administrative passwords stored in configuration or .pf files
  • Database administrative passwords used for bootstrapping AVM connections
  • OpenEdge Management (OEE/OEM) administrative credentials
  • Domain Access Codes (DAC) for ABL clients and utilities
  • TLS/SSL keystore alias credentials
  • OEAG authentication keys and passwords
Additional sources:
  • Generation of encoded passwords or audit keys (e.g. ABL method ENCRYPT-AUDIT-MAC-KEY())
  • Command‑line utilities (e.g. genpassword)
  • Interactive administrative utilities
Upgrade and Migration Guidance

Recommended Upgrade Flow to 12.2.19

  1. Identify all customer‑managed OECH1‑encoded values across your environment.
  2. Replace affected credentials with new values encoded using a stronger supported obfuscation algorithm.
  3. Validate configuration files and .pf files prior to system startup.
  4. Test all runtime paths to ensure no remaining OECH1 usage is detected in logs.
If upgrading from OpenEdge 11.x, complete the standard upgrade process to OpenEdge 12 before addressing OECH1 remediation.

Finding OECH1 Usage

Before upgrading, customers should perform a comprehensive scan of their OpenEdge installation directories to proactively locate OECH1‑encoded values. Configuration files are the most common source of latent OECH1 dependencies that may not surface until specific services are started.

After static scanning, runtime testing should be performed to identify any remaining usage reported in OpenEdge or system logs.

Security Risk Statement

Continuing to use OECH1 significantly weakens the security posture of OpenEdge environments. OECH1‑encoded credentials should be treated as compromised.

Re‑encoding historical OECH1 values without changing the underlying secret does not mitigate risk. If attackers obtain earlier OECH1‑encoded values, they may still exploit updated deployments.

Customers are advised to:
  • Change all administrative and integration credentials
  • Secure all OpenEdge installations, databases, and configuration files
  • Eliminate all OECH1 usage prior to production deployment
Summary

OpenEdge 12.2.19 is a backward‑incompatible release that introduces a mandatory security remediation.

Failure to migrate OECH1‑encoded values before applying this update will result in runtime errors and service outages. Customers must plan and execute migration activities carefully to ensure continued system availability.
Install OCTA-82879

Starting with OpenEdge 12.2.19, update releases are delivered as both incremental and complete installations. This means that a previous version of OpenEdge 12.2 does not need to be installed before running the 12.2.19 installer.
Install OCTA-82874

Starting with OpenEdge 12.2.19, update releases are provided as complete installations. You no longer need to install a previous version of 12.2 JMS Adapter before applying the update. In other words, you can directly add the OpenEdge JMS Adapter version 12.2.19 or later to an existing OpenEdge installation, even if the JMS Adapter was not previously installed.
Install OCTA-82873

Starting with OpenEdge 12.2.19, update releases are provided as full installations. You no longer need to install a previous version of 12.2 ESB Adapter before applying the update. In other words, you can directly add the OpenEdge ESB Adapter version 12.2.19 or later to an existing OpenEdge installation, even if the ESB Adapter was not previously installed.
OEM OCTA-88981

When starting a database from OpenEdge Management, the lgTruncateFrequency parameter (which controls database log file truncation frequency) is incorrectly set to 0 (daily) instead of the expected default value –1 (disabled). As a result, log file truncation runs on a daily schedule even though it should be disabled.

Workaround: Change the lgTruncateFrequency parameter in OpenEdge Management to any value between 0 and 7, save the change, and then reset the value to –1 and save again. The parameter then retains the correct value of –1. 
PASOE OCTA-87658

This release upgrades the bundled Apache Tomcat to version 9.0.113.
In this version, the HTTPS Connector attribute strictSni is enabled by default (true). When enabled, Tomcat enforces validation to ensure the TLS Server Name Indication (SNI) host matches the configured HTTP virtual host. Certain load balancer or proxy configurations may experience rejected HTTPS requests after upgrading.

To retain previous behavior, you may set strictSni="false" in the HTTPS Connector configuration. However, disabling this setting is not recommended, as the default configuration improves security.
SQL OCTA-88932

In OpenEdge Release 12.2.19, the Progress OpenEdge ODBC Driver has been upgraded to version 08.02.0399, which includes an ICU upgrade for Solaris. As a result, the /opt/developerstudio12.6/lib/compilers/atomic/sparcv9  directory must be added to LD_LIBRARY_PATH environment variable on Solaris systems. This change is required to successfully use the Progress OpenEdge ODBC Driver for Solaris platform.
WebClient OCTA-89219

Running older 12.2 webclient installers on non administrator accounts will fail if the 2017-2026 visual c++ redistributable is installed.