fabriziosalmi/certmate v2.13.2

v2.13.2 — security: scope & rate-limit hardening

on GitHub

Security hardening patch. Two findings were confirmed and fixed after an adversarial re-verification of the audit's security tier against current main; four others were ruled out (two false positives, one already fixed, and API-token brute-force already neutralised by the existing token-entropy enforcement).

Fixes

• Scope boundary: apex-scoped API key no longer authorizes the wildcard certificate. domain_matches_scope normalised the requested domain with lstrip('*.'), which strips a character set rather than the literal *. prefix, collapsing *.example.com to example.com. A key scoped only to the apex example.com could therefore issue/renew/delete the wildcard *.example.com, whose certificate is valid for every subdomain — a privilege escalation across the documented scope boundary. A wildcard request is now authorized only by an identical wildcard scope entry; forward matching (apex / exact / subdomain-vs-wildcard) is unchanged.

• Login rate-limit memory: bounded under source-IP / username rotation. The bucket sweep only removed already-empty entries, but a rotated key is recorded once as a non-empty [ts] and never revisited, so it was never reclaimed and the dicts grew without bound (memory-exhaustion DoS). The sweep now trims every bucket to its active window once over the soft cap, with a hard 2x-cap backstop. Rate-limiting behaviour is unchanged.

Notes

• Behaviour change (security-motivated): an apex scope no longer implies the corresponding wildcard. Any client relying on that was relying on the bug.
• Both changes are authentication-logic only — no change to the certificate issuance or DNS-provider path.

Validation

Full test suite green (1435 passed, 16 skipped, 1 xfailed) plus a Docker boot smoke (container /health and /health/ready return 200, image reports 2.13.2).

Full changelog: v2.13.1...v2.13.2