Did anyone try a known exploit on your server?

How this log analyzer works

Two kinds of check run over every line. The first is one check per known exploit, written from our research write-ups and the vendor advisories: CyberPanel (CVE-2026-67614), Langflow (CVE-2026-9198), Portainer (CVE-2026-44848), Ivanti Sentry (CVE-2026-10520) and SonicWall SMA1000 (CVE-2026-15409). Each answers on its own: signs the exploit may have worked, the exploit pattern seen, a probe, could not check, or nothing found in what the logs recorded. Each answer comes with what the check could not see. Checks whose detection has not been tested against a real attack in our lab say so.

The second is a set of general attack patterns not tied to one CVE: a rarely requested script followed by repeated POSTs from one address, which is how a web shell in use looks in an access log; Log4Shell-style JNDI strings after URL decoding; path traversal; basic SQL injection. These give leads, not verdicts. Mass scanners are recognised by user agent and behaviour and set aside, so the requests aimed at you are not buried under the ones every server gets.

Supported formats: IIS, nginx, Apache and more

IIS W3C extended logs with any #Fields line, including files where the field list changes part-way through. nginx and Apache combined and common formats, with or without a virtual-host field, which also covers LiteSpeed and CyberPanel, Tomcat's access log valve and ingress-nginx. uvicorn access lines (FastAPI, Langflow), Caddy's JSON log and Traefik. Lines wrapped by Docker's JSON log driver, Kubernetes or syslog are unwrapped first. For anything else, paste your Apache LogFormat or nginx log_format line under “Checks and log format”. Rotated .gz files are decompressed in the browser, and several days of files are read together in time order.

Why it runs in your browser

Access logs hold visitors' IP addresses, which under GDPR are personal data, and often tokens in query strings. Uploading them to an online log analyzer hands both to someone else. Here the files are read by a background worker in this tab. The page sets a Content-Security-Policy that forbids it from making network requests once it has loaded, so not even a bug could send a line anywhere, and you can watch the network panel (F12, Network) stay empty while it runs.

Where IIS, nginx and Apache keep their logs

• IIS (one file per site per day, times in UTC)C:\inetpub\logs\LogFiles\W3SVC<site ID>\u_exYYMMDD.log
• nginx (older days rotated to .1 and .gz)/var/log/nginx/access.log, access.log.1, access.log.2.gz …
• Apache on Debian and Ubuntu/var/log/apache2/access.log
• Apache on RHEL, Rocky, Alma and Fedora/var/log/httpd/access_log
• cPanel, per domain/usr/local/apache/domlogs/
• LiteSpeed and CyberPanel/usr/local/lsws/logs/access.log, and per site under /home/<domain>/logs/
• Docker (json-file log driver)docker logs <container> > access.log, or /var/lib/docker/containers/<id>/<id>-json.log
• Kuberneteskubectl logs <pod> > access.log (ingress-nginx: the controller pod)

On IIS the site ID is shown in IIS Manager under Sites. Copy the files rather than reading them in place on a live server, and keep the originals untouched if this might become an incident: an insurer or a forensics firm will want them as they were.

What access logs can't show

An access log is one line per request: who asked, for what, when, and which status and size came back. It does not hold the request body, so an exploit sent in a POST appears as a path and a status code, never as the payload. It does not hold most headers or any cookies unless the format was changed to record them. It shows nothing that happened on the server after the response: a shell that was opened, a file that was written, a connection out. And it covers only the days the files cover.

That is why a check here can say that something was attempted, and sometimes that it may have worked, but never that a server is fine. When a check needs a field your logs do not have, it says “could not check” rather than “nothing found”.

Questions

Is this an online log analyzer? Are my logs uploaded?

It is a web page, but nothing is uploaded. The page downloads once, then reads your files locally. It keeps working with the network switched off.

Does “nothing found” mean the server was not hacked?

No. It means none of the checks matched in what these logs recorded. Exploits that left no trace in an access log, activity outside the dates the files cover, and traffic that bypassed the server that wrote the log are all invisible to it. Read what each check could not see before drawing a conclusion.

Why does a check say “could not check”?

Because the evidence it relies on is in a field your logs do not record, or in a product log you did not include. IIS, for example, only started logging bytes sent by default with the February 2026 update, and only on Windows Server 2019 and later. The check names what is missing so you can add it or find another source.

How large a log can it read?

Files are streamed rather than loaded whole, so a couple of gigabytes is fine on a laptop. Phones have less memory and keep fewer examples, but still count every line.

Can I use it for general nginx or Apache log analysis?

It answers security questions, not traffic ones: there are no top pages, browsers or countries. For traffic analytics, GoAccess and AWStats do that job well. For IIS log analysis of the “was this server attacked” kind, that is what this page is for.