deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-x5hg-x4gv-j98m
Package: org.opensearch.plugin:opensearch-security (MAVEN)
Severity: LOW (CVSS 2.2)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 2.18.0, < 2.19.4.0
Patched in: 2.19.4.0

Summary: OpenSearch has ineffective TLS certificate hostname verification

Details:
### Description

A regression was introduced in OpenSearch 2.18.0 that caused the `plugins.security.ssl.transport.enforce_hostname_verification` 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.nodes_dn` to limit which certificates are accepted for node-to-node communication.
GitHub Security Advisory: GHSA-x83w-23jp-g6pw
Package: org.opensearch.plugin:opensearch-security (MAVEN)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.0.0, <= 3.1.0
Patched in: 3.2.0.0

Summary: OpenSearch Security plugin: DLS not applied on documents linked by has_child or has_parent relation

Details:
### Description

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 has_parent or has_child 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.
GitHub Security Advisory: GHSA-x83w-23jp-g6pw
Package: org.opensearch.plugin:opensearch-security (MAVEN)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.0.0, <= 2.19.3
Patched in: 2.19.4.0

Summary: OpenSearch Security plugin: DLS not applied on documents linked by has_child or has_parent relation

Details:
### Description

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 has_parent or has_child 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.
GitHub Security Advisory: GHSA-22vx-2x23-98w6
Package: org.opensearch.plugin:opensearch-security (MAVEN)
Severity: LOW (CVSS 2.2)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.0.0, <= 3.1.0
Patched in: 3.2.0.0

Summary: OpenSearch vulnerable to improper authorization for Rollover Requests

Details:
### Description

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.
GitHub Security Advisory: GHSA-22vx-2x23-98w6
Package: org.opensearch.plugin:opensearch-security (MAVEN)
Severity: LOW (CVSS 2.2)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.0.0, <= 2.19.3
Patched in: 2.19.4.0

Summary: OpenSearch vulnerable to improper authorization for Rollover Requests

Details:
### Description

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.
GitHub Security Advisory: GHSA-83x9-vc3c-hghc
Package: org.opensearch.plugin:opensearch-security (MAVEN)
Severity: LOW (CVSS 3.7)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.11.0.0, < 2.19.0.0
Patched in: 2.19.0.0

Summary: OpenSearch has a bypass of REST Layer Authorization Using Malformed Paths

Details:
### Description

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.
GitHub Security Advisory: GHSA-hm32-hfmw-rhvg
Package: org.keycloak:keycloak-services (MAVEN)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-425: Direct Request ('Forced Browsing')
Vulnerable versions: <= 26.6.1
Patched in: unpatched

Summary: Keycloak has a Forced Browsing issue

Details:
When Keycloak is started with `--features-disabled=account,account-api`, the Account REST API is only partially disabled. Five endpoints under the versioned path `/account/v1alpha1` remain fully functional — including both read and write operations — because they lack the `checkAccountApiEnabled()` gate that correctly blocks four other endpoints in the same REST service class. The user needs to have permissions to use the API.
GitHub Security Advisory: GHSA-r4w4-wv68-qv85
Package: io.awspring.cloud:spring-cloud-aws-sns (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 3.0.0, <= 3.4.2
Patched in: unpatched

Summary: Spring Cloud AWS missing SNS message signature verification allows spoofing of HTTP/HTTPS endpoint notifications

Details:
### Impact
  
  Applications using Spring Cloud AWS SNS HTTP/HTTPS endpoint support (@NotificationMessageMapping, @NotificationSubscriptionMapping, @NotificationUnsubscribeConfirmationMapping) did not verify the signature of incoming SNS messages.

An unauthenticated attacker who knows the endpoint URL could send crafted HTTP POST requests mimicking SNS Notification or SubscriptionConfirmation messages, causing the application to:
  
  - Process arbitrary payloads as if they were legitimate SNS notifications.
  - Auto-confirm subscriptions or unsubscribe from attacker-controlled topics.
  
Affected versions: 3.0.0 through 3.4.2, 4.0.0, and 4.0.1.
  
The 3.x line will not receive a fix; users on 3.x should apply the workaround below or upgrade to 4.0.2.
  
### Patches
  
Fixed in Spring Cloud AWS 4.0.2. When using Spring Boot auto-configuration, signature verification is enabled by default. Users should upgrade to 4.0.2.
  
### Workarounds
  
Manually verify the SNS message signature in a servlet filter or Spring HandlerInterceptor before the request reaches the controller, using SnsMessageManager from the AWS SDK v2 sns-message-manager module.
  
 ### Resources
  
  - AWS SNS: Verifying the signatures of Amazon SNS messages (https://docs.aws.amazon.com/sns/latest/dg/sns-verify-signature-of-message.html)
  - AWS SDK for Java v2: SnsMessageManager (https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/messagemanager/sns/SnsMessageManager.html)
  - Fix PR: #1614
GitHub Security Advisory: GHSA-r4w4-wv68-qv85
Package: io.awspring.cloud:spring-cloud-aws-sns (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 4.0.0, < 4.0.2
Patched in: 4.0.2

Summary: Spring Cloud AWS missing SNS message signature verification allows spoofing of HTTP/HTTPS endpoint notifications

Details:
### Impact
  
  Applications using Spring Cloud AWS SNS HTTP/HTTPS endpoint support (@NotificationMessageMapping, @NotificationSubscriptionMapping, @NotificationUnsubscribeConfirmationMapping) did not verify the signature of incoming SNS messages.

An unauthenticated attacker who knows the endpoint URL could send crafted HTTP POST requests mimicking SNS Notification or SubscriptionConfirmation messages, causing the application to:
  
  - Process arbitrary payloads as if they were legitimate SNS notifications.
  - Auto-confirm subscriptions or unsubscribe from attacker-controlled topics.
  
Affected versions: 3.0.0 through 3.4.2, 4.0.0, and 4.0.1.
  
The 3.x line will not receive a fix; users on 3.x should apply the workaround below or upgrade to 4.0.2.
  
### Patches
  
Fixed in Spring Cloud AWS 4.0.2. When using Spring Boot auto-configuration, signature verification is enabled by default. Users should upgrade to 4.0.2.
  
### Workarounds
  
Manually verify the SNS message signature in a servlet filter or Spring HandlerInterceptor before the request reaches the controller, using SnsMessageManager from the AWS SDK v2 sns-message-manager module.
  
 ### Resources
  
  - AWS SNS: Verifying the signatures of Amazon SNS messages (https://docs.aws.amazon.com/sns/latest/dg/sns-verify-signature-of-message.html)
  - AWS SDK for Java v2: SnsMessageManager (https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/messagemanager/sns/SnsMessageManager.html)
  - Fix PR: #1614
GitHub Security Advisory: GHSA-248h-974q-xrc2
Package: com.getaxonflow:axonflow-sdk (MAVEN)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-345: Insufficient Verification of Data Authenticity, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 6.0.0
Patched in: 6.0.0

Summary: axonflow-sdk-java: Webhook signing-key (HMAC-SHA256) not exposed by SDK type, preventing signature verification

Details:
## Summary

The AxonFlow SDK's `WebhookSubscription` (or equivalent) type did not expose the HMAC-SHA256 signing key returned by the platform's `CreateWebhook` endpoint. Without access to the secret through the typed SDK API, callers had no path to verify the `X-AxonFlow-Signature` header on incoming webhook deliveries. Affected callers had two unsatisfactory options:

1. Skip signature verification entirely — accepting any payload from any source that knew the webhook URL.
2. Hand-parse the raw HTTP JSON response to extract the secret, bypassing the type-safe SDK surface.

This advisory is filed across all four AxonFlow SDKs (Go, Python, TypeScript, Java) because the same defect and the same fix landed in each.

## Affected versions

Versions prior to 6.0.0.

## Impact

A webhook receiver using the SDK's typed API to handle inbound deliveries had no path to authenticate the source of incoming payloads. An attacker who learned the webhook URL — through misconfiguration, log leakage, observable network traffic during setup, or any other discovery channel — could forge webhook deliveries indistinguishable from legitimate ones, causing the receiving application to act on fabricated events (e.g. simulated approval-granted callbacks, simulated policy-decision callbacks, simulated step-completion callbacks).

## Remediation

Upgrade to the patched version listed in Vulnerabilities below. The signing key is now exposed on the `WebhookSubscription` response type returned by `CreateWebhook`. Implementations should:

1. Persist the secret returned by `CreateWebhook` securely (it is only returned once, at create time).
2. On each incoming webhook delivery, compute `HMAC-SHA256(secret, raw_body)` and compare it in constant time against the `X-AxonFlow-Signature` header.
3. Reject any delivery whose signature does not match.

## Credit

Identified by AxonFlow internal security review during the April 2026 quality-freeze epic.
GitHub Security Advisory: GHSA-rwm7-x88c-3g2p
Package: io.netty:netty-transport-native-epoll (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-772: Missing Release of Resource after Effective Lifetime
Vulnerable versions: < 4.2.13.Final
Patched in: 4.2.13.Final

Summary: Netty epoll transport denial of service via RST on half-closed TCP connection

Details:
## Summary

Netty's epoll transport fails to detect and close TCP connections that receive a RST after being half-closed, leading to stale channels that are never cleaned up and, in some code paths, a 100% CPU busy-loop in the event loop thread.

## Affected versions

All versions of 4.2.x `netty-transport-native-epoll` up to and including 4.2.12.Final

## Fixed in

4.2.13.Final (fix merged into the `4.2` branch via [#16689](https://github.com/netty/netty/pull/16689); release not yet cut as of 2026-04-25).

## Severity

**Medium** — Denial of Service (resource exhaustion / CPU spin)

**CWE:** CWE-772: Missing Release of Resource after Effective Lifetime

## Description

When a TCP connection using Netty's epoll transport has `ALLOW_HALF_CLOSURE` enabled (or is in a half-closed state via the HTTP codec), and the remote peer:

1. Sends a FIN (half-close), causing the server to mark the input as shutdown, then
2. Sends a RST (e.g. by closing with `SO_LINGER=0`)

the server-side channel is never closed. This happens because:

- `epollOutReady()` is a no-op when there is no pending flush.
- `epollInReady()` short-circuits via `shouldBreakEpollInReady()` because input is already marked as shutdown.
- The `EPOLLERR`/`EPOLLHUP` error condition is therefore never processed, and `channelInactive` is never fired.

Depending on the Netty version and configuration, this results in:

- **Stale channels**: The connection is never closed or deregistered. An unauthenticated remote attacker can repeat the sequence to accumulate stale connections, exhausting file descriptors, memory, or connection-count limits.
- **CPU busy-loop**: In code paths where `clearEpollIn0()` is not called during the `ChannelInputShutdownReadComplete` event, `epoll_wait` returns immediately on every iteration for the affected fd, causing 100% CPU utilization on the event loop thread and starving all other connections multiplexed on it.

## Mitigation

- Upgrade to 4.2.13.Final when released (or build from the `4.2` branch at commit [`0ec3d97`](https://github.com/netty/netty/commit/0ec3d97fab376e243d328ac95fbd288ba0f6e22d)).
- If upgrading is not immediately possible, configure idle timeouts on connections to limit the lifetime of stale channels.

## Resources

- Issue: https://github.com/netty/netty/issues/16683
- Fix: https://github.com/netty/netty/pull/16689
GitHub Security Advisory: GHSA-jp6g-g3v3-6gvf
Package: org.jenkins-ci.plugins:azure-ad (MAVEN)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: <= 666.v6060de32f87d
Patched in: 667.v4c5827a

Summary: Jenkins Microsoft Entra ID (previously Azure AD) Plugin has an open redirect vulnerability

Details:
Jenkins Microsoft Entra ID (previously Azure AD) Plugin versions 666.v6060de32f87d and earlier do not restrict the redirect URL after login.

This allows attackers to perform phishing attacks by having users go to a Jenkins URL that will forward them to a different site after successful authentication.

Microsoft Entra ID (previously Azure AD) Plugin 667.v4c5827a_e74a_0 only redirects to relative (Jenkins) URLs.
GitHub Security Advisory: GHSA-f8h4-46xv-h7jj
Package: org.jenkins-ci.plugins:htmlpublisher (MAVEN)
Severity: HIGH (CVSS 8.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 427.1
Patched in: 427.1

Summary: Jenkins HTML Publisher Plugin has a XSS vulnerability in the legacy wrapper file

Details:
Jenkins HTML Publisher Plugin versoins 427 and earlier do not escape the job name and URL in the legacy wrapper file.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission.

HTML Publisher Plugin 427.1 escapes job name and URL when generating the legacy wrapper file.
GitHub Security Advisory: GHSA-w22p-4x9f-486v
Package: org.jenkins-ci.plugins:git (MAVEN)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.46.0.1
Patched in: 1.46.0.1

Summary: Jenkins GitHub Plugin has an XSS vulnerability

Details:
In Jenkins GitHub Plugin versions 1.46.0 and earlier, the JavaScript that validates the "GitHub hook trigger for GITScm polling" feature improperly processes the current job URL.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by non-anonymous attackers with Overall/Read permission.

GitHub Plugin 1.46.0.1 no longer processes the current job URL as part of JavaScript implementing validation of the feature "GitHub hook trigger for GITScm polling".
GitHub Security Advisory: GHSA-wg26-8wmj-cf9p
Package: org.jenkins-ci.plugins:github-branch-source (MAVEN)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 1967.1969.v205fd594c821
Patched in: 1967.1969.v205fd594c821

Summary: Jenkins GitHub Branch Source Plugin: Missing permissions check allows attackers to perform a connection test

Details:
Jenkins GitHub Branch Source Plugin versions 1967.vdea_d580c1a_b_a_ and earlier do not perform a permission check in a method implementing form validation.

This allows attackers with Overall/Read permission to connect to an attacker-specified URL with attacker-specified GitHub App credentials.

GitHub Branch Source Plugin 1967.1969.v205fd594c821 requires Overall/Manage permission to perform the connection test.
GitHub Security Advisory: GHSA-jp9r-mmhw-vff3
Package: org.jenkins-ci.plugins:matrix-auth (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.0-beta-1, <= 3.2.9
Patched in: 3.2.10

Summary: Jenkins Matrix Authorization Strategy Plugin: Unsafe deserialization allows invocation of parameterless constructors

Details:
Jenkins Matrix Authorization Strategy Plugin 2.0-beta-1 through 3.2.9 (both inclusive) invokes parameterless constructors of classes specified in configuration when deserializing inheritance strategies, without restricting the classes that can be instantiated.

This can be abused by attackers with Item/Configure permission to instantiate arbitrary types, which may lead to information disclosure or other impacts depending on the classes available on the classpath.

Matrix Authorization Strategy Plugin 3.2.10 verifies that the class being instantiated is an inheritance strategy implementation, preventing instantiation of arbitrary types.
GitHub Security Advisory: GHSA-p334-gfhq-c7w6
Package: org.jenkins-ci.plugins:script-security (MAVEN)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 1402.v94c9ce464861
Patched in: 1402.v94c9ce464861

Summary: Jenkins Script Security Plugin: Missing permission checks allow enumeration of pending and approved classpaths 

Details:
Jenkins Script Security Plugin versions 1399.ve6a_66547f6e1 and earlier do not perform a permission check in an HTTP endpoint.

This allows attackers with Overall/Read permission to enumerate pending and approved Script Security classpaths.

Script Security Plugin 1402.v94c9ce464861 requires Overall/Administer permission to enumerate pending and approved Script Security classpaths.
GitHub Security Advisory: GHSA-p2rf-wpxj-mx2g
Package: org.jenkins-ci.plugins:credentials-binding (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 720.v3f6decef43ea
Patched in: 720.v3f6decef43ea

Summary: Jenkins Credentials Binding Plugin has a path traversal vulnerability

Details:
Jenkins Credentials Binding Plugin versions 719.v80e905ef14eb_ and earlier do not sanitize file names for file and zip file credentials.

This allows attackers able to provide credentials to a job to write files to arbitrary locations on the node filesystem. If Jenkins is configured to allow a low-privileged user to configure file or zip file credentials used for a job running on the built-in node, this can lead to remote code execution.

Credentials Binding Plugin 720.v3f6decef43ea_ sanitizes the file name provided for file and zip file credentials, preventing path traversal.
GitHub Security Advisory: GHSA-6p4f-wcwh-5vvm
Package: org.springframework:spring-webmvc (MAVEN)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 5.3.47
Patched in: unpatched

Summary: Spring MVC and WebFlux applications are vulnerable to Denial of Service attacks when resolving static resources

Details:
Spring MVC and WebFlux applications are vulnerable to Denial of Service attacks when resolving static resources.


More precisely, an application can be vulnerable when all the following are true:

  *  the application is using Spring MVC or Spring WebFlux
  *  the application is serving static resources from the file system
  *  the application is running on a Windows platform


When all the conditions above are met, the attacker can send malicious requests that are slow to resolve and that can keep HTTP connections in use. This can cause a Denial of Service on the application.