CyberAlerts is shutting down on June 30th, 2025. Thank you for your support!
Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
CVE-2025-32120 |
Description: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Erick Danzer Easy Query – WP Query Builder allows Blind SQL Injection. This issue affects Easy Query – WP Query Builder: from n/a through 2.0.4.
CVSS: HIGH (7.6) EPSS Score: 0.04%
April 4th, 2025 (3 months ago)
|
|
CVE-2025-32113 |
Description: Cross-Site Request Forgery (CSRF) vulnerability in Renzo Tejada Libro de Reclamaciones y Quejas allows Cross Site Request Forgery. This issue affects Libro de Reclamaciones y Quejas: from n/a through 0.9.
CVSS: HIGH (7.1) EPSS Score: 0.02%
April 4th, 2025 (3 months ago)
|
|
CVE-2025-32112 |
Description: Cross-Site Request Forgery (CSRF) vulnerability in OTWthemes Sidebar Manager Light allows Cross Site Request Forgery. This issue affects Sidebar Manager Light: from n/a through 1.1.8.
CVSS: HIGH (7.1) EPSS Score: 0.02%
April 4th, 2025 (3 months ago)
|
|
CVE-2025-25000 |
Description: Access of resource using incompatible type ('type confusion') in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.
CVSS: HIGH (8.8) EPSS Score: 0.14% SSVC Exploitation: none
April 4th, 2025 (3 months ago)
|
|
Description: Summary
CWE-470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') when having Javers selected as Entity Audit Framework
Details
In the following two occurences, user input directly leads to class loading without checking against e.g. a whitelist of allowed classes. This is also known as CWE-470
https://github.com/jhipster/generator-jhipster-entity-audit/blob/e21e83135d10c77d92203c89cb0b0063914e8fe0/generators/spring-boot-javers/templates/src/main/java/_package_/web/rest/JaversEntityAuditResource.java.ejs#L88
https://github.com/jhipster/generator-jhipster-entity-audit/blob/e21e83135d10c77d92203c89cb0b0063914e8fe0/generators/spring-boot-javers/templates/src/main/java/_package_/web/rest/JaversEntityAuditResource.java.ejs#L124
So, if an attacker manages to place some malicious classes into the classpath and also has access to these REST interface for calling the mentioned REST endpoints, using these lines of code can lead to unintended remote code execution.
PoC
Place an arbitrary class with the right package name (starting with JHIpster applications path name) and make it available in class path
Gain access to view entity's audit changelogs (Role: ADMIN)
pass in the malicious class name part as entityType (first mentioned part) // qualifiedName (second mentioned occurence)
class gets loaded and static code blocks in there get executed
--> Should be limited to the already existing whitelist of classes (see first method in that mentioned clas...
CVSS: HIGH (7.7) EPSS Score: 0.21%
April 4th, 2025 (3 months ago)
|
|
|
[github.com/minio/minio] MinIO performs incomplete signature validation for unsigned-trailer uploads
Description: Impact
This is a high priority vulnerability and users must upgrade ASAP.
The signature component of the authorization may be invalid, which would mean that as a client you can use any arbitrary secret to upload objects given the user already has prior WRITE permissions on the bucket,
Prior knowledge of access-key, and bucket name this user might have access to - and an access-key with a WRITE permissions is necessary.
However with relevant information in place, uploading random objects to buckets is trivial and easy via curl
Patches
Yes https://github.com/minio/minio/pull/21103
Workarounds
Reject requests with x-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER for now at LB layer, ask application users to use STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER
References
https://github.com/minio/minio/security/advisories/GHSA-wg47-6jq2-q2hh
https://nvd.nist.gov/vuln/detail/CVE-2025-31489
https://github.com/minio/minio/pull/21103
https://github.com/minio/minio/commit/8c70975283f9f4ce80f331a25c7475a36279e519
https://github.com/advisories/GHSA-wg47-6jq2-q2hh
CVSS: HIGH (8.7) EPSS Score: 1.47%
April 4th, 2025 (3 months ago)
|
|
|
Description: Summary
Using the Relay special node type you can bypass the configured security on an operation.
Details
Here is an example of how to apply security configurations for the GraphQL operations:
#[ApiResource(
security: "is_granted('ROLE_USER')",
operations: [ /* ... */ ],
graphQlOperations: [
new Query(security: "is_granted('ROLE_USER')"),
//...
],
)]
class Book { /* ... */ }
This indeed checks is_granted('ROLE_USER') as expected for a GraphQL query like the following:
query {
book(id: "/books/1") {
title
}
}
But the security check can be bypassed by using the node field (that is available by default) on the root query type like that:
query {
node(id: "/books/1") {
... on Book {
title
}
}
}
This does not execute any security checks and can therefore be used to access any entity without restrictions by everyone that has access to the API.
Impact
Everyone using GraphQl with the security attribute. Not sure whereas this works with custom resolvers nor if this also applies on mutation.
Patched at https://github.com/api-platform/core/commit/60747cc8c2fb855798c923b5537888f8d0969568
References
https://github.com/api-platform/core/security/advisories/GHSA-cg3c-245w-728m
https://nvd.nist.gov/vuln/detail/CVE-2025-31481
https://github.com/api-platform/core/commit/60747cc8c2fb855798c923b5537888f8d0969568
https://github.com/advisories/GHSA-cg3c-245w-728m
CVSS: HIGH (7.5) EPSS Score: 0.04%
April 4th, 2025 (3 months ago)
|
|
|
Description: Summary
Using the Relay special node type you can bypass the configured security on an operation.
Details
Here is an example of how to apply security configurations for the GraphQL operations:
#[ApiResource(
security: "is_granted('ROLE_USER')",
operations: [ /* ... */ ],
graphQlOperations: [
new Query(security: "is_granted('ROLE_USER')"),
//...
],
)]
class Book { /* ... */ }
This indeed checks is_granted('ROLE_USER') as expected for a GraphQL query like the following:
query {
book(id: "/books/1") {
title
}
}
But the security check can be bypassed by using the node field (that is available by default) on the root query type like that:
query {
node(id: "/books/1") {
... on Book {
title
}
}
}
This does not execute any security checks and can therefore be used to access any entity without restrictions by everyone that has access to the API.
Impact
Everyone using GraphQl with the security attribute. Not sure whereas this works with custom resolvers nor if this also applies on mutation.
Patched at https://github.com/api-platform/core/commit/60747cc8c2fb855798c923b5537888f8d0969568
References
https://github.com/api-platform/core/security/advisories/GHSA-cg3c-245w-728m
https://nvd.nist.gov/vuln/detail/CVE-2025-31481
https://github.com/api-platform/core/commit/60747cc8c2fb855798c923b5537888f8d0969568
https://github.com/advisories/GHSA-cg3c-245w-728m
CVSS: HIGH (7.5) EPSS Score: 0.04%
April 4th, 2025 (3 months ago)
|
|
|
Description: Original message:
I found an issue with security grants on on properties in the GraphQL ItemNormalizer:
If you use something like #[ApiProperty(security: 'is_granted("PROPERTY_READ", [object, property])')] on a member of an entity, the grant gets cached and is only evaluated once, even if the object in question is a different one.
There is the ApiPlatform\GraphQl\Serializer\ItemNormalizer::isCacheKeySafe() method that seems to be intended to prevent this: https://github.com/api-platform/core/blob/88f5ac50d20d6510686a7552310cc567fcca45bf/src/GraphQl/Serializer/ItemNormalizer.php#L160-L164and in its usage on line 90 it does indeed not create a cache key, but the parent::normalize() that is called afterwards still creates the cache key and causes the issue.
Impact
It grants access to properties that it should not.
Workarounds
Override the ItemNormalizer.
Patched at: https://github.com/api-platform/core/commit/7af65aad13037d7649348ee3dcd88e084ef771f8
References
https://github.com/api-platform/core/security/advisories/GHSA-428q-q3vv-3fq3
https://nvd.nist.gov/vuln/detail/CVE-2025-31485
https://github.com/api-platform/core/commit/7af65aad13037d7649348ee3dcd88e084ef771f8
https://github.com/advisories/GHSA-428q-q3vv-3fq3
CVSS: HIGH (7.5) EPSS Score: 0.04%
April 4th, 2025 (3 months ago)
|
|
|
Description: Original message:
I found an issue with security grants on on properties in the GraphQL ItemNormalizer:
If you use something like #[ApiProperty(security: 'is_granted("PROPERTY_READ", [object, property])')] on a member of an entity, the grant gets cached and is only evaluated once, even if the object in question is a different one.
There is the ApiPlatform\GraphQl\Serializer\ItemNormalizer::isCacheKeySafe() method that seems to be intended to prevent this: https://github.com/api-platform/core/blob/88f5ac50d20d6510686a7552310cc567fcca45bf/src/GraphQl/Serializer/ItemNormalizer.php#L160-L164and in its usage on line 90 it does indeed not create a cache key, but the parent::normalize() that is called afterwards still creates the cache key and causes the issue.
Impact
It grants access to properties that it should not.
Workarounds
Override the ItemNormalizer.
Patched at: https://github.com/api-platform/core/commit/7af65aad13037d7649348ee3dcd88e084ef771f8
References
https://github.com/api-platform/core/security/advisories/GHSA-428q-q3vv-3fq3
https://nvd.nist.gov/vuln/detail/CVE-2025-31485
https://github.com/api-platform/core/commit/7af65aad13037d7649348ee3dcd88e084ef771f8
https://github.com/advisories/GHSA-428q-q3vv-3fq3
CVSS: HIGH (7.5) EPSS Score: 0.04%
April 4th, 2025 (3 months ago)
|