anhanga is a request filter that sits in front of other services. A flaw in it is a flaw in everything it protects — a bypass here silently reopens whatever the deny rules were closing. We take reports seriously and we would much rather hear about a problem early.

Please do not open a public issue.

Report privately through either channel:

• GitHub Security Advisories — open a private report (preferred; it keeps the discussion attached to the repository).
• Email — ericof@simplesconsultoria.com.br

Useful things to include, as far as you have them:

• The version or image tag affected (anhanga version, or the GHCR tag).
• A rules.yaml fragment that reproduces it, plus the request that gets through (or gets blocked) when it should not.
• What you expected instead.

You do not need a working exploit or a fix to report something. A clear description of the bypass is plenty.

• Acknowledgement within 5 business days.
• An assessment and a rough timeline once we have reproduced it.
• Credit in the release notes when the fix ships, unless you would rather not be named.

Please give us a reasonable window to ship a fix before disclosing publicly.

Versions are CalVer (YYYYMMDD.N). Only the latest released version is supported — fixes ship as a new release rather than as backports. Upgrading is a tag bump.

In scope, and the kind of thing we most want to hear about:

• A request that should match a deny rule set but does not (filter bypass).
• Anything that causes the service to fail open — evaluating to allow when it should deny, or when it cannot decide.
• Crashes, panics, or unbounded resource use reachable from request input.
• A rules.yaml that passes check but compiles into rules that do not mean what the file says.

Out of scope, because they are documented behaviour rather than defects — though please do tell us if the documentation is what is wrong:

• Forged X-Forwarded-For when Traefik's forwardedHeaders.trustedIPs is misconfigured. anhanga trusts the header Traefik hands it. Configuring that trust boundary correctly is the operator's job, and getting it wrong makes every client_ip rule cosmetic. See "Trust your forwarded headers" in the README.
• Information disclosed by --verbose-deny. It exists to name the rule that fired, which is why the README says to leave it off in production.
• Denial of service against your own site by writing a rule set that matches everything. check rejects the common forms of this, but it cannot read your intent.
• Findings in Traefik itself — please report those to Traefik.