Security Issues: Attacks, Suspicious Access and Exposure Found in Logs

Last verified on Nov 10, 2026.

What lands in this group

Security issues cover five kinds of trouble: someone attacking the application, someone using an account in an odd way, a secret sitting where it should not, abuse such as scraping or fake signups, and an AI agent spending far beyond its normal budget. They all start the same way, with something in a log that does not look like ordinary traffic.

If you want the vendor-neutral view of what to log and what to look for, the security monitoring guide covers it. This page is about what Sazabi opens an issue for without you writing a rule.

Where the issues come from

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. Eight live signals feed security issues.

What requests and log lines contain

• Attack payloads: SQL injection, path traversal and SSRF strings in requests.
• Exploit attempts: requests that match a known exploit against your stack.
• Bots and scraping: high-rate clients, headless browsers and rotating addresses.
• Secrets or personal data in logs: tokens, keys, emails or ID numbers written to a log line.

How accounts, access and spend behave

• Authentication anomalies: bursts of failed logins, credential stuffing, impossible travel and session reuse.
• Privilege changes: new admins, role escalations and new API keys.
• Unusual data egress: a large export or response going to a single actor.
• LLM spend spike: token use that jumps for one feature or customer, which is the agent-misbehavior side of the group.

The first four need no knowledge of your app, because an injection string looks the same everywhere. The other four depend on what a login, an admin grant or an export is in your logs, so the agent reads your logs first.

Example: a quiet probe turns into a credential spray

This is an example, not output from a real project. The first lines are a path traversal attempt that reaches the application:

2026-11-08T03:10:44Z WARN  files-api GET /download?file=../../etc/passwd status=400 client=198.51.100.23
2026-11-08T03:10:45Z WARN  files-api GET /download?file=..%2f..%2fetc%2fshadow status=400 client=198.51.100.23

An hour later the login route sees a different kind of traffic:

2026-11-08T04:02:10Z INFO  auth-api login failed user=m.ortiz@example.com client=203.0.113.9
2026-11-08T04:02:10Z INFO  auth-api login failed user=d.chen@example.com client=203.0.113.14

The first triggers the attack payloads sensor, which asks whether requests carry attack strings. The second triggers the authentication anomalies sensor, which asks whether failed logins are spread across many accounts from many addresses. The agent investigates each one, and an issue might read like this:

Failed logins across many accounts from rotating addresses (high, component: auth). Failures hit several hundred accounts in an hour, each from a different address, with no successful login from those addresses. Earlier path traversal probes against files-api came from a neighboring range. Evidence: the failure counts per account, the address spread and the absence of successes.

The line "no successful login" is what separates a noisy night from an incident.

What you see and how you are told

An issue arrives already investigated, with what happened, why, and the evidence. Severity runs low, medium, high and critical, and you can attach a component and an owning team. The issue thread lets you ask follow-up questions, such as which accounts were targeted.

Issue triggered goes to the app, email, Slack DM or SMS, and to shared Slack or Microsoft Teams channels through delivery rules. A workable setup sends high and critical to SMS and a security channel and leaves the rest in the inbox. You can resolve, ignore or mute from the dashboard, Slack, Teams or CLI. Recurrences of an open issue fold into it, so an ongoing probe does not flood the channel.

What it does not cover

• Sazabi does not block traffic. It reports what reached your logs.
• Traffic stopped at the edge never reaches a log, so it is not seen.
• Code scanning, dependency advisories and supply chain checks are not covered today.
• Unusual access to objects by an authenticated user is not covered today.

Edge logs can still be useful input. See the Cloudflare and AWS integrations for the sources, and pricing for how issues are metered. The glossary entries on credential stuffing and data exfiltration define two of the attacks above.