#Release Notes

#v3.0.0-acp.3

Supported on Alauda Container Platform 4.1, 4.2, 4.3 and 4.4, on amd64 and arm64 nodes, on IPv4, IPv6 and dual-stack clusters.

#New and Optimized Features

• OLM operator package. The product is delivered as the OLM package opensearch-operator, display name Alauda Data Services Search Engine E1, channel stable, and installs from OperatorHub. See Installation.
• New API group opensearch.org/v1. The operator is based on upstream OpenSearch Kubernetes Operator 3.0, which manages its resources in the opensearch.org/v1 API group instead of opensearch.opster.io/v1.
• In-place upgrade from operator 2.8.0. Existing opensearch.opster.io/v1 resources are migrated to opensearch.org/v1 automatically, and the old API group becomes read-only. Every node pool is restarted once. The upgrade starts when you switch the 2.8.0 Subscription from the alpha channel to stable; complete Before the upgrade first. The platform log storage keeps using operator 2.8.0 on alpha; do not switch it. See Upgrade.
• Restricted Pod Security by default. The pods the operator creates get security contexts that are compatible with the Kubernetes restricted Pod Security level, unless the custom resource sets those fields. See Pod Security for the created pods.
• No privileged init containers. vm.max_map_count is a node prerequisite instead of a privileged init container, and data volumes are made writable through the pod fsGroup instead of a root init container. See Set vm.max_map_count on nodes.
• Images from the platform registry. The operator selects the engine, Dashboards and init helper images that this release ships from spec.general.version, so they follow the platform's image registry, including in disconnected environments.
• Rebuilt engine images. The OpenSearch and OpenSearch Dashboards images are rebuilt by Alauda from the upstream images, with operating system packages updated and vulnerable libraries replaced by fixed versions. They do not include the Security Analytics and Skills plugins. See Plugins not included.

#Fixed Issues

• A cluster without TLS started with the demo security configuration. A cluster with no TLS configuration now runs with the security plugin disabled, instead of starting with the image's demo security configuration. See Create a Cluster.
• The bootstrap pod's PVC had no StorageClass. On a platform cluster without a default StorageClass, it never bound and the cluster never formed. If spec.bootstrap.storageClass is not set, the bootstrap PVC now uses the storage class of the cluster-manager node pool. See Storage.
• Dashboards could wait forever for its first index migration on a new cluster. The migration was interrupted when the bootstrap pod was removed, or when the startup probe restarted Dashboards before the migration finished. Dashboards now starts only after the cluster has formed and the bootstrap pod is removed, and its startup probe allows 30 minutes for the saved-objects migration. See Dashboards waits for another migration.
• OpenSearch Dashboards never became ready on IPv6-only clusters. It listened on IPv4 only, so its startup probe failed. On a cluster whose primary IP family is IPv6, Dashboards now listens on IPv6. A SERVER_HOST set in spec.dashboards.env still takes precedence.
• The operator Deployment is renamed opensearch-operator-manager. This makes the in-place upgrade from operator 2.8.0 possible, because the Deployment selector cannot change in place. Update any monitoring or automation that refers to the operator Deployment by name.

#Security Fixes

At release, vulnerabilities that have a drop-in fix are fixed in all images. The following are not fixed in this release and are planned for a later patch release:

• OpenSearch Dashboards. npm dependencies that need a major version upgrade, or that have no upstream fix yet, including CVE-2026-85061 (critical, maplibre-gl; see Mitigating CVE-2026-85061). OpenSearch Dashboards 2.19.6 runs on Node.js 18, which is end-of-life upstream and has known vulnerabilities that are fixed only in newer Node.js versions. It also contains a Node.js 14 fallback runtime affected by CVE-2024-3566 (critical, Windows only).
• OpenSearch engine 3.8.0. Jackson and Apache HttpComponents versions shaded inside jars of the security and notifications plugins.
• BusyBox 1.38.0. CVE-2025-60876, CVE-2026-38753, CVE-2026-38754 and CVE-2026-38755, which have no upstream fix yet.
• Operator. GO-2026-5932 in golang.org/x/crypto/openpgp, which has no fixed version.

#Known Issues

• vm.max_map_count must be set on the nodes. spec.general.setVMMaxMapCount has no effect.
• Do not set image overrides. If spec.general.defaultRepo or an image is set in an OpenSearchCluster, the pods can fail to pull their images. See Image settings in the cluster spec.
• Resource changes roll one pod at a time, about 3 to 4 minutes per pod. See Known Limitations.
• No automated rollback to operator 2.8.0. See Upgrade.
• CVE-2026-85061 in the Dashboards Maps plugin is not fixed. See Mitigating CVE-2026-85061.

#Mitigating CVE-2026-85061

CVE-2026-85061 (critical) is a cross-site scripting flaw in maplibre-gl, which the Maps plugin (customImportMapDashboards) of OpenSearch Dashboards 3.8.0 and 2.19.6 uses to draw maps. HTML in a map's attribution text can keep an event-handler attribute, such as onload or ontoggle, after it is sanitized. The handler runs in the browser of a user who opens a map that shows this attribution. To exploit the flaw, an attacker must control the attribution of a map: the attribution of a custom layer in a saved map, or the attribution in a map style from an external tile service.

The following measures were verified on E1 3.0 with both Dashboards versions.

1. Keep the default Content Security Policy. Dashboards sends an enforced Content-Security-Policy header on its pages, including the Maps app. The header does not allow 'unsafe-inline' for scripts, so browsers do not run inline event handlers:

In a browser test on E1 Dashboards, ontoggle, onload and onerror handlers inserted into the page as HTML did not run: the browser blocked each one as a script-src-attr violation. The same markup ran on a page without this header. Therefore:

• Do not add 'unsafe-inline' to the script directives, for example through csp.rules in spec.dashboards.additionalConfig.
• Do not remove or replace the header in a reverse proxy or Ingress in front of Dashboards.
• Use a current browser. A browser that does not enforce Content Security Policy is not protected by this measure.

2. Restrict who can create or change maps. Maps, including the attribution of their custom layers, are saved objects in the Dashboards index. The built-in kibana_user role, and all_access, can create and change them. Map users who only need to view dashboards and maps to a read-only role instead, and do not map them to kibana_user as well; roles add up. For example, with the security plugin REST API:

curl -k -u admin:<admin-password> -X PUT \
  "https://<cluster-service>:9200/_plugins/_security/api/roles/dashboards_read_only" \
  -H 'Content-Type: application/json' -d '{
    "cluster_permissions": ["cluster_composite_ops_ro"],
    "index_permissions": [{
      "index_patterns": [".kibana", ".kibana_*", ".opensearch_dashboards", ".opensearch_dashboards_*"],
      "allowed_actions": ["read"]
    }],
    "tenant_permissions": [{
      "tenant_patterns": ["global_tenant"],
      "allowed_actions": ["kibana_all_read"]
    }]
  }'

curl -k -u admin:<admin-password> -X PUT \
  "https://<cluster-service>:9200/_plugins/_security/api/rolesmapping/dashboards_read_only" \
  -H 'Content-Type: application/json' -d '{"users": ["<user>"]}'

A user who has only this role can log in to Dashboards and open existing maps. Creating, changing or importing a map is rejected with a no permissions for [indices:data/write/...] error. Give kibana_user and all_access only to trusted users.

This measure needs the security plugin. A cluster without TLS configuration runs with the security plugin disabled (see Create a Cluster), so anyone who can reach its Dashboards can create maps. For such a cluster, rely on measure 1 and limit network access to Dashboards.

What does not mitigate the flaw:

• The Maps plugin cannot be disabled through configuration. Setting custom_import_map_dashboards.enabled: "false" in spec.dashboards.additionalConfig makes Dashboards fail to start with ValidationError: [config validation of [custom_import_map_dashboards].enabled]: definition for this key is missing. Do not set it.
• map.includeOpenSearchMapsService: "false" is accepted, but the Maps plugin does not use this setting, so it does not change what the Maps app loads.

For the complete list, see Known Limitations.

OpenSearch® is a registered trademark of LF Projects, LLC.