The validate JSON endpoint of the Secvisogram csaf-validator-service in versions < 0.1.0 processes tests with unexpected names. This insufficient input validation of requests by an unauthenticated remote user might lead to a partial DoS of the service. Only the request of the attacker is affected by this vulnerability.

An high privileged attacker may pass crafted arguments to the validate function of csaf-validator-lib of a locally installed Secvisogram in versions < 0.1.0 wich can result in arbitrary code execution and DoS once the users triggers the validation.

A Regular Expression Denial of Service (ReDOS) vulnerability was discovered in scniro-validator v1.0.1 when validating crafted invalid emails.

FORT Validator versions prior to 1.5.2 will crash if an RPKI CA publishes an X.509 EE certificate. This will lead to RTR clients such as BGP routers to lose access to the RPKI VRP data set, effectively disabling Route Origin Validation.

validator.js is vulnerable to Inefficient Regular Expression Complexity

All versions of package djvalidator are vulnerable to Regular Expression Denial of Service (ReDoS) by sending crafted invalid emails - for example, --@------------------------------------------------------------------------------------------------------------------------!.

jpv (aka Json Pattern Validator) before 2.2.2 does not properly validate input, as demonstrated by a corrupted array.

In jpv (aka Json Pattern Validator) before 2.1.1, compareCommon() can be bypassed because certain internal attributes can be overwritten via a conflicting name, as demonstrated by 'constructor': {'name':'Array'}. This affects validate(). Hence, a crafted payload can overwrite this builtin attribute to manipulate the type detection result.

In TypeStack class-validator 0.10.2, validate() input validation can be bypassed because certain internal attributes can be overwritten via a conflicting name. Even though there is an optional forbidUnknownValues parameter that can be used to reduce the risk of this bypass, this option is not documented and thus most developers configure input validation in the vulnerable default manner. With this vulnerability, attackers can launch SQL Injection or XSS attacks by injecting arbitrary malicious input. NOTE: a software maintainer agrees with the "is not documented" finding but suggests that much of the responsibility for the risk lies in a different product.