If the application patch is not ready, hoping the attacker waits is not a security strategy.
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.
Our approach
TR7 treats virtual patching not as a one-off emergency rule but as a testable, manageable security lifecycle.
Pre-built signatures for critical CVEs are included in the security set
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.
Custom patch rules are built step by step
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.
Patch date is recorded and traceable
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.
Monitor mode enables safe validation in production
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.
Capabilities
TR7 Virtual Patching combines pre-built CVE signatures, custom rule creation and controlled activation in a single policy pipeline.
Pre-built CVE signatures cover critical attack families quickly
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.
Try the pattern before it is attached to anything
Write the expression, paste a request that should match and one that should not, and see the result — inside the interface, before the rule is attached to a single service. The classic virtual-patching accident is a pattern that turned out slightly too broad and blocked real customers the moment it went live; here that is caught while writing it, not from the incident channel. Monitor mode is still there for the next step: the rule watches live traffic before it is allowed to block anything.
Custom regex-based virtual patches can be written for new vulnerabilities
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.
Monitor mode measures real traffic impact before blocking is enabled
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.
Score-based decision model manages different risk levels
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.
Different patch scopes can be defined at global and pool level
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.
The state and score of existing rules can be overridden
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.
Hot-reload keeps patch deployment from becoming a restart operation
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.
Patch behavior can be validated with a test attack dictionary
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.
Operational depth
Virtual patching requires rule traceability, rollback, scope control and test discipline as much as fast emergency response.
Rule ID ranges
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.
Patch date tracking
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.
Hot-reload compilation process
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.
Pre-production attack testing
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.
Rule rollback management
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.
Audit and evidence generation
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 to use it
Log4Shell emergency response
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.
Temporary Spring4Shell protection on a legacy application
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.
Custom parameter block for a CMS plugin vulnerability
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.
Temporary security control after a penetration test finding
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.
Frequently asked questions
Does TR7 virtual patching genuinely protect without changing application code?
Does TR7 automatically block new CVEs?
What is monitor mode and why should it be used?
Does adding a virtual patch rule require a service restart?
What is the difference between global-level and pool-level virtual patching?
How are virtual patches managed once the application is permanently fixed?
Close vulnerabilities without code changes
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.