deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-5rc6-9qfp-8vwg
Package: org.apache.camel:camel-consul (MAVEN)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.0.0, < 4.14.6
Patched in: 4.14.6

Summary: Apache Camel-Consul component vulnerable to Deserialization of Untrusted Data

Details:
The ConsulRegistry in the camel-consul component (class org.apache.camel.component.consul.ConsulRegistry and its inner ConsulRegistryUtils.deserialize method) read Java-serialized values from the Consul KV store and passed them to ObjectInputStream.readObject() without configuring an ObjectInputFilter. An attacker who can write to the Consul KV store backing a Camel ConsulRegistry instance could inject a malicious serialized Java object that is deserialized the next time Camel performs a lookup against that registry, leading to arbitrary code execution in the Camel process. The issue mirrors the class of vulnerability already addressed for other Camel components in CVE-2024-22369, CVE-2024-23114 and CVE-2026-25747, and was overlooked during the original remediation of those CVEs.

This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.1.

Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.1.
GitHub Security Advisory: GHSA-2vqf-x7g4-7c2g
Package: org.apache.camel:camel-mail (MAVEN)
Severity: CRITICAL (CVSS 9.4)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 4.15.0, < 4.18.1
Patched in: 4.18.1

Summary: Apache Camel's Camel-Mail component is vulnerable to Camel message header injection

Details:
The Camel-Mail component is vulnerable to Camel message header injection. The custom header filter strategy used by the component (MailHeaderFilterStrategy) only filters the 'out' direction via setOutFilterStartsWith, while it does not configure the 'in' direction via setInFilterStartsWith. As a result, when a Camel application consumes mail through camel-mail (for example via from(\"imap://...\") or from(\"pop3://...\")) the inbound filter check is skipped and Camel-prefixed MIME headers are mapped unfiltered into the Exchange. An attacker who can deliver an email to a mailbox monitored by such a consumer can inject Camel-specific headers that, for some Camel components downstream of the mail consumer (such as camel-bean, camel-exec, or camel-sql), can alter the behaviour of the route. This is the same pattern that was previously addressed in camel-undertow (CVE-2025-30177) and the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891).

This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.1.

Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.1. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6.
GitHub Security Advisory: GHSA-2vqf-x7g4-7c2g
Package: org.apache.camel:camel-mail (MAVEN)
Severity: CRITICAL (CVSS 9.4)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.0.0, < 4.14.6
Patched in: 4.14.6

Summary: Apache Camel's Camel-Mail component is vulnerable to Camel message header injection

Details:
The Camel-Mail component is vulnerable to Camel message header injection. The custom header filter strategy used by the component (MailHeaderFilterStrategy) only filters the 'out' direction via setOutFilterStartsWith, while it does not configure the 'in' direction via setInFilterStartsWith. As a result, when a Camel application consumes mail through camel-mail (for example via from(\"imap://...\") or from(\"pop3://...\")) the inbound filter check is skipped and Camel-prefixed MIME headers are mapped unfiltered into the Exchange. An attacker who can deliver an email to a mailbox monitored by such a consumer can inject Camel-specific headers that, for some Camel components downstream of the mail consumer (such as camel-bean, camel-exec, or camel-sql), can alter the behaviour of the route. This is the same pattern that was previously addressed in camel-undertow (CVE-2025-30177) and the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891).

This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.1.

Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.1. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6.
GitHub Security Advisory: GHSA-27vm-5vpj-rp5g
Package: org.apache.camel:camel-platform-http-main (MAVEN)
Severity: HIGH (CVSS 8.2)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: >= 4.19.0, < 4.20.0
Patched in: 4.20.0

Summary: Apache Camel Vulnerable to Authentication Bypass Using an Alternate Path or Channel

Details:
When authentication is enabled on the Apache Camel embedded HTTP server or embedded management server (camel-platform-http-main) and a non-root context path such as /api or /admin is configured via camel.server.path or camel.management.path, the BasicAuthenticationConfigurer and JWTAuthenticationConfigurer classes derive the authentication path from properties.getPath() when camel.server.authenticationPath / camel.management.authenticationPath is not explicitly set. Combined with the Vert.x sub-router mounting model - the sub-router is mounted at _path_* and the authentication handler is registered inside the sub-router at the resolved path - this causes the authentication handler to match only the exact configured context path, not its subpaths. Unauthenticated requests to subpaths such as /api/_route_ or /admin/observe/info therefore reach protected business routes and management endpoints without being challenged for credentials. The /observe/info endpoint can disclose runtime metadata such as the user, working directory, home directory, process ID, JVM and operating system information.

This issue affects Apache Camel: from 4.14.1 before 4.14.6, from 4.18.0 before 4.18.2.

Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, they are suggested to upgrade to 4.14.6. If users are on the 4.18.x LTS releases stream, they are suggested to upgrade to 4.18.2.
GitHub Security Advisory: GHSA-27vm-5vpj-rp5g
Package: org.apache.camel:camel-platform-http-main (MAVEN)
Severity: HIGH (CVSS 8.2)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: >= 4.18.0, < 4.18.2
Patched in: 4.18.2

Summary: Apache Camel Vulnerable to Authentication Bypass Using an Alternate Path or Channel

Details:
When authentication is enabled on the Apache Camel embedded HTTP server or embedded management server (camel-platform-http-main) and a non-root context path such as /api or /admin is configured via camel.server.path or camel.management.path, the BasicAuthenticationConfigurer and JWTAuthenticationConfigurer classes derive the authentication path from properties.getPath() when camel.server.authenticationPath / camel.management.authenticationPath is not explicitly set. Combined with the Vert.x sub-router mounting model - the sub-router is mounted at _path_* and the authentication handler is registered inside the sub-router at the resolved path - this causes the authentication handler to match only the exact configured context path, not its subpaths. Unauthenticated requests to subpaths such as /api/_route_ or /admin/observe/info therefore reach protected business routes and management endpoints without being challenged for credentials. The /observe/info endpoint can disclose runtime metadata such as the user, working directory, home directory, process ID, JVM and operating system information.

This issue affects Apache Camel: from 4.14.1 before 4.14.6, from 4.18.0 before 4.18.2.

Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, they are suggested to upgrade to 4.14.6. If users are on the 4.18.x LTS releases stream, they are suggested to upgrade to 4.18.2.
GitHub Security Advisory: GHSA-27vm-5vpj-rp5g
Package: org.apache.camel:camel-platform-http-main (MAVEN)
Severity: HIGH (CVSS 8.2)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: >= 4.14.1, < 4.14.6
Patched in: 4.14.6

Summary: Apache Camel Vulnerable to Authentication Bypass Using an Alternate Path or Channel

Details:
When authentication is enabled on the Apache Camel embedded HTTP server or embedded management server (camel-platform-http-main) and a non-root context path such as /api or /admin is configured via camel.server.path or camel.management.path, the BasicAuthenticationConfigurer and JWTAuthenticationConfigurer classes derive the authentication path from properties.getPath() when camel.server.authenticationPath / camel.management.authenticationPath is not explicitly set. Combined with the Vert.x sub-router mounting model - the sub-router is mounted at _path_* and the authentication handler is registered inside the sub-router at the resolved path - this causes the authentication handler to match only the exact configured context path, not its subpaths. Unauthenticated requests to subpaths such as /api/_route_ or /admin/observe/info therefore reach protected business routes and management endpoints without being challenged for credentials. The /observe/info endpoint can disclose runtime metadata such as the user, working directory, home directory, process ID, JVM and operating system information.

This issue affects Apache Camel: from 4.14.1 before 4.14.6, from 4.18.0 before 4.18.2.

Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, they are suggested to upgrade to 4.14.6. If users are on the 4.18.x LTS releases stream, they are suggested to upgrade to 4.18.2.
GitHub Security Advisory: GHSA-f2wh-grmh-r6jm
Package: org.apache.mina:mina-core (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.2.0, < 2.2.6
Patched in: 2.2.6

Summary: Apache MINA Vulnerable to Deserialization of Untrusted Data (CVE-2024-52046 Incomplete Fix)

Details:
The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed.

Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5.

The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by  applying the classname allowlist earlier.

Affected are applications using Apache MINA that call IoBuffer.getObject().

Applications using Apache MINA are advised to upgrade
GitHub Security Advisory: GHSA-f2wh-grmh-r6jm
Package: org.apache.mina:mina-core (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.1.0, < 2.1.11
Patched in: 2.1.11

Summary: Apache MINA Vulnerable to Deserialization of Untrusted Data (CVE-2024-52046 Incomplete Fix)

Details:
The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed.

Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5.

The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by  applying the classname allowlist earlier.

Affected are applications using Apache MINA that call IoBuffer.getObject().

Applications using Apache MINA are advised to upgrade
GitHub Security Advisory: GHSA-f2wh-grmh-r6jm
Package: org.apache.mina:mina-core (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.0.0, < 2.0.28
Patched in: 2.0.28

Summary: Apache MINA Vulnerable to Deserialization of Untrusted Data (CVE-2024-52046 Incomplete Fix)

Details:
The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed.

Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5.

The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by  applying the classname allowlist earlier.

Affected are applications using Apache MINA that call IoBuffer.getObject().

Applications using Apache MINA are advised to upgrade
GitHub Security Advisory: GHSA-vpr3-2659-rw55
Package: org.apache.camel:camel-mina (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 4.19.0, < 4.20.0
Patched in: 4.20.0

Summary: Camel-MINA Vulnerable to Deserialization of Untrusted Data

Details:
The camel-mina component's MinaConverter.toObjectInput(IoBuffer) type converter wraps an IoBuffer in a java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. When a Camel route uses camel-mina as a TCP or UDP consumer and requests conversion to ObjectInput (for example via getBody(ObjectInput.class) or @Body ObjectInput), an attacker sending a crafted serialized Java object over the network to the MINA consumer port can trigger arbitrary code execution in the context of the application during readObject().

This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0.

Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2.
GitHub Security Advisory: GHSA-vpr3-2659-rw55
Package: org.apache.camel:camel-mina (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 4.15.0, < 4.18.2
Patched in: 4.18.2

Summary: Camel-MINA Vulnerable to Deserialization of Untrusted Data

Details:
The camel-mina component's MinaConverter.toObjectInput(IoBuffer) type converter wraps an IoBuffer in a java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. When a Camel route uses camel-mina as a TCP or UDP consumer and requests conversion to ObjectInput (for example via getBody(ObjectInput.class) or @Body ObjectInput), an attacker sending a crafted serialized Java object over the network to the MINA consumer port can trigger arbitrary code execution in the context of the application during readObject().

This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0.

Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2.
GitHub Security Advisory: GHSA-vpr3-2659-rw55
Package: org.apache.camel:camel-mina (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.0.0, < 4.14.6
Patched in: 4.14.6

Summary: Camel-MINA Vulnerable to Deserialization of Untrusted Data

Details:
The camel-mina component's MinaConverter.toObjectInput(IoBuffer) type converter wraps an IoBuffer in a java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. When a Camel route uses camel-mina as a TCP or UDP consumer and requests conversion to ObjectInput (for example via getBody(ObjectInput.class) or @Body ObjectInput), an attacker sending a crafted serialized Java object over the network to the MINA consumer port can trigger arbitrary code execution in the context of the application during readObject().

This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0.

Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2.
GitHub Security Advisory: GHSA-v3vg-332r-mw99
Package: org.apache.camel:camel-pqc (MAVEN)
Severity: HIGH (CVSS 7.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 4.18.2
Patched in: 4.18.2

Summary: Camel-PQC Vulnerable to Deserialization of Untrusted Data

Details:
The Camel-PQC FileBasedKeyLifecycleManager class deserializes the contents of `<keyId>.key` files in the configured key directory using java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. The cast to `java.security.KeyPair` is evaluated only after `readObject()` has already returned, so any `readObject()` side effects in the deserialized object run before the type check. An attacker who can write to the key directory used by a Camel application — for example through a path traversal into the directory, misconfigured filesystem permissions on the volume where keys are stored, a compromised key provisioning pipeline, or a symlink attack — can place a crafted serialized Java object that, when deserialized during normal key lifecycle operations, results in arbitrary code execution in the context of the application.

This issue affects Apache Camel: from 4.19.0 before 4.20.0, from 4.18.0 before 4.18.2.

Users are recommended to upgrade to version 4.20.0, which fixes the issue by replacing java.io.ObjectInputStream-based key and metadata storage with standard PKCS#8 (private key) / X.509 SubjectPublicKeyInfo (public key) Base64 JSON encoding. For users on the 4.18.x LTS releases stream, upgrade to 4.18.2.
GitHub Security Advisory: GHSA-6rmm-pg23-5f8q
Package: com.baomidou:dynamic-datasource-spring (MAVEN)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: <= 4.5.0
Patched in: unpatched

Summary: Dynamic-Datasource has an Injection vulnerability

Details:
A vulnerability was determined in baomidou dynamic-datasource 2.5.0. Affected by this vulnerability is the function DsSpelExpressionProcessor#doDetermineDatasource of the file dynamic-datasource-spring/src/main/java/com/baomidou/dynamic/datasource/processor/DsSpelExpressionProcessor.java of the component StandardEvaluationContext/SpelExpressionParser. This manipulation causes injection. The attack may be initiated remotely. Patch name: 273fcedaee984c08197c0890f14190b86ab7e0b8. It is recommended to apply a patch to fix this issue.
GitHub Security Advisory: GHSA-xcfg-fcr5-gw9r
Package: org.geysermc.geyser:core (MAVEN)
Severity: LOW (CVSS 2.4)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 2.9.2
Patched in: 2.9.3

Summary: Geyser Vulnerable to Server-Side Request Forgery (SSRF) via Player Head Texture URL in Geyser

Details:
### Summary
A server-side request forgery (SSRF) vulnerability exists in Geyser’s handling of Bedrock player head texture data.
By supplying a crafted Base64-encoded skin texture URL via the /give command, an attacker can cause the Minecraft server to issue arbitrary HTTP GET requests to attacker-controlled or internal endpoints.
This occurs server-side, without proper URL validation, and can be triggered by a Bedrock client.

### Details
Geyser allows Bedrock clients to interact with Java Edition mechanics, including the creation of custom player heads using the minecraft:profile NBT structure.

When a player head is created with a custom textures property, Geyser processes the Base64-encoded JSON value and forwards the embedded texture URL for resolution.
However, the URL contained in the textures.SKIN.url field is not sufficiently validated.
### PoC

1. **Setup Environment:**
   - Set up a Minecraft Server (Paper/Spigot) with the latest version of Geyser installed.
   - Ensure you have a Bedrock client connected.

2. **Prepare Listener:**
   - Go to [webhook.site](https://webhook.site) and obtain a unique URL (e.g., `https://webhook.site/YOUR-UUID`).

3. **Construct Payload:**
   - Create a JSON payload pointing to your listener URL:
     `{"textures":{"SKIN":{"url":"https://webhook.site/YOUR-UUID"}}}`
   - Encode this JSON string to Base64.
     *(You can use a terminal command: `echo -n '{"textures":{"SKIN":{"url":"..."}}}' | base64`)*

4. **Execute Command:**
   - Run the following command in the Bedrock Edition client:
   `/give @p minecraft:player_head[minecraft:profile={properties:[{name:"textures",value:"[PASTE_BASE64_HERE]"}]}]`

5. **Verify:**
   - Check the webhook.site dashboard.
   - You will see an **HTTP GET request originating from the Minecraft Server's IP address**, not the client's IP.

### Impact
This vulnerability allows server-side request forgery (SSRF) from the Minecraft server to arbitrary HTTP endpoints.

#### Affected Parties
- Minecraft servers running Geyser
- Server operators exposing internal or cloud metadata endpoints

#### Potential Impacts
- Internal network probing (e.g., intranet services, admin panels)
- Cloud metadata access attempts (e.g., 169.254.169.254)
- IP address disclosure of the Minecraft server
- Abuse of the server as an HTTP request proxy

Although the vulnerability is blind SSRF (no response data returned to the attacker), it is still useful for:
- Network mapping
- Firewall bypass attempts
- Cloud environment fingerprinting
GitHub Security Advisory: GHSA-42fc-7w97-8vrc
Package: org.xwiki.contrib.plantuml:macro-plantuml-macro (MAVEN)
Severity: MODERATE (CVSS 4.4)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 2.4.1
Patched in: 2.4.1

Summary: XWiki PlantUML Macro Vulnerable to Server-Side Request Forgery (SSRF) via 'server' parameter

Details:
### Impact

The [PlantUML Macro](https://extensions.xwiki.org/xwiki/bin/view/Extension/PlantUML+Macro) is vulnerable to Server-Side Request Forgery (SSRF). The macro allows users to specify an alternative PlantUML server via the `server` parameter. However, the application does not validate the supplied URL. An attacker can supply an internal IP address or a malicious external URL. The XWiki server will attempt to connect to this URL to "render" the diagram.

This issue affects all versions of the Plant UML Macro extension till version 2.4 included.

### Patches

Version 2.4.1 of the Plant UML Macro extension fixes the issue by verifying if the supplied server domain matches one of the [trusted domain configured inside of XWiki](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Configuration/#HTrusteddomains).

### Workarounds

Protect the XWiki server by placing it in a DMZ so that it cannot access any other internal servers.

### Resources

The issue was fixed in [PLANTUML-25](https://jira.xwiki.org/browse/PLANTUML-25) by the commit [c8b19bda93058794e04c8862fc7ca85c59b5fe5c](https://github.com/xwiki-contrib/macro-plantuml/commit/c8b19bda93058794e04c8862fc7ca85c59b5fe5c).

### For more information

If there are any questions or comments about this advisory:
* Open an issue in [JIRA XWiki.org](https://jira.xwiki.org/)
* Send an email to [Security Mailing List](mailto:security@xwiki.org)

### Attribution

The issue was reported by Łukasz Rybak.