=== What is the potential impact?

In the context of a web application vulnerable to regex injection: +
After discovering the injection point, attackers insert data into the
vulnerable field to make the affected component inaccessible.


Depending on the application's software architecture and the injection point's
location, the impact may or may not be visible.

Below are some real-world scenarios that illustrate some impacts of an attacker
exploiting the vulnerability.

==== Self Denial of Service

In cases where the complexity of the regular expression is exponential to the
input size, a small, carefully-crafted input (for example, 20 chars) can
trigger _catastrophic backtracking_ and cause a denial of service of the
application. 

Super-linear regex complexity can produce the same effects for a large,
carefully crafted input (thousands of chars).

If the component jeopardized by this vulnerability is not a bottleneck that
acts as a single point of failure (SPOF) within the application, the denial of
service might only affect the attacker who initiated it.

Such benign denial of service can also occur in architectures that rely heavily
on containers and container orchestrators. Replication systems would detect the
failure of a container and automatically replace it.

==== Infrastructure SPOFs

However, a denial of service attack can be critical to the enterprise if it
targets a SPOF component. Sometimes the SPOF is a software architecture
vulnerability (such as a single component on which multiple critical components
depend) or an operational vulnerability (for example, insufficient container
creation capabilities or failures from containers to terminate).

In either case, attackers aim to exploit the infrastructure weakness by sending
as many malicious payloads as possible, using potentially huge offensive
infrastructures.

These threats are particularly insidious if the attacked organization does not
maintain a disaster recovery plan (DRP).
