The Loghound Threat Model - Adversaries, Trust and Limits

Loghound parses hostile input by definition: log lines carry paths, User-Agents and referrers chosen by strangers, and the beacon collector is a public write path. This page names the adversaries, what is trusted and what never is, and the limits stated plainly.

01 · Who the adversaries are

Anyone who can send a request to a monitored site

Full control of the request path, query string, User-Agent, referrer and every other header — all of which end up as bytes in a log line Loghound parses

What they want: Stored scripting in the panel, query injection, path traversal, exhausting the ingest daemon

Anyone on the internet

Can post to the beacon collector, which is public and unauthenticated by design

What they want: Forge sessions, poison timing metrics, exhaust the staging table, get code execution on a public write path

A local unprivileged user on the same box

Can read world-readable files

What they want: The API key, the beacon signing secret, the traffic data

Another site on the same shared host

Executes as the shared web server user

What they want: The same secrets, via a readable configuration file

A compromised panel session

Authenticated, can drive every panel action

What they want: Pivot from reading the dashboard to reading arbitrary files or running arbitrary queries

A compromised enrichment provider

Controls the response body

What they want: Injection through a field the operator assumes is trustworthy

Explicitly out of scope: an attacker with root on the box; a compromised Solr; denial of service by sheer traffic volume against the origin web server; and the security of your own web server, PHP build and TLS configuration.

02 · What is trusted, and what is not

Figure 1 — the trust boundary. The important consequence: there is no point in the pipeline where a log-derived value becomes safe. It is escaped at the sink, every time, in the encoding that sink requires.

03 · Known limitations, stated plainly

Because a security document that only lists strengths is marketing.

The sign-in lockout is per address, and only per address. That is deliberate rather than an oversight — the reasoning is here — but the cost is that a distributed guesser is not slowed by it at all.
There is no audit log of panel actions. No record of who looked at what.
The raw line copy stores complete log lines, including any credential that ended up in a query string on your site. That is your data and your risk; the switch exists so you can decide.
Enrichment responses are parsed, not verified. A compromised provider could inject a value. It is escaped at every output point, but it can still make a field say something untrue.
The JA4 field is filled only when your web server logs a JA4 fingerprint (a ja4 variable or an X-JA4 header), and no scoring rule reads it yet.
The beacon can be blocked, and a token can be replayed within its window. The signature proves the token was issued by us for that session and that origin — not that this particular client is the one it was issued to. What that buys an attacker is the ability to lie about dwell time for their own session, which is why forged timings are recorded as a signal rather than trusted or dropped.
No formal third-party security audit has been performed. If you do one, the results are very welcome.

Threat model

Security