When a new zero-day or critical CVE is published, the real problem an organization faces is rarely that the vulnerability is unknown — it is how quickly the application can be patched. Legacy applications, end-of-support versions, brittle dependencies and vendor-locked software all make direct code patching difficult.
An official patch may take days or weeks to arrive. Even when a patch ships, deploying it to production is a separate process: regression testing, change window, approval chain, rollback plan and service downtime risk. When an active attack wave begins, these processes are not fast enough for a security team.
With cloud-based or externally dependent WAAP signature feeds, organizations cannot always control when a critical CVE signature will arrive or how customizable it will be. This is especially important in on-premises, air-gapped or sovereign cloud architectures where security response needs to be performed internally.
Virtual patching applied incorrectly creates new problems. Overly broad regex rules can break legitimate user traffic, incorrect scope selection can affect unrelated applications, and a rule placed directly into blocking mode can create false positives in production. Fast response therefore requires controlled testing and rollback capability — not just speed.
TR7's virtual patching approach narrows the attack surface at the traffic layer until application code is ready — doing so through monitor mode, score control, scope selection and hot-reload without introducing operational risk.
TR7 treats virtual patching not as a one-off emergency rule but as a testable, manageable security lifecycle.
Pre-built signatures for critical vulnerabilities such as Log4Shell, Spring4Shell and Shellshock are available in the WAAP database. Separate patterns cover multiple variants and encoded attack forms.
Operators write a regex, choose the match field, assign a score and set the rule state. Rules can be applied to different traffic fields including path, query, header, form, json, xml or raw body.
Every custom rule is stored with a date stamp. This record makes it easy to see when a temporary patch was added and to clean up after a permanent application fix is in place.
A rule in `monitor` state generates logs without blocking traffic. After the security team observes false-positive impact, the same rule can be moved to `enabled` to activate blocking.
TR7 Virtual Patching combines pre-built CVE signatures, custom rule creation and controlled activation in a single policy pipeline.
The TR7 WAAP database includes pre-built signatures for critical vulnerabilities such as Log4Shell, Spring4Shell and Shellshock. On the Log4Shell side, base JNDI patterns, encoded variants and obfuscation attempts can each be addressed with separate patterns. This structure reduces the need to write rules from scratch for known high-risk attacks. Organizations can activate a pre-built signature in monitor or blocking mode for fast response.
A custom regex rule can be defined for an organization-specific vulnerability, a CMS plugin flaw or a penetration test finding. The rule can be applied to different match fields including path, query, header, form, json, xml or raw body. This allows the security team to intercept the attack pattern at the traffic layer without changing application code. The approach creates a fast protection layer until the permanent patch is available.
A newly added rule in `monitor` state generates only logs and does not block user traffic. The security team can observe which requests the rule matches, whether it produces false positives and what its score impact is. When the result is safe, the rule is moved to `enabled` state. This flow balances emergency response speed with production safety.
Custom rules can be assigned scores such as 2, 4, 6 or 8. A high score is used for direct blocking scenarios; a lower score contributes to a combined risk threshold decision. This structure allows each virtual patch to be tuned to attack certainty and business impact rather than applying the same severity to every rule. Operators can build both precise and aggressive policies.
A virtual patch can be applied globally to all service pools or bound to a specific pool only. The global layer provides fast coverage for widespread CVE attacks while pool level offers more controlled scope for specific application vulnerabilities. This ensures a single CMS vulnerability does not unnecessarily harden the entire platform policy. Rule scope can be narrowed to match application risk.
An existing rule's state can be changed to `enabled`, `disabled` or `monitor`. Similarly, the score value can be increased or decreased to adjust the rule's weight in the decision process. This feature is used to temporarily place a known signature into monitor mode or apply it more aggressively in an emergency. Organization policy can be fine-tuned against real traffic behavior.
When a new virtual patch is added, the changed regex content is processed, relevant hash structures are updated and only the affected segment is recompiled. This process targets rule activation without restarting the entire proxy layer. The compilation operation runs within controlled resource limits. Security teams can apply emergency patches without making them dependent on a maintenance window.
Specific attack examples from a pre-built attack dictionary can be replayed within the TR7 test framework. The `Attack.js` tool allows selecting a target host and port and running specific attack IDs. This method verifies practically whether the virtual patch catches the expected attack pattern. Operations teams can see the behavior concretely before taking the rule to production.
Virtual patching requires rule traceability, rollback, scope control and test discipline as much as fast emergency response.
Global custom rules and pool-level custom rules are held in separate ID ranges. Global rules are in the 1M–5M range, pool rules in the 5M–10M range. This separation makes the scope a rule affects operationally more visible.
Custom rules are stored with a date stamp in `DD.MM.YYYY` format. This field is important for preventing temporary patches from being forgotten. When the permanent application fix is complete, related virtual patches can be cleaned up in bulk.
When new regex content is processed, the relevant hash values are recalculated and the changed segment is recompiled. The process runs within resource limits and ensures the affected security pipeline is updated. Emergency rule additions do not require broad service interruption.
A pre-built attack dictionary assists with rule validation using known attack examples. Operators can run specific attack IDs and observe whether the rule logs or blocks. This test reduces false-positive and false-negative risk especially for new regex rules.
Virtual patches should be treated as temporary security controls. When the application is permanently fixed, related custom rules can be disabled or deleted in bulk. Without this discipline, old emergency rules accumulate over time, creating policy confusion and unnecessary blocking risk.
Rule name, description, date, state, score and match fields produce meaningful records from an audit perspective. Security teams can show which temporary control was added for a specific CVE or penetration test finding and when it was applied. This is particularly useful in compliance processes for demonstrating the chain: vulnerability detected, control applied, permanent patch pending.
When Log4Shell risk is detected in a legacy Java application that cannot be patched immediately, the pre-built signature can be activated in TR7 to block JNDI variants at the traffic layer and buy time for the application fix.
If a class loader manipulation risk exists in a legacy application framework, the rule can first be run in monitor mode. After measuring traffic impact for a day, the rule is moved to blocking mode to bring the vulnerability under control.
Before a vendor patch is available for a CMS plugin, an attack pattern may be visible in specific parameters. A custom regex rule is written in TR7 targeting only the relevant path or query field. This blocks risky requests without taking down the entire application.
When a penetration testing team reports an exploitable vulnerability in production, the development team needs time for a permanent fix. TR7 virtual patching provides an interim control that prevents the finding from turning into attack traffic during that window.
From Log4Shell to penetration test findings, TR7 virtual patching engages at the traffic layer in every emergency scenario. Let us walk through a live setup on your own environment.