Attack Payload Alerts: An Issue When Injection Attempts Hit Your Services

Last verified on Nov 10, 2026.

What it catches

Every public service gets hostile input. Most of it bounces off. Some of it is a person or a tool trying to turn a request parameter into a database query, a file read or a request to your internal network. The first sign is usually a strange string in a log line, long before there is any damage you can see.

Attack payloads is the Sazabi detection for those strings. You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. Sensors are standing questions about your logs, and this one asks whether requests carry attack strings. There is no signature list to import and no rule to tune.

The kinds of input it looks for:

• SQL injection attempts in a query string, form field or JSON body.
• Path traversal, where a file or document parameter tries to climb out of its directory.
• Server-side request forgery, where a URL parameter points at an internal address or a cloud metadata endpoint.
• Expression injection, where a name or message field carries syntax meant to be evaluated on the server.

Example: a probe that starts as noise and turns real

This is an example, not output from a real project. A service called search-api logs one line per request with the path, query and status:

2026-11-08T22:03:11Z INFO search-api GET /search q=boots status=200 ms=41 client=203.0.113.50
2026-11-08T22:03:14Z WARN search-api GET /search q=boots'%20OR%201=1-- status=500 ms=12 client=203.0.113.50
2026-11-08T22:03:15Z WARN search-api GET /search q=boots'%20UNION%20SELECT%20username,password%20FROM%20users-- status=500 ms=14 client=203.0.113.50
2026-11-08T22:03:19Z INFO search-api GET /fetch url=http://169.254.169.254/latest/meta-data/ status=200 ms=88 client=203.0.113.50

The first line is a normal search. The next two are SQL injection attempts that failed with a 500. The last one is the one to worry about: a request to the cloud metadata address that came back with a 200. A sensor that only counted attempts would treat all four lines alike. Sazabi investigates the firing and opens an issue. An example of what it could say:

• Name: SQL injection and metadata-address probe against search-api from one client
• Description: One client sent two SQL injection payloads to /search, both of which produced server errors, then requested the cloud metadata address through /fetch and received a 200 response.
• Severity: critical

The evidence is those request lines. The agent analysis separates the attempts that failed from the one that succeeded, which is what decides whether you are cleaning up a scan or responding to an incident.

Why the response matters

Scanners hit every site, so a payload in a log is not by itself an emergency. The investigation is where the question becomes "did anything work". Expect the issue to say what the payload tried to reach, which paths it hit, the response codes, and whether the same client got anywhere else. A 400 from your validation layer and a 200 with data are different findings and the issue is written to tell them apart.

How you get told

The issue sends an Issue triggered notification to in-app, email, Slack DM or SMS, and to shared Slack or Microsoft Teams channels when a delivery rule matches. Rules can match on severity, component or owning team, so critical security issues can go to a channel your security owner watches, not to every engineer.

You can ask the agent follow-up questions in the issue thread, for example whether the client touched any other route. Run sazabi issues agent-prompt to give the fix to a coding agent, such as adding input validation to the /fetch handler. Resolve, ignore or mute the issue from the dashboard, Slack, Teams or the CLI. A repeat from the same source while the issue is open or ignored folds into it.

What it needs from your logs

The payload has to be in what you send. Request logs that record the path and query are the usual source. Edge and gateway logs work too, for example Cloudflare or AWS WAF logs, as do application logs through OpenTelemetry. If bodies are not logged, a payload in a POST body will not be seen.

What it does not cover

• Payloads that never reach a log, such as an encrypted channel you do not terminate or a body you do not record.
• Blocking. Sazabi reports; it does not drop traffic or change a firewall rule.
• Weaknesses in your code that nobody has tried to exploit yet. Code scanning is not part of it.
• Known exploits for specific vulnerabilities in software you run. That question belongs to exploit attempts.

The vendor-neutral approach to decoding and judging payloads is in the SQL injection detection guide. Detection volume is metered; see pricing.