deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-w3w2-mpp5-92gm
Package: org.apache.activemq:activemq-all (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-20: Improper Input Validation, CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 5.19.6
Patched in: 5.19.6

Summary: Apache ActiveMQ Vulnerable to Improper Input Validation and Code Injection

Details:
Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ.



An authenticated attacker may bypass the fix in CVE-2026-34197 by adding a connector using an HTTP Discovery transport via BrokerView.addNetworkConnector or BrokerView.addConnector through Jolokia if the activemq-http module is on the classpath.
A malicious HTTP endpoint can return a VM transport through the HTTP URI which will bypass the validation added in CVE-2026-34197. The attacker can then use the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext.
Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec().


This issue affects Apache ActiveMQ Broker: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ All: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ: before 5.19.6, from 6.0.0 before 6.2.5.

Users are recommended to upgrade to version 5.19.6 or 6.2.5, which fixes the issue.
GitHub Security Advisory: GHSA-w3w2-mpp5-92gm
Package: org.apache.activemq:apache-activemq (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-20: Improper Input Validation, CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 5.19.6
Patched in: 5.19.6

Summary: Apache ActiveMQ Vulnerable to Improper Input Validation and Code Injection

Details:
Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ.



An authenticated attacker may bypass the fix in CVE-2026-34197 by adding a connector using an HTTP Discovery transport via BrokerView.addNetworkConnector or BrokerView.addConnector through Jolokia if the activemq-http module is on the classpath.
A malicious HTTP endpoint can return a VM transport through the HTTP URI which will bypass the validation added in CVE-2026-34197. The attacker can then use the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext.
Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec().


This issue affects Apache ActiveMQ Broker: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ All: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ: before 5.19.6, from 6.0.0 before 6.2.5.

Users are recommended to upgrade to version 5.19.6 or 6.2.5, which fixes the issue.
GitHub Security Advisory: GHSA-f786-9c63-8xr8
Package: org.apache.dolphinscheduler:dolphinscheduler-rpc (MAVEN)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.2.0, < 3.3.1
Patched in: 3.3.1

Summary: Apache DolphinScheduler RPC module has a Deserialization of Untrusted Data vulnerability

Details:
Deserialization of Untrusted Data vulnerability in Apache DolphinScheduler RPC module.

This issue affects Apache DolphinScheduler: 

Version >= 3.2.0 and < 3.3.1.

Attackers who can access the Master or Worker nodes can compromise the system by creating a StandardRpcRequest, injecting a malicious class type into it, and sending RPC requests to the DolphinScheduler Master/Worker nodes.
Users are recommended to upgrade to version [3.3.1], which fixes the issue.
GitHub Security Advisory: GHSA-f786-9c63-8xr8
Package: org.apache.dolphinscheduler:dolphinscheduler (MAVEN)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.2.0, < 3.3.1
Patched in: 3.3.1

Summary: Apache DolphinScheduler RPC module has a Deserialization of Untrusted Data vulnerability

Details:
Deserialization of Untrusted Data vulnerability in Apache DolphinScheduler RPC module.

This issue affects Apache DolphinScheduler: 

Version >= 3.2.0 and < 3.3.1.

Attackers who can access the Master or Worker nodes can compromise the system by creating a StandardRpcRequest, injecting a malicious class type into it, and sending RPC requests to the DolphinScheduler Master/Worker nodes.
Users are recommended to upgrade to version [3.3.1], which fixes the issue.
GitHub Security Advisory: GHSA-qww7-89xh-x7m7
Package: org.xwiki.platform:xwiki-platform-webjars (MAVEN)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-23: Relative Path Traversal
Vulnerable versions: >= 6.1-miletone-2, <= 7.1.3
Patched in: unpatched

Summary: XWiki configuration files can be accessed through the webjars API

Details:
### Impact

It's possible to get access and read configuration files by using URLs such as http://localhost:8080/xwiki/webjars/wiki%3Axwiki/..%2F..%2F..%2F..%2F..%2FWEB-INF%2Fxwiki.cfg. The trick here is to encode the / which is decoded when parsing the URL segment, but not re-encoded when assembling the file path.

### Patches

This has been patched in 17.4.0-rc-1, 16.10.7.

### Workarounds

There is no known workaround, other than upgrading XWiki.

### References

* https://jira.xwiki.org/browse/XWIKI-19350
* https://github.com/xwiki/xwiki-platform/commit/9e7b4c03f2143978d891109a17159f73d4cdd318#diff-45ea9c87d5fb68cd5db0da7f78cf25e76f1325f5fe56e21618b21786fc706236R80-R81

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)
* Email us at [Security Mailing List](mailto:security@xwiki.org)
GitHub Security Advisory: GHSA-qww7-89xh-x7m7
Package: org.xwiki.platform:xwiki-platform-webjars-api (MAVEN)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-23: Relative Path Traversal
Vulnerable versions: >= 17.0.0-rc-1, < 17.4.0-rc-1
Patched in: 17.4.0-rc-1

Summary: XWiki configuration files can be accessed through the webjars API

Details:
### Impact

It's possible to get access and read configuration files by using URLs such as http://localhost:8080/xwiki/webjars/wiki%3Axwiki/..%2F..%2F..%2F..%2F..%2FWEB-INF%2Fxwiki.cfg. The trick here is to encode the / which is decoded when parsing the URL segment, but not re-encoded when assembling the file path.

### Patches

This has been patched in 17.4.0-rc-1, 16.10.7.

### Workarounds

There is no known workaround, other than upgrading XWiki.

### References

* https://jira.xwiki.org/browse/XWIKI-19350
* https://github.com/xwiki/xwiki-platform/commit/9e7b4c03f2143978d891109a17159f73d4cdd318#diff-45ea9c87d5fb68cd5db0da7f78cf25e76f1325f5fe56e21618b21786fc706236R80-R81

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)
* Email us at [Security Mailing List](mailto:security@xwiki.org)
GitHub Security Advisory: GHSA-qww7-89xh-x7m7
Package: org.xwiki.platform:xwiki-platform-webjars-api (MAVEN)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-23: Relative Path Traversal
Vulnerable versions: >= 7.1.4, < 16.10.7
Patched in: 16.10.7

Summary: XWiki configuration files can be accessed through the webjars API

Details:
### Impact

It's possible to get access and read configuration files by using URLs such as http://localhost:8080/xwiki/webjars/wiki%3Axwiki/..%2F..%2F..%2F..%2F..%2FWEB-INF%2Fxwiki.cfg. The trick here is to encode the / which is decoded when parsing the URL segment, but not re-encoded when assembling the file path.

### Patches

This has been patched in 17.4.0-rc-1, 16.10.7.

### Workarounds

There is no known workaround, other than upgrading XWiki.

### References

* https://jira.xwiki.org/browse/XWIKI-19350
* https://github.com/xwiki/xwiki-platform/commit/9e7b4c03f2143978d891109a17159f73d4cdd318#diff-45ea9c87d5fb68cd5db0da7f78cf25e76f1325f5fe56e21618b21786fc706236R80-R81

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)
* Email us at [Security Mailing List](mailto:security@xwiki.org)
GitHub Security Advisory: GHSA-c9ph-gxww-7744
Package: org.thymeleaf:thymeleaf-spring6 (MAVEN)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: <= 3.1.4.RELEASE
Patched in: 3.1.5.RELEASE

Summary: Sandboxed Thymeleaf expressions vulnerable to improper recognition of unauthorized syntax patterns

Details:
### Impact

A security bypass vulnerability exists in the expression execution mechanisms of Thymeleaf up to and including 3.1.4.RELEASE. Although the library provides mechanisms to avoid the execution of potentially dangerous expressions in some specific sandboxed (restricted) contexts, it fails to properly neutralize specific constructs that allow this kind of expressions to be executed. If an application developer passes to the template engine unsanitized variables that contain such expressions, and these values are used in sandboxed contexts inside the templates, these expressions can be executed achieving Server-Side Template Injection (SSTI).

### Patches

This has been fixed in Thymeleaf 3.1.5.RELEASE. All users are advised to upgrade immediately.

### Workarounds

No workaround is available beyond ensuring applications do not pass unvalidated/unsanitized data directly to the template engine. Upgrading to 3.1.5.RELEASE is strongly recommended in any case.
GitHub Security Advisory: GHSA-c9ph-gxww-7744
Package: org.thymeleaf:thymeleaf-spring5 (MAVEN)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: <= 3.1.4.RELEASE
Patched in: 3.1.5.RELEASE

Summary: Sandboxed Thymeleaf expressions vulnerable to improper recognition of unauthorized syntax patterns

Details:
### Impact

A security bypass vulnerability exists in the expression execution mechanisms of Thymeleaf up to and including 3.1.4.RELEASE. Although the library provides mechanisms to avoid the execution of potentially dangerous expressions in some specific sandboxed (restricted) contexts, it fails to properly neutralize specific constructs that allow this kind of expressions to be executed. If an application developer passes to the template engine unsanitized variables that contain such expressions, and these values are used in sandboxed contexts inside the templates, these expressions can be executed achieving Server-Side Template Injection (SSTI).

### Patches

This has been fixed in Thymeleaf 3.1.5.RELEASE. All users are advised to upgrade immediately.

### Workarounds

No workaround is available beyond ensuring applications do not pass unvalidated/unsanitized data directly to the template engine. Upgrading to 3.1.5.RELEASE is strongly recommended in any case.
GitHub Security Advisory: GHSA-c9ph-gxww-7744
Package: org.thymeleaf:thymeleaf (MAVEN)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: <= 3.1.4.RELEASE
Patched in: 3.1.5.RELEASE

Summary: Sandboxed Thymeleaf expressions vulnerable to improper recognition of unauthorized syntax patterns

Details:
### Impact

A security bypass vulnerability exists in the expression execution mechanisms of Thymeleaf up to and including 3.1.4.RELEASE. Although the library provides mechanisms to avoid the execution of potentially dangerous expressions in some specific sandboxed (restricted) contexts, it fails to properly neutralize specific constructs that allow this kind of expressions to be executed. If an application developer passes to the template engine unsanitized variables that contain such expressions, and these values are used in sandboxed contexts inside the templates, these expressions can be executed achieving Server-Side Template Injection (SSTI).

### Patches

This has been fixed in Thymeleaf 3.1.5.RELEASE. All users are advised to upgrade immediately.

### Workarounds

No workaround is available beyond ensuring applications do not pass unvalidated/unsanitized data directly to the template engine. Upgrading to 3.1.5.RELEASE is strongly recommended in any case.
GitHub Security Advisory: GHSA-qmcv-hh7c-3m56
Package: ai.h2o:h2o-core (MAVEN)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 3.46.0.10
Patched in: 3.46.0.10

Summary: H2O-3 is Vulnerable to Code Injection

Details:
A critical remote code execution vulnerability exists in the unauthenticated REST API endpoint /99/ImportSQLTable in H2O-3 version 3.46.0.9 and prior. The vulnerability arises due to insufficient security controls in the parameter blacklist mechanism, which only targets MySQL JDBC driver-specific dangerous parameters. An attacker can bypass these controls by switching the JDBC URL protocol to jdbc:postgresql: and exploiting PostgreSQL JDBC driver-specific parameters such as socketFactory and socketFactoryArg. This allows unauthenticated attackers to execute arbitrary code on the H2O-3 server with the privileges of the H2O-3 process. The issue is resolved in version 3.46.0.10.
GitHub Security Advisory: GHSA-xj4f-8jjg-vx4q
Package: org.openmrs.api:openmrs-api (MAVEN)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 2.8.0, < 2.8.6
Patched in: 2.8.6

Summary: OpenMRS has Stored Velocity SSTI to RCE via ConceptReferenceRange

Details:
### Impact

The `ConceptReferenceRangeUtility.evaluateCriteria()` method in OpenMRS Core
evaluates database-stored criteria strings as Apache Velocity templates without any sandbox configuration. The `VelocityEngine` is initialized with only logging properties and no`SecureUberspector`, leaving the default `UberspectImpl` in place, which allows
unrestricted Java reflection through template expressions.

A user with the `Manage Concepts` privilege can store a malicious Velocity template
expression in a concept's reference range criteria field. This payload is then executed
automatically whenever a user or API call validates an observation against the affected
concept. The Velocity context exposes `$patient` (the `Person` / `Patient` object), `$obs` (the `Obs` object), and `$fn` (the `ConceptReferenceRangeUtility` instance with access to the full OpenMRS service layer).

**Persistent Remote Code Execution**: The payload persists in the concept_reference_range database table (VARCHAR 65535). A single compromised concept for a common clinical measurement executes the payload on every subsequent observation validation across all users, API clients, and integrations in the facility.

**Privilege Escalation**: The Manage Concepts privilege is a content-management function, defined as "Able to add/edit/delete concept entries", not an administrative privilege. Multiple non-admin staff per facility typically hold this privilege. The attacker escalates from concept dictionary management to arbitrary code execution as the Tomcat application server process.

**PHI Exfiltration**: The Velocity context objects directly expose patient data without requiring OS-level RCE.

### Patches

This is fixed in 2.8.6 and 2.7.9 as well as future versions.

### Workarounds

Ensure the `Manage Concepts` privilege is restricted to only authorized users and carefully audit any `ConceptReferenceRanges` in the database.

### Resources
https://github.com/openmrs/openmrs-core/commit/8d1c193
https://www.machinespirits.com/advisory/1e8430/
GitHub Security Advisory: GHSA-xj4f-8jjg-vx4q
Package: org.openmrs.api:openmrs-api (MAVEN)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 2.7.0, < 2.7.9
Patched in: 2.7.9

Summary: OpenMRS has Stored Velocity SSTI to RCE via ConceptReferenceRange

Details:
### Impact

The `ConceptReferenceRangeUtility.evaluateCriteria()` method in OpenMRS Core
evaluates database-stored criteria strings as Apache Velocity templates without any sandbox configuration. The `VelocityEngine` is initialized with only logging properties and no`SecureUberspector`, leaving the default `UberspectImpl` in place, which allows
unrestricted Java reflection through template expressions.

A user with the `Manage Concepts` privilege can store a malicious Velocity template
expression in a concept's reference range criteria field. This payload is then executed
automatically whenever a user or API call validates an observation against the affected
concept. The Velocity context exposes `$patient` (the `Person` / `Patient` object), `$obs` (the `Obs` object), and `$fn` (the `ConceptReferenceRangeUtility` instance with access to the full OpenMRS service layer).

**Persistent Remote Code Execution**: The payload persists in the concept_reference_range database table (VARCHAR 65535). A single compromised concept for a common clinical measurement executes the payload on every subsequent observation validation across all users, API clients, and integrations in the facility.

**Privilege Escalation**: The Manage Concepts privilege is a content-management function, defined as "Able to add/edit/delete concept entries", not an administrative privilege. Multiple non-admin staff per facility typically hold this privilege. The attacker escalates from concept dictionary management to arbitrary code execution as the Tomcat application server process.

**PHI Exfiltration**: The Velocity context objects directly expose patient data without requiring OS-level RCE.

### Patches

This is fixed in 2.8.6 and 2.7.9 as well as future versions.

### Workarounds

Ensure the `Manage Concepts` privilege is restricted to only authorized users and carefully audit any `ConceptReferenceRanges` in the database.

### Resources
https://github.com/openmrs/openmrs-core/commit/8d1c193
https://www.machinespirits.com/advisory/1e8430/
GitHub Security Advisory: GHSA-rc95-pcm8-65v9
Package: io.quarkus:quarkus-vertx-http (MAVEN)
Severity: HIGH (CVSS 8.2)
CWE: CWE-287: Improper Authentication, CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.34.0, < 3.35.1.1
Patched in: 3.35.1.1

Summary: Quarkus has Authentication/Authorization bypasses

Details:
Quarkus version 3.32.4 is vulnerable to an authorization bypass issue (GHSL-2026-099), in which semicolons (matrix parameters) in HTTP requests can be used to bypass security constraints, potentially allowing unauthorized access to protected resources.

Unauthenticated or lower-privileged users can bypass HTTP path-based authorization policies by appending a semicolon (`;`) and arbitrary text to the request URL. The vulnerability arises from a path-normalization inconsistency: Quarkus's [security layer](https://quarkus.io/guides/security-authorize-web-endpoints-reference) performs authorization checks on the raw URL path (which preserves matrix parameters), whereas RESTEasy Reactive's routing layer strips matrix parameters before matching endpoints. This allows requests like `/api/admin;anything` to bypass policies protecting `/api/admin` while still routing to the protected endpoint.


### Impact

This issue may lead to Authentication/Authorization bypasses.

### Credits

This issue was discovered with the [GitHub Security Lab Taskflow Agent](https://github.com/GitHubSecurityLab/seclab-taskflow-agent) and manually verified by GHSL team members [@p- (Peter Stöckli)](https://github.com/p-) and [@m-y-mo (Man Yue Mo)](https://github.com/m-y-mo).
GitHub Security Advisory: GHSA-rc95-pcm8-65v9
Package: io.quarkus:quarkus-vertx-http (MAVEN)
Severity: HIGH (CVSS 8.2)
CWE: CWE-287: Improper Authentication, CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.30.0, < 3.33.1.1
Patched in: 3.33.1.1

Summary: Quarkus has Authentication/Authorization bypasses

Details:
Quarkus version 3.32.4 is vulnerable to an authorization bypass issue (GHSL-2026-099), in which semicolons (matrix parameters) in HTTP requests can be used to bypass security constraints, potentially allowing unauthorized access to protected resources.

Unauthenticated or lower-privileged users can bypass HTTP path-based authorization policies by appending a semicolon (`;`) and arbitrary text to the request URL. The vulnerability arises from a path-normalization inconsistency: Quarkus's [security layer](https://quarkus.io/guides/security-authorize-web-endpoints-reference) performs authorization checks on the raw URL path (which preserves matrix parameters), whereas RESTEasy Reactive's routing layer strips matrix parameters before matching endpoints. This allows requests like `/api/admin;anything` to bypass policies protecting `/api/admin` while still routing to the protected endpoint.


### Impact

This issue may lead to Authentication/Authorization bypasses.

### Credits

This issue was discovered with the [GitHub Security Lab Taskflow Agent](https://github.com/GitHubSecurityLab/seclab-taskflow-agent) and manually verified by GHSL team members [@p- (Peter Stöckli)](https://github.com/p-) and [@m-y-mo (Man Yue Mo)](https://github.com/m-y-mo).
GitHub Security Advisory: GHSA-rc95-pcm8-65v9
Package: io.quarkus:quarkus-vertx-http (MAVEN)
Severity: HIGH (CVSS 8.2)
CWE: CWE-287: Improper Authentication, CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.21.0, < 3.27.3.1
Patched in: 3.27.3.1

Summary: Quarkus has Authentication/Authorization bypasses

Details:
Quarkus version 3.32.4 is vulnerable to an authorization bypass issue (GHSL-2026-099), in which semicolons (matrix parameters) in HTTP requests can be used to bypass security constraints, potentially allowing unauthorized access to protected resources.

Unauthenticated or lower-privileged users can bypass HTTP path-based authorization policies by appending a semicolon (`;`) and arbitrary text to the request URL. The vulnerability arises from a path-normalization inconsistency: Quarkus's [security layer](https://quarkus.io/guides/security-authorize-web-endpoints-reference) performs authorization checks on the raw URL path (which preserves matrix parameters), whereas RESTEasy Reactive's routing layer strips matrix parameters before matching endpoints. This allows requests like `/api/admin;anything` to bypass policies protecting `/api/admin` while still routing to the protected endpoint.


### Impact

This issue may lead to Authentication/Authorization bypasses.

### Credits

This issue was discovered with the [GitHub Security Lab Taskflow Agent](https://github.com/GitHubSecurityLab/seclab-taskflow-agent) and manually verified by GHSL team members [@p- (Peter Stöckli)](https://github.com/p-) and [@m-y-mo (Man Yue Mo)](https://github.com/m-y-mo).