If Cloudflare's WAF already blocked it, why alert?

A block stops one request; the pattern tells you an attacker is actively mapping and exploiting your surface — often the prelude to a request that isn't blocked. Alerting on the attempt (Action=block or log) gives you attacker IP, timing, and target so you can rate-limit/ban and check whether anything got through.

Why match on the path instead of the WAF ruleID?

Matching literal traversal/sensitive-file patterns in ClientRequestPath is portable and catches attempts regardless of which WAF rule (or none) fired — including 'log' actions where the WAF didn't block. Pair it with your WAF ruleID data for defense in depth.

How does LogTriage add value here?

Its path-sensitivity classifier scores requests to sensitive endpoints, and the recon pattern detector flags wide sensitive-path coverage from one source — so a traversal sweep is surfaced as a reconnaissance incident with the attacker IP and full path list, not scattered log lines.

Detect Path Traversal & Sensitive-File Recon in Cloudflare Logs

Sigma Rule

title: Cloudflare — Path Traversal / Sensitive File Probe
id: 1b6e4a83-7c29-4d50-9a38-6e2f9c3b1a10
status: experimental
description: >
  Detects directory-traversal and sensitive-file access attempts at the Cloudflare
  edge — requests for /etc/passwd, /etc/shadow, .env, and ../ traversal sequences.
  Whether WAF-blocked or merely logged, these requests indicate active recon /
  exploitation of a public-facing app.
references:
  - https://attack.mitre.org/techniques/T1190/
author: LogTriage
date: 2026/07/01
logsource:
  product: cloudflare
detection:
  selection:
    ClientRequestPath|contains:
      - '../'
      - '/etc/passwd'
      - '/etc/shadow'
      - '/.env'
      - '/.git/'
      - 'wp-config'
  condition: selection
falsepositives:
  - Authorized scanners / bug-bounty researchers (allowlist source IPs)
  - Rare legitimate paths containing encoded '..' (inspect first)
level: high
tags:
  - attack.initial_access
  - attack.discovery
  - attack.t1190

What this rule detects

Path traversal and sensitive-file probing is classic web recon/exploitation: an attacker requests /etc/passwd, /etc/shadow, .env, .git/, or uses ../ sequences to escape the web root. At the Cloudflare edge these show up in ClientRequestPath, whether the WAF blocks or merely logs them.

This rule fires on any request whose path contains a traversal or sensitive-file pattern.

Detection logic

Match literal high-signal substrings in ClientRequestPath (../, /etc/passwd, /.env, /.git/, wp-config). This is portable — it catches the attempt regardless of which WAF rule fired, including log-only actions where nothing was blocked. The strongest confirmation is many distinct sensitive paths from one source IP in a short window (a sweep).

LogTriage’s reconnaissance detection scores sensitive-path access and clusters wide coverage from one source into a single recon incident.

Validated against a real sample

Validated against cloudflare_waf_attack.json (shipped with LogTriage): requests for /../../../etc/passwd, /api/v1/../../etc/shadow, and /admin/.env with Action: block. The rule fires on that sample and stays silent on the matching benign traffic log.

False positives

Authorized scanners and bug-bounty researchers generate identical traffic — allowlist their source IPs. A legitimate path with an encoded .. is rare; inspect before adding an exception.

Frequently Asked Questions

If Cloudflare's WAF already blocked it, why alert?: A block stops one request; the pattern tells you an attacker is actively mapping and exploiting your surface — often the prelude to a request that isn't blocked. Alerting on the attempt (Action=block or log) gives you attacker IP, timing, and target so you can rate-limit/ban and check whether anything got through.
Why match on the path instead of the WAF ruleID?: Matching literal traversal/sensitive-file patterns in ClientRequestPath is portable and catches attempts regardless of which WAF rule (or none) fired — including 'log' actions where the WAF didn't block. Pair it with your WAF ruleID data for defense in depth.
How does LogTriage add value here?: Its path-sensitivity classifier scores requests to sensitive endpoints, and the recon pattern detector flags wide sensitive-path coverage from one source — so a traversal sweep is surfaced as a reconnaissance incident with the attacker IP and full path list, not scattered log lines.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs