2026.3.0 STS

September 25, 2026

In this release:

• 2026.3.0 STS
  • Key Features: 2026.3.0
  • Enhancements: 2026.3.0
  • Bug Fixes: 2026.3.0
  • Bugs: Security Vulnerability Fixes

Key Features: 2026.3.0

Observability Enhancements: Metrics Logging Enhancements

This release introduces a new metrics logging framework that periodically captures and persists container health data to a structured JSON format metrics log, enabling integration with modern log aggregation and monitoring platforms such as Elasticsearch, Splunk, and OpenSearch.

Key Enhancements

• JSON format metrics logs — A new configurable scheduled job periodically logs container health metrics to metrics.log in ECS-formatted JSON. The job frequency can be adjusted using admin console or automation recipe. Metrics are captured from a pre-configured Health Panel and can include any metrics that are displayed on the Admin Console Monitoring Tab.

• Additional container health metrics capture:

  • JVM Metrics — Akana containers now capture JVM-level health metrics such as heap utilization, GC pause time, and thread counts, enabling early detection of memory pressure and performance degradation.

  • MongoDB Health Monitoring — MongoDB connection and operational health metrics such as connection pool usage, heartbeat status, and command failure rates are now available for tracking. Sharded MongoDB deployments additionally report per-shard and config-server health states.

  • Gateway-to-Policy-Manager Communication Metrics — To provide visibility into ND-PM communication degradation before it impacts live API traffic, Akana now captures metrics such as response time, total and failed request counts, and response size per PM communication APIs grouped under communication channels.

Benefits

• Proactive failure detection — Continuous metrics logging surfaces early indicators of heap exhaustion, GC pressure, thread leaks, and database connection issues before they cause outages.

• Seamless observability platform integration — ECS-formatted JSON output integrates directly with Elasticsearch, OpenSearch, Splunk, and other log aggregation platforms without custom parsing.

• End-to-end infrastructure visibility — JVM, MongoDB, and Gateway-to-Policy-Manager metrics in a single log provide a unified view of container health across the entire Akana platform.

• Operational flexibility — Scheduler frequency is configurable per environment and can be updated without a container restart.

To get started, refer to the Metrics Log documentation.

Case number: No associated case

Enhancements: 2026.3.0

Java 21 Support

Akana now supports Java 21 to leverage the benefits offered by this version and long-term support compliance.

The Akana Platform is compatible with JRE 21.0.10+7 and shipped with OpenLogic OpenJDK 21.0.10+7. You can also configure the platform to use an external JRE. Akana is certified to work with Oracle 21.0.10+7 as an external JRE. While certification is specific to this version, there are no known limitations with other Java 21 compliant JREs.

Next Steps Before Upgrading

• OS Compatibility — Verify that your operating system version is compatible with JRE 21.0.10+7 before upgrading. Refer to Platform Requirements for the certified OS matrix.

• Custom Policy Compatibility — Review and test any custom policy bundles against Java 21. Pay particular attention to policies using third-party libraries using commons-lang which was updated in the Akana version 2026.2.0.

• Startup scripts — If you are using custom startup scripts for Akana with modified JAVA_OPTS, use the latest from the Akana release and update accordingly. Java 21 defaults to G1GC. If your containers were tuned with explicit GC flags for older collectors such as CMS, remove or replace those flags to avoid container startup failures.

• TLS Cipher Suites — Java 21 disables certain legacy cipher suites and TLS protocols by default. Validate your TLS configuration for both Jetty and HTTP client and update cipher suite lists as needed to ensure continued connectivity with backends and clients. For details. refer Configure TLS for inbound requests with Cipher suites, Configure TLS for outbound requests with Cipher suites, and Enable TLS logging.

• Keystore and certificate tooling — If you use keytool scripts for certificate management using the Akana internal JRE, verify compatibility with Java 21's stricter default key algorithm requirements.

• EntrustHSM Configuration — If your deployment uses Entrust HSM, additional configuration is required. Refer to EntrustHSM configuration for instructions.

Case number: No associated case

MongoDB 8 Support

Akana now supports MongoDB 8, allowing you to leverage the latest database features and optimizations.

Akana still continues to be compatible with MongoDB 7 and other versions mentioned in the System Requirements document.

Case number: 01371104, 01521194, 01587262

Community Manager Login Performance Improvement

Logins to the Community Manager portal via SAML Web SSO were occasionally slow or timed out in environments with a large number of certificates configured in the trust store. This release improves login performance and reliability for these environments. There is no change to existing functionality or configuration.

Case number: 01438256

Configurable File Upload Size Limit for OAS Specifications

Akana now supports a configurable file upload size limit for OAS specifications, allowing you to upload larger API definition files beyond the previous default of 4MB. The maximum supported value is 200 MB, configurable via the MaxFileSizeForUpload business setting.

For optimal developer portal and gateway performance with a 4 GB heap, OAS files up to 10 MB upload and render without issues. Also, the gateway runtime can route the API traffic without issues. Larger files require additional heap and configuration tuning — refer to the OAS upload troubleshooting guide for sizing guidance.

For more information, see Create APIs with large OAS specification files.

If you are experiencing upload failures with large OAS files on current versions, consider reducing the file size by removing any non-essential content from the specification such as detailed documentation or examples before uploading.

Case number: No associated case

Restrict Anonymous Access to Boards, Tickets and Forums

This release introduces tenant-level configuration to control anonymous access to boards, discussions, tickets, alerts, and forums along with related REST APIs for the Akana APIs Apps, and Groups with public visibility.

This feature can be enabled using new setting to restrict the access to only registered users. Site Admins can enable the setting under following sections:

• Admin → Settings → API → Public API Board Support

• Admin → Settings → App → Public App Board Support

• Admin → Settings → Group → Public Group Board Support

When set to Enabled for Registered User, unauthenticated requests to board/forum endpoints for APIs, Apps, or Groups with public visibility will return 401 Unauthorized, ensuring sensitive metadata is accessible only after user login. Also related pages will be hidden from Community Manager Portal.

For details, refer to the documentation.

Case number: 01548511

Bug Fixes: 2026.3.0

Null Example Values in Downloaded OAS 3.0 and OAS 3.1 API Specifications

When downloading an API definition in OAS 3.0 or OAS 3.1 format from the API Details screen, example values in request bodies, response bodies, parameters, and schema properties incorrectly contained null example values. This caused the Developer Portal to show incomplete or inaccurate API documentation. APIs onboarded using RAML specification files were particularly affected. Swagger 2.0 exports were not impacted.

Case number: 01511596

Gateway Pod Startup Failures During Autoscaling with Large Trust Store

In Kubernetes (EKS) deployments with a large number of trusted certificates, newly scaled Gateway pods experienced heap exhaustion, startup failures, and HTTP 500 errors during autoscaling events. This release redesigns the trusted certificate loading mechanism to address the issue.

New config settings in com.soa.mp.core.client.cfg (PID com.soa.mp.core.client) are:

• trusted.ca.cert.keystore.spi.fallbackMode = LAST_GOOD (also BOOTSTRAP, LEGACY)

• trusted.ca.cert.keystore.spi.coldStartWaitMillis = 30000

• trusted.ca.cert.keystore.spi.warmRefreshMode = WAIT (also NO_WAIT)

For more details, see Configuration of the Message Processing Core Client properties.

Non-EKS deployments can also benefit from these new properties with the default settings. No changes required.

Case number: 01592443

External OIDC Provider Login Fails After Platform Upgrade

Following an upgrade, login to the Community Manager portal using an External OIDC provider stopped working for domains created prior to the upgrade. Users attempting SSO login received a Domain not found or registered error, preventing access via external identity providers.

OIDC provider domains created in earlier versions now initialize correctly after upgrade.

As a workaround on an earlier version, if a current deployment is affected, re-saving the OIDC domain in the Community Manager console restores login immediately — no restart required.

Case number: No associated case

Trust Store Certificate Changes May Not Get Applied on Gateway in PMCM + PM-Only Deployments

In deployments where the Gateway connects to a PM-Only container to receive certificate updates, adding or removing certificates in the trust store did not take effect on the Gateway immediately. This caused API calls to return 500 errors even after the correct certificate was added. As a workaround, you had to configure the Gateway to force-refresh its certificate cache every 60 seconds.

The Gateway now picks up trust store certificate changes immediately, regardless of whether it connects to PMCM or PM-Only. The 60-second cache refresh workaround is no longer needed.

To make use of this change, ensure to update database schema as part of upgrade process.

If you previously set trusted.ca.cert.keystore.spi.expireIntervalMillis=60000 as a workaround, you can now change this to -1 to disable the periodic refresh.

Case number: No associated case

Schema Validation Skipped When API Defines Multiple Custom JSON Content Types

When an API OAS 3.0 or OAS 3.1 specification defined multiple custom JSON media types in the request body, the message validation policy was silently skipped, and requests were forwarded without any schema validation. Validation only worked when a single content type was defined.

Both inline requestBody definitions and $ref references to schemas defined under components are supported. This fix applies to OAS 3.0 and OAS 3.1 API definitions. Swagger specifications do not support multiple content types.

Case number: 01525352

Incorrect HTTP Response Code Returned for Token Algorithm Mismatch in External OAuth Provider

When an access token was presented with a signing algorithm that did not match the algorithm configured for the External OAuth Provider, Akana incorrectly returned a 500 Internal Server Error instead of 401 – Invalid Token authentication failure response. This made it difficult for API consumers and client applications to identify and act on the root cause.

Client applications will need to process the new error code 401 - Invalid Token instead of the earlier 500 Internal Server Error.

Case number: 01610330

Sensitive Details Exposed in Gateway Error Responses

When the Gateway encountered certain runtime errors, the error response body exposed internal details, presenting an information disclosure risk.

The new Gateway configuration property bpel.process.engine.suppressServiceDetailsInFaults (PID: com.soa.vs.engine) allows you to replace detailed fault messages with a generic response — "An unexpected error occurred while processing the request" — without exposing internal details. The default value is false for backward compatibility. The error cause continues to be logged internally for troubleshooting.

Case number: 01610330

Bugs: Security Vulnerability Fixes

CVE-2026-85978: Unauthenticated Remote Code Execution in the Akana API Platform

Addressed CVE-2026-85978 in the Akana Policy Manager.

Authentication enforcement in the Policy Manager console has been strengthened. All protected endpoints now correctly require authentication and a path-normalization flaw has been addressed. This fix is applicable to both Standalone Policy Manager and Policy Manager deployed as part of Community Manager.

For additional details, contact Perforce support.

Case Number: No associated case

Third-party Libraries Updated to Mitigate Vulnerabilities

Several third-party libraries have been updated to mitigate critical, high, and some medium priority vulnerabilities. See Using the Third-Party Libraries in the Akana documentation.

Case number: No associated case