← Problem Library
Security L7 SECURITY-1224 · 18 min

WAF rollback looks complete but one hostname still enforces the old rule because it reads policy from another config source

Central policy changed, yet one hostname behaves as if rollback never happened because it is attached to another rollout or config surface.

SecurityWAF / AppSecPlatform ReliabilityLevel 7Pro18 min
Scenario

A temporary block is reverted and most traffic returns to normal, but one API hostname still rejects the old pattern.

What to check first
  • Identify the primary failure signal in the WAF / AppSec scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Validate which config source each hostname is actually consuming.

Questions worth viewing together
What should you verify first when WAF rollback looks complete but one hostname still enforces the old rule appears?

Community-field WAF operations problem inspired by public reports where one hostname still enforced old policy because it was detached from the main con... A successful central rollback does not guarantee every hostname reads the same source of truth.

What usually causes WAF rollback looks complete but one hostname still enforces the old rule in production?

Teams often assume propagation delay when one hostname is actually attached to another config path.

What should you document after resolving WAF rollback looks complete but one hostname still enforces the old rule?

Hostname-specific policy attachments can survive longer than central rule rollbacks.