Click here for a list of the fixed issues.

The following table lists the release notes for this release:

Component Issue Number Description
Security OCTA-80320

Important Notice – Breaking Change

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

OpenEdge 12.8.11 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.8.11, 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.8.x versions prior to 12.8.11 are subject to this vulnerability.

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

Behavior Changes in OpenEdge 12.8.11

  • 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 Update Requirements for Remediation

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 Cases

Customer‑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

Migration Guidance for Remediation

Recommended Upgrade Flow to 12.8.11
  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.8.11 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.
PDSOE OCTA-87217

Summary

OpenEdge 12.8.11 upgrades the underlying Eclipse Platform to version 4.34. As a result of this platform change, Progress Developer Studio for OpenEdge (PDSOE) does not migrate custom Eclipse plug-ins, third‑party extensions, or workspace associations from releases prior to 12.8.11.

Description

In the 12.8.11 release, PDSOE is built on Eclipse 4.34 to incorporate security updates and align with a later, more stable Eclipse platform. This upgrade introduces certain behavior changes that affect existing PDSOE configurations:
  • Custom plug-ins or extensions installed in OpenEdge releases prior to 12.8.11 are not carried forward automatically. These plug-ins must be reinstalled after updating.
  • Workspace associations configured in earlier releases do not persist automatically. Users will need to recreate these associations after installing 12.8.11.
  • While PDSOE has always relied on the Eclipse P2 model, in 12.8.11 the upgrade to Eclipse 4.34 enforces dependency resolution more strictly, making manual plugin migration methods that previously worked unreliable or fully non‑functional.

This represents a backward‑incompatible change which needs to be managed by the user.

Impact

After installing OpenEdge 12.8.11, users upgrading from earlier releases must reinstall or reconfigure the following in PDSOE:
  • Custom Eclipse plug-ins
  • Third‑party enhancements

Required Customer Actions

Before installing OpenEdge 12.8.11, users should perform the following tasks:
  1. Back up any custom plugins, update sites, or configuration notes from their existing PDSOE environment.
  2. Verify plugin compatibility with Eclipse 4.34.
  3. After installing OpenEdge 12.8.11, reinstall required plugins.
  4. Recreate workspace settings if multiple workspaces were used.