Active Attack Alerts: Issues When Someone Is Attacking Your App Right Now

Last verified on Nov 10, 2026.

Someone is attacking your application when their traffic shows up in your logs as hostile input, probes for a known hole, or a flood of login attempts. The Sazabi agent sets up sensors for your project and maintains them over time. When one of them fires, the agent investigates and opens an issue that already says what happened and what it saw.

This page lists what feeds the active attack category today, how each one is produced, and where the edges are.

What feeds this category

Three live signals cover active attacks:

• Attack payloads. SQL injection, path traversal, server-side request forgery and other injection attempts that appear in requests.
• Exploit attempts. Traffic that matches a known exploit against your stack, such as probes for the vulnerable endpoint of a newly published advisory.
• Authentication anomalies. Bursts of failed logins, credential stuffing, impossible travel and reused sessions. The agent learns how your login and session events look from your logs.

Nobody configures any of them. Only your logs say what a login failure is called in your system, so the agent reads them to find out.

Example: a stuffing run against the login route

This is an example, not output from a real project. The service names and addresses are made up. Your web-api service logs a steady trickle of failed logins. Then this starts:

2026-11-08T02:14:03Z WARN  web-api POST /session login_failed user=m.ortiz@example.com ip=203.0.113.41
2026-11-08T02:14:03Z WARN  web-api POST /session login_failed user=d.chen@example.com ip=203.0.113.41
2026-11-08T02:14:04Z WARN  web-api POST /session login_failed user=a.patel@example.com ip=203.0.113.58
2026-11-08T02:14:04Z WARN  web-api POST /session login_failed user=k.lee@example.com ip=203.0.113.58

The sensor's question reads like this: "Tell me when failed logins spread across many different accounts from a few addresses at a pace far outside the usual." When it fires, the agent investigates. It checks whether any of those accounts later logged in successfully and whether the same addresses touched other routes.

The issue could be named "Credential stuffing against /session from two address ranges", with a severity of high, a description of when it began and the evidence lines. If one of the targeted accounts did sign in afterward, the agent says so in the analysis.

What you see and how you hear about it

You see an issue in the Issues inbox. It carries a name, a description, a severity from low to critical, an optional component and a status, plus the agent's analysis and evidence. Ask follow-up questions in its thread, for example whether the addresses also hit the password-reset route.

The Issue triggered notification goes to your in-app feed first. To page a security channel in Slack or Microsoft Teams, add a delivery rule on severity, component or owning team. Hand the cleanup to a coding agent with sazabi issues agent-prompt when the fix is code, such as adding rate limits to the login route.

If the attack continues while the issue is open or ignored, the repeats fold into the same issue. A resolved issue that sees the attack again opens a new one.

What you need

You need logs that carry the request. For payload and exploit signals that means paths, query strings and user agents from your app, a load balancer or an edge provider. If Cloudflare fronts your traffic, its logs are a good source, and the Cloudflare integration covers setup. For authentication signals you need your login and session events, with some stable field for the account and the source address.

The AWS integration and the OpenTelemetry integration cover other common routes in.

What it does not cover

• Attacks that leave no line in your logs. A flood absorbed upstream before it reaches anything that logs is invisible here.
• Stopping the attack. A sensor reads logs after the fact. It tells you quickly; your firewall or your team acts.
• Suspicious but successful access, such as a valid user pulling too much data. That lives on the suspicious access page.
• Risky code and supply chain problems. Neither is covered today.

See pricing for how detected issues are metered.

Related

The vendor-neutral view is in the guide to attack payload detection. For abuse that is not an exploit, read abuse and fraud.