Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
14 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A regression was introduced in OpenSearch 2.18.0 that caused the plugins.security.ssl.transport.enforcehostnameverification setting to be ineffective. When this setting was enabled, OpenSearch did not verify that the hostname in a connecting node's TLS certificate matched the hostname of the connection. This could allow a node with a valid certificate (signed by the cluster's trusted CA) but an incorrect hostname SAN to join the cluster. Impact Clusters running affected versions with hostname verification enabled did not receive the expected protection from this setting. A node presenting a certificate signed by the cluster's trusted CA could join the cluster regardless of whether its hostname SAN matched. This regression does not affect certificate validation itself — only the additional hostname verification check. Patches This issue is fixed in OpenSearch 2.19.4 and 3.3.0. Workarounds Use more restrictive values for plugins.security.nodesdn to limit which certificates…
Recommended action: Upgrade to 3.3.0.0 or 2.19.4.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was identified in the OpenSearch Security plugin's document-level security (DLS) implementation. DLS restrictions were not correctly applied to search queries that use hasparent or haschild join relations. This could allow an authenticated user to access document contents that should have been restricted by DLS rules. Impact An authenticated user with access to an index containing parent/child join relations could bypass DLS restrictions on documents linked by those relations, potentially accessing restricted document contents. This only affects clusters that use both DLS and the join field type on the same index. Patches This issue is fixed in OpenSearch 2.19.4 and 3.2.0. Workarounds Avoid using the join field type on indices that are subject to DLS rules.
Recommended action: Upgrade to 3.2.0.0 or 2.19.4.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was identified in the OpenSearch Security plugin's handling of index rollover requests. When a rollover request included an explicit target index name, the security plugin did not properly evaluate access control permissions against the target index. This could allow a user with rollover permissions on a source index to create a new index with a name they are not authorized to use. Impact A user with indices:admin/rollover permission on a source index pattern could roll over to a target index name outside their authorized index patterns. This is limited to index creation via the rollover API and requires the user to already have rollover privileges on the source index. Patches This issue is fixed in OpenSearch 2.19.4 and 3.2.0 Workarounds Grant the indices:admin/rollover permission only to fully trusted users.
Recommended action: Upgrade to 3.2.0.0 or 2.19.4.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was identified in the OpenSearch REST layer that could allow authorization checks to be bypassed when processing certain malformed HTTP requests. This could permit unauthorized access to restricted API endpoints in environments that rely on REST-layer authorization. Transport-level authorization is not affected by this issue. Impact The default OpenSearch distribution is not affected by this issue. REST actions in the default distribution have corresponding transport actions that independently enforce authorization. Custom plugins that register REST actions without a corresponding transport action may be affected, potentially allowing unauthorized read access to those endpoints. Patches This issue is fixed in OpenSearch 2.19.0. Users should upgrade to 2.19.0 or later.
Recommended action: Upgrade to 2.19.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact OpenSearch versions 2.19.2 and earlier improperly apply Field Level Security (FLS) rules on fields which are not at the top level of the source document tree (i.e., which are members of a JSON object). If an FLS exclusion rule (like ~object) is applied to an object valued attribute in a source document, the object is properly removed from the source document in search and get results. However, any member attribute of that object remains available to search queries. This allows to reconstruct the original field contents using range queries. Patches The issue has been resolved in OpenSearch 3.0.0 and OpenSearch 2.19.3. Workarounds If FLS exclusion rules are used for object valued attributes (like ~object), add an additional exclusion rule for the members of the object (like ~object.).
Recommended action: Upgrade to 2.19.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact OpenSearch versions 2.19.2 and earlier improperly apply field masking rules on fields of the types ip, geopoint, geoshape, xypoint, xyshape. While the content of these fields is properly redacted in the source document returned by search operations, the original unredacted values remain available to search queries. This allows to reconstruct the original field contents using range queries. Additionally, the content of fields of type geopoint, geoshape, xypoint, xyshape is returned in an unredacted form if requested via the fields option of the search API. Patches The issue has been resolved in OpenSearch 3.0.0 and OpenSearch 2.19.3. Workarounds If you cannot upgrade immediately, you can avoid the problem by using field level security (FLS) protection on fields of the affected types instead of field masking.
Recommended action: Upgrade to 2.19.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact There is an issue with the implementation of tenant permissions in OpenSearch Dashboards where authenticated users with read-only access to a tenant can perform create, edit and delete operations on index metadata of dashboards and visualizations in that tenant, potentially rendering them unavailable. This issue does not affect index data, only metadata. Dashboards correctly enforces read-only permissions when indexing and updating documents. This issue does not provide additional read access to data users don’t already have. Mitigation This issue can be mitigated by disabling the tenants functionality for the cluster. Versions 1.3.14 and 2.11.0 contain a fix for this issue. For more information If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
Recommended action: Upgrade to 2.11.0.0 or 1.3.14.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An issue has been identified with how OpenSearch handled incoming requests on the HTTP layer. An unauthenticated user could force an OpenSearch node to exit with an OutOfMemory error by sending a moderate number of malformed HTTP requests. The issue was identified by Elastic Engineering and corresponds to security advisory ESA-2023-13 (CVE-2023-31418). Mitigation Versions 1.3.14 and 2.11.0 contain a fix for this issue. For more information If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
Recommended action: Upgrade to 2.11.0.0 or 1.3.14.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact There is an issue with the implementation of fine-grained access control rules (document-level security, field-level security and field masking) where they are not correctly applied to the queries during extremely rare race conditions potentially leading to incorrect access authorization. For this issue to be triggered, two concurrent requests need to land on the same instance exactly when query cache eviction happens, once every four hours. Affected versions OpenSearch 1.0.0-1.3.9 and 2.0.0-2.6.0 Patched versions OpenSearch 1.3.10 and 2.7.0 For more information If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
Recommended action: Upgrade to 2.7.0.0 or 1.3.10.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact There is an issue with the implementation of fine-grained access control rules (document-level security, field-level security and field masking) where they are not correctly applied to the indices that back data streams potentially leading to incorrect access authorization. This issue can only be triggered by authenticated users authorized to read those data streams which are backed by the impacted indexes. Additionally, existing privileged users cannot access random indexes within these clusters; they can only access indexes to which they have already been granted permission. Patches OpenSearch 1.3.7 and 2.4.0 contain a fix for this issue. Workarounds There is no recommended work around. For more information If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to aws-security@amazon.com. Please do not create a public GitHub…
Recommended action: Upgrade to 2.4.0 or 1.3.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact There is an observable discrepancy in the authentication response time between calls where the user provided exists and calls where it does not. This issue only affects calls using the internal basic identity provider (IdP), and not other externally configured IdPs. Patches OpenSearch 1.3.9 and 2.6.0 Workarounds None. References If you have any questions or comments about this advisory, please contact AWS/Amazon Security using our issue reporting page [1] or directly via email [2]. Please do not create a public GitHub issue. [1] AWS Security issue reporting page: https://aws.amazon.com/security/vulnerability-reporting/ [2] AWS Security email: aws-security@amazon.com
Recommended action: Upgrade to 2.6.0 or 1.3.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Advisory title: Field-level security issue with .keyword fields Affected versions: OpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1 Patched versions: OpenSearch 1.3.8 and 2.5.0 Impact: There is an issue in the implementation of field-level security (FLS) and field masking where rules written to explicitly exclude fields are not correctly applied for certain queries that rely on their auto-generated .keyword fields. This issue is only present for authenticated users with read access to the indexes containing the restricted fields. Workaround: FLS rules that use explicit exclusions can be written to grant explicit access instead. Policies authored in this way are not subject to this issue. Patches: OpenSearch versions 1.3.8 and 2.5.0 contain a fix for this issue. For more information: If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to…
Recommended action: Upgrade to 2.5.0 or 1.3.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Advisory title: Issue with whitespace in JWT roles Affected versions: OpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1 Patched versions: OpenSearch 1.3.8 and 2.5.0 Impact: OpenSearch uses JWTs to store role claims obtained from the Identity Provider (IdP) when the authentication backend is SAML or OpenID Connect. There is an issue in how those claims are processed from the JWTs where the leading and trailing whitespace is trimmed, allowing users to potentially claim roles they are not assigned to if any role matches the whitespace-stripped version of the roles they are a member of. This issue is only present for authenticated users, and it requires either the existence of roles that match, not considering leading/trailing whitespace, or the ability for users to create said matching roles. In addition, the Identity Provider must allow leading and trailing spaces in role names. Patches: OpenSearch versions 1.3.8 and 2.5.0 contain a fix for this issue. For more information: If you have any…
Recommended action: Upgrade to 2.5.0 or 1.3.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Requests to an OpenSearch cluster configured with advanced access control features (document level security (DLS), field level security (FLS), and/or field masking) will not be filtered when the query's search pattern matches an aliased index. OpenSearch Dashboards creates an alias to .kibana by default, so filters with the index pattern of to restrict access to documents or fields will not be applied. This issue allows requests to access sensitive information when customer have acted to restrict access that specific information. Patches OpenSearch 2.2.0+ contains the fix for this issue. OpenSearch Security Plugin 2.2.0.0 is compatible with OpenSearch 2.2.0. Workarounds There is no recommended work around. References See pull request #1999 for additional details. For more information If you have any questions or comments about this advisory we ask that contact AWS/Amazon Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do…
Recommended action: Upgrade to 2.2.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.