Why a curl User-Agent Isn't Automatically Malicious

logtriage — Sun, 05 Jul 2026 06:38:20 +0000

A surprising number of security tools treat user-agent strings as a static blocklist: see curl, python-requests, or Go-http-client, raise an alert. In practice, this produces so many false positives that analysts learn to ignore the alert entirely — which defeats the purpose of having it.

curl hitting a public /health endpoint is completely unremarkable; it's almost certainly a monitoring probe or a developer's smoke test. The same curl user-agent posting to /api/v1/admin/users or /api/v1/beacon is a different story. The string itself didn't change. What changed is the context — the path being accessed, the response it got, what else that source IP did in the same session.

This is why context-aware risk scoring doesn't operate on the user-agent alone. A suspicious user-agent match is one signal among several: path sensitivity, ASN reputation, IP threat intelligence, and behavioral patterns from session grouping all feed into the same score. A compound-signal rule specifically rewards combinations — three or more independent high-severity indicators on the same event get a 1.25× multiplier. A curl request to a low-sensitivity endpoint from a clean IP stays low risk. The same user-agent on a sensitive admin path, from an ASN already flagged in a threat intelligence feed, compounds quickly.

The broader principle: a security tool that can't tell curl apart by context isn't actually doing risk assessment — it's pattern matching with an extra step.

I build LogTriage and publish a free, validated Sigma detection-rule library — each rule tested against a real sample log before it ships: logtriage.app/rules.

DEV Community: logtriage

Why a curl User-Agent Isn't Automatically Malicious