@hilbras/keystone 2.6.0 → 3.0.0

package/docs/security/registry.md

@@ -0,0 +1,657 @@
+# Security regression registry
+
+<!-- Generated by scripts/render-security-registry.mjs from docs/security/registry.json. Do not edit by hand. -->
+
+Every vulnerability found in Keystone, the fix, the test that would fail without it, and where it is documented. The registry is validated by `npm run registry:check`, which fails if an entry names a test that does not exist, if a security suite is claimed by no entry, or if a mandatory attack class is uncovered.
+
+**46 findings.**
+
+| Severity | Count |
+| --- | --- |
+| critical | 6 |
+| high | 26 |
+| medium | 13 |
+| low | 1 |
+
+## Mandatory attack classes
+
+The CI pipeline must exercise each of these. Every one is claimed by at least one entry above; the check is mechanical, not a convention.
+
+| Attack class | Findings |
+| --- | --- |
+| `privilege-escalation` | SEC-001, SEC-002, SEC-003, SEC-007, SEC-023, SEC-025, SEC-028, SEC-032 |
+| `mfa-bypass` | SEC-004, SEC-005, SEC-015, SEC-034 |
+| `tenant-isolation` | SEC-001, SEC-003, SEC-006 |
+| `token-replay` | SEC-012, SEC-013, SEC-038 |
+| `oauth-attacks` | SEC-016, SEC-017, SEC-018, SEC-019, SEC-020, SEC-021 |
+| `scim-cross-tenant` | SEC-006 |
+| `mtls-spoofing` | SEC-007, SEC-009, SEC-010 |
+| `xff-spoofing` | SEC-008, SEC-009 |
+| `api-scope-escalation` | SEC-023, SEC-024, SEC-025 |
+| `secret-disclosure` | SEC-026, SEC-027, SEC-028, SEC-029, SEC-030, SEC-031 |
+| `session-persistence` | SEC-014, SEC-015, SEC-031, SEC-038 |
+| `password-reset-invalidation` | SEC-014 |
+
+## Critical
+
+### SEC-001 — Organization role escalation through self-assignment
+
+*Fixed in v1.7.0. Component: `authorization`.*
+
+**Issue.** A member could set their own organization role, so a `member` could promote themselves to `owner` and then administer the organization they were only supposed to belong to.
+
+**Fix.** src/routes/admin/organizations.ts — role changes are owner-only and cannot target the caller's own membership
+
+**Test.** `src/tests/security/authorization/authorization.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `privilege-escalation`, `tenant-isolation`
+
+### SEC-002 — Platform-owner routes reachable without the owner role
+
+*Fixed in v1.7.0. Component: `authorization`.*
+
+**Issue.** Platform administration endpoints checked authentication but not the owner role, so any authenticated session could list and modify every user, organization and application in the installation.
+
+**Fix.** src/routes/admin/helpers.ts — requireOwner() on every platform route
+
+**Test.** `src/tests/security/authorization/authorization.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `privilege-escalation`
+
+### SEC-004 — MFA could be enabled without ever being enforced
+
+*Fixed in v1.8.0. Component: `mfa`.*
+
+**Issue.** MFA was checked on the interactive login path only. Every other token-issuing path — refresh, OAuth token exchange, the token login flow — issued a full session without consulting the user's MFA state, so the control was present in the UI and absent everywhere else.
+
+**Fix.** src/services/application/authentication.ts — a single token-issuance chokepoint that every flow passes through
+
+**Test.** `src/tests/security/mfa/mfa.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `mfa-bypass`
+
+### SEC-006 — SCIM credentials were not organization-scoped
+
+*Fixed in v1.9.0. Component: `scim`.*
+
+**Issue.** A SCIM token was accepted as a global credential, so a provisioning client for one organization could read and write users and groups in every organization in the installation.
+
+**Fix.** src/services/scimCredentials.ts and src/routes/scim.ts — a credential resolves to exactly one organization
+
+**Test.** `src/tests/security/scim/isolation.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `scim-cross-tenant`, `tenant-isolation`
+
+### SEC-007 — x-service-account-id was a complete authentication bypass
+
+*Fixed in v2.0.0. Component: `trust-boundary`.*
+
+**Issue.** The mTLS plugin trusted a client-supplied `x-service-account-id` header as the caller's identity. Any client that could reach the service could assert any service account and act as it, with no certificate and no secret.
+
+**Fix.** src/plugins/mtls.ts — identity is derived from the verified client certificate and bound to its fingerprint
+
+**Test.** `src/tests/security/proxy/trust-boundary.test.ts`
+
+**Documentation.** [docs/security/mtls.md](./mtls.md)
+
+**Attack classes.** `mtls-spoofing`, `privilege-escalation`
+
+### SEC-023 — A wildcard scope let any API key act as any service account
+
+*Fixed in v2.6.0. Component: `api-keys`.*
+
+**Issue.** The scope registry contained a `service_account` entry that any key carrying could use as a wildcard against every scope check, so a narrowly scoped key behaved as a fully privileged one.
+
+**Fix.** src/services/scopes.ts — the wildcard is gone; every scope must be named
+
+**Test.** `src/tests/security/api-keys/scopes-and-principals.test.ts`
+
+**Documentation.** [docs/security/scopes.md](./scopes.md)
+
+**Attack classes.** `api-scope-escalation`, `privilege-escalation`
+
+## High
+
+### SEC-003 — Tenant-unsafe workflow execution
+
+*Fixed in v1.7.0. Component: `authorization`.*
+
+**Issue.** Workflow lookup was keyed by identifier alone, so a request naming another organization's workflow run executed it and read its output.
+
+**Fix.** src/services/workflows/engine.ts — every lookup is scoped to the owning organization
+
+**Test.** `src/tests/security/authorization/authorization.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `tenant-isolation`, `privilege-escalation`
+
+### SEC-005 — TOTP verification was not bound to the user
+
+*Fixed in v1.8.0. Component: `mfa`.*
+
+**Issue.** A TOTP code was checked against a resolved secret without confirming the code belonged to the account being authenticated, so a valid code for one account could satisfy verification for another.
+
+**Fix.** src/services/totp.ts — verification is user-scoped
+
+**Test.** `src/tests/security/mfa/mfa.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `mfa-bypass`
+
+### SEC-008 — Unconditional x-forwarded-for trust escaped every rate limit
+
+*Fixed in v2.0.0. Component: `proxy`.*
+
+**Issue.** `trustProxy: true` accepted x-forwarded-for from any peer, so a client could present a fresh address on every request and receive an unlimited rate-limit budget on every endpoint, including login and MFA verification.
+
+**Fix.** src/services/trustedProxies.ts — forwarding headers are honoured only from explicitly configured networks
+
+**Test.** `src/tests/security/rate-limiting/abuse-prevention.test.ts`
+
+**Documentation.** [docs/security/proxy-security.md](./proxy-security.md)
+
+**Attack classes.** `xff-spoofing`
+
+### SEC-009 — Client-supplied identity headers were not stripped
+
+*Fixed in v2.0.0. Component: `trust-boundary`.*
+
+**Issue.** Identity-bearing headers survived to route handlers even when the peer was untrusted, so a header-stripping gap in one plugin would be a bypass in another.
+
+**Fix.** src/plugins/headerSanitization.ts — untrusted identity headers are removed before routing
+
+**Test.** `src/tests/security/proxy/trust-boundary.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `xff-spoofing`, `mtls-spoofing`
+
+### SEC-010 — A service account certificate was not bound to the account it claimed
+
+*Fixed in v2.0.0. Component: `mtls`.*
+
+**Issue.** Certificate authentication proved possession of a valid certificate but not that the certificate belonged to the service account being used, so any certificate issued by a trusted CA could impersonate any service account.
+
+**Fix.** src/plugins/mtls.ts — the certificate fingerprint must match the stored binding
+
+**Test.** `src/tests/security/proxy/trust-boundary.test.ts`
+
+**Documentation.** [docs/security/mtls.md](./mtls.md)
+
+**Attack classes.** `mtls-spoofing`
+
+### SEC-011 — A production container shipped a bundled npm with eight high-severity CVEs
+
+*Fixed in v2.1.0. Component: `supply-chain`.*
+
+**Issue.** The production image included npm itself, which carried eight high advisories. `npm audit` and the OSV scanner both read the lockfile, not the image, so the finding was invisible to every configured gate.
+
+**Fix.** Dockerfile — npm is removed from the runtime stage
+
+**Test.** `.github/workflows/supply-chain.yml`
+
+**Documentation.** [docs/security/supply-chain.md](./supply-chain.md)
+
+### SEC-012 — Single-use credentials were readable and consumable more than once
+
+*Fixed in v2.2.0. Component: `tokens`.*
+
+**Issue.** Magic links, password reset tokens and SMS OTP codes were checked and then consumed as two separate steps. Concurrent requests could each pass the check before any of them consumed the credential, so a single emailed code produced many sessions — 50 concurrent requests yielded 50 successful logins.
+
+**Fix.** src/services/singleUse.ts — a single atomic claim, so exactly one request can consume a credential
+
+**Test.** `src/tests/security/tokens/single-use.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `token-replay`
+
+### SEC-014 — Password reset did not revoke existing sessions
+
+*Fixed in v2.3.0. Component: `sessions`.*
+
+**Issue.** Resetting a password left every existing session and refresh token valid. An attacker who had obtained a session before the victim changed their password retained access indefinitely, which defeats the purpose of the reset.
+
+**Fix.** src/services/sessionRevocation.ts — a password change evicts sessions, refresh tokens and pending challenges
+
+**Test.** `src/tests/security/sessions/session-revocation.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `password-reset-invalidation`, `session-persistence`
+
+### SEC-015 — Enabling MFA did not invalidate sessions issued without it
+
+*Fixed in v2.3.0. Component: `sessions`.*
+
+**Issue.** Turning on a second factor left pre-existing sessions untouched, so an attacker holding a session captured before enrolment kept full access after the user believed they had raised their security.
+
+**Fix.** src/services/sessionRevocation.ts — revocation is centralized and applied on MFA enablement
+
+**Test.** `src/tests/security/mfa/mfa.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `session-persistence`, `mfa-bypass`
+
+### SEC-016 — The authorization_code grant never verified the client secret
+
+*Fixed in v2.4.0. Component: `oauth`.*
+
+**Issue.** `verifyClientSecret` was called on the other grants but not on the authorization code exchange, so a confidential client could redeem a code with only its public client_id. Latent rather than live — the code still required a matching redirect_uri and the code itself — but it removed a layer that the grant was specified to have.
+
+**Fix.** src/routes/oauth2.ts — client authentication is mandatory for confidential clients on every grant
+
+**Test.** `src/tests/security/oauth/oauth2-hardening.test.ts`
+
+**Documentation.** [docs/MIGRATION-2.4.md](./docs/MIGRATION-2.4.md)
+
+**Attack classes.** `oauth-attacks`
+
+### SEC-017 — javascript: and data: were accepted as redirect URIs
+
+*Fixed in v2.4.0. Component: `oauth`.*
+
+**Issue.** Redirect URI validation checked structure but not scheme, so a client could register a `javascript:` URI. The authorization response carrying a code or token would then execute in the context of the authorization page, turning the redirect into script execution.
+
+**Fix.** src/services/redirectUri.ts — only https, and http for loopback, are registrable
+
+**Test.** `src/tests/security/oauth/oauth2-hardening.test.ts`
+
+**Documentation.** [docs/MIGRATION-2.4.md](./docs/MIGRATION-2.4.md)
+
+**Attack classes.** `oauth-attacks`
+
+### SEC-019 — ID token algorithm was inferred and expiry was optional
+
+*Fixed in v2.4.0. Component: `oidc`.*
+
+**Issue.** The ID token's signing algorithm was read from the token's own header rather than from the connector's registered configuration, and neither `exp` nor `iat` was required. A token could therefore be verified under an algorithm the operator never configured, and one with no expiry at all was accepted.
+
+**Fix.** src/services/connectors/oidc.ts — the algorithm comes from configuration, and exp and iat are required
+
+**Test.** `src/tests/security/oauth/oauth2-hardening.test.ts`
+
+**Documentation.** [docs/MIGRATION-2.4.md](./docs/MIGRATION-2.4.md)
+
+**Attack classes.** `oauth-attacks`
+
+### SEC-020 — The default Google connector discarded the OIDC nonce
+
+*Fixed in v2.5.0. Component: `oidc`.*
+
+**Issue.** `GoogleConnector.exchangeCode` dropped the nonce when calling the token endpoint, so a correct nonce was never sent and the response could not be checked. This defeated SEC-018 for the most commonly configured provider, which is why the fix in 2.4.0 was not sufficient on its own.
+
+**Fix.** src/services/connectors/google.ts — the nonce is forwarded on exchange
+
+**Test.** `src/tests/security/oidc/enterprise-sso.test.ts`
+
+**Documentation.** [docs/security/enterprise-sso.md](./enterprise-sso.md)
+
+**Attack classes.** `oauth-attacks`
+
+### SEC-024 — Scope enforcement failed open for requests without a key
+
+*Fixed in v2.6.0. Component: `api-keys`.*
+
+**Issue.** `requireScopes` returned early when `request.apiKeyId` was absent, so any authenticated path that reached a scoped route without going through key authentication skipped the scope check entirely.
+
+**Fix.** src/services/scopes.ts — enforcement fails closed and treats a missing key as no authority
+
+**Test.** `src/tests/security/api-keys/scopes-and-principals.test.ts`
+
+**Documentation.** [docs/security/scopes.md](./scopes.md)
+
+**Attack classes.** `api-scope-escalation`
+
+### SEC-025 — Human-only operations were available to machine principals
+
+*Fixed in v2.6.0. Component: `service-accounts`.*
+
+**Issue.** Profile and MFA management accepted any authenticated principal, so a service account key could read and change a person's profile and second-factor settings.
+
+**Fix.** src/plugins/machinePrincipal.ts — requireHumanPrincipal() rejects machine principals, placed after authentication so it can see them
+
+**Test.** `src/tests/security/api-keys/scopes-and-principals.test.ts`
+
+**Documentation.** [docs/security/scopes.md](./scopes.md)
+
+**Attack classes.** `api-scope-escalation`, `privilege-escalation`
+
+### SEC-026 — Configuration redaction used a denylist that missed half the secrets
+
+*Fixed in v2.7.0. Component: `configuration`.*
+
+**Issue.** Redaction matched a list of known secret-looking key names. Measuring it against the real configuration surface, 12 of 24 secret-shaped keys were returned unredacted, including the signing keys — so the owner-only configuration endpoint disclosed the material used to sign tokens.
+
+**Fix.** src/services/configuration/profiles.ts — an allowlist of exposable keys replaces the denylist
+
+**Test.** `src/tests/security/configuration/secrets-config.test.ts`
+
+**Documentation.** [docs/security/configuration.md](./configuration.md)
+
+**Attack classes.** `secret-disclosure`
+
+### SEC-027 — An empty CORS allowlist permitted every origin with credentials
+
+*Fixed in v2.7.0. Component: `configuration`.*
+
+**Issue.** An unset or empty `ALLOWED_ORIGINS` was treated as 'allow all', combined with credentialed requests. A misconfiguration therefore produced a wildcard CORS policy that browsers enforce, rather than a closed one.
+
+**Fix.** src/services/trustedProxies.ts — isOriginAllowed() fails closed on an empty allowlist, shared with the tests rather than duplicated
+
+**Test.** `src/tests/security/configuration/secrets-config.test.ts`
+
+**Documentation.** [docs/security/configuration.md](./configuration.md)
+
+**Attack classes.** `secret-disclosure`
+
+### SEC-028 — The setup server allowed any origin with credentials
+
+*Fixed in v2.7.0. Component: `configuration`.*
+
+**Issue.** The first-run setup server was configured with `origin: true` and credentials enabled, so any page in the operator's browser could call it during setup and complete provisioning.
+
+**Fix.** src/routes/setup.ts — the setup origin is restricted to the server's own address
+
+**Test.** `src/tests/security/configuration/secrets-config.test.ts`
+
+**Documentation.** [docs/security/configuration.md](./configuration.md)
+
+**Attack classes.** `secret-disclosure`, `privilege-escalation`
+
+### SEC-029 — The setup token was written to stdout
+
+*Fixed in v2.7.0. Component: `configuration`.*
+
+**Issue.** The token granting initial owner access was printed to the process log, so it reached log aggregation, container stdout capture and any log shipper — the credential intended to bootstrap trust was the one most widely distributed.
+
+**Fix.** src/services/setup/token.ts — the token is delivered once, and printing requires an explicit opt-in
+
+**Test.** `src/tests/security/configuration/secrets-config.test.ts`
+
+**Documentation.** [docs/security/configuration.md](./configuration.md)
+
+**Attack classes.** `secret-disclosure`
+
+### SEC-031 — Session cookies were not Secure by default in production
+
+*Fixed in v2.7.0. Component: `configuration`.*
+
+**Issue.** `COOKIE_SECURE` defaulted to false, so a production deployment that did not set it explicitly issued session cookies over plaintext, exposing them to interception on any non-TLS path.
+
+**Fix.** src/plugins/auth.ts — Secure defaults to true when NODE_ENV is production
+
+**Test.** `src/tests/security/configuration/secrets-config.test.ts`
+
+**Documentation.** [docs/security/configuration.md](./configuration.md)
+
+**Attack classes.** `secret-disclosure`, `session-persistence`
+
+### SEC-032 — The setup server listened on all interfaces
+
+*Fixed in v2.7.0. Component: `configuration`.*
+
+**Issue.** The setup server bound 0.0.0.0, so during first run the unauthenticated provisioning endpoint was reachable from the network rather than only from the operator's machine.
+
+**Fix.** src/routes/setup.ts — loopback by default, overridable, and warns when exposed
+
+**Test.** `src/tests/security/configuration/secrets-config.test.ts`
+
+**Documentation.** [docs/security/configuration.md](./configuration.md)
+
+**Attack classes.** `privilege-escalation`
+
+### SEC-033 — A Redis outage removed rate limiting entirely
+
+*Fixed in v2.8.0. Component: `rate-limiting`.*
+
+**Issue.** Every limiter returned 'allowed' when Redis was unavailable, so during an outage login, MFA verification, OTP verification and the OAuth token exchange had no limit at all. An outage is precisely when unlimited attempts are worth having, because a burst of guessing no longer looks like a burst.
+
+**Fix.** src/services/localRateLimit.ts — a bounded in-process budget, used only when Redis is unavailable
+
+**Test.** `src/tests/security/rate-limiting/abuse-prevention.test.ts`
+
+**Documentation.** [docs/security/rate-limiting.md](./rate-limiting.md)
+
+### SEC-034 — MFA verification shared one budget across every user behind an address
+
+*Fixed in v2.8.0. Component: `rate-limiting`.*
+
+**Issue.** The rate-limit key included the submitted email, which the verification endpoint does not carry, so all 20 attempts were shared across every user at that address. An office behind a single NAT could have every legitimate second-factor login locked out by ordinary traffic.
+
+**Fix.** src/routes/auth.ts — the key includes the challenge, which identifies one login attempt
+
+**Test.** `src/tests/security/rate-limiting/abuse-prevention.test.ts`
+
+**Documentation.** [docs/security/rate-limiting.md](./rate-limiting.md)
+
+**Attack classes.** `mfa-bypass`
+
+### SEC-042 — The test runner's directory glob was shallower than the test tree
+
+*Fixed in v2.9.0. Component: `testing`.*
+
+**Issue.** `node --test` expands `**` as a single directory level rather than as globstar, so the discovery patterns stopped matching as soon as the security suites gained a directory level. 48 security tests — the entire authorization suite — stopped running, and the suite still reported success because the remaining files passed. A green run was reporting on less than the repository contained.
+
+**Fix.** package.json — one pattern per directory depth, with no overlap
+
+**Test.** `src/tests/security/registry.test.ts`
+
+**Documentation.** [docs/security/registry.md](./registry.md)
+
+### SEC-043 — SAML assertions were validated without a complete issuer and audience binding
+
+*Fixed in v2.5.0. Component: `saml`.*
+
+**Issue.** The response validator checked signature and conditions but did not require a complete binding between the assertion and the configured service-provider entity, so a valid signed assertion minted for a different relying party could be accepted here.
+
+**Fix.** src/services/saml/validator.ts — the audience and issuer are both required and must match configuration
+
+**Test.** `src/tests/security/saml/saml-validator.test.ts`
+
+**Documentation.** [docs/security/enterprise-sso.md](./enterprise-sso.md)
+
+### SEC-046 — Every service-account request produced no audit record at all
+
+*Fixed in v2.9.0. Component: `audit`.*
+
+**Issue.** A machine principal is represented in memory by a user object whose id is the sentinel `sa:<uuid>`, so that routes expecting `request.user` keep working without a matching user row. The audit subscriber passed that sentinel straight into `audit_log.user_id`, which is a uuid column. Postgres rejected the insert, the subscriber's catch logged `failed to write event` and the audit record was lost. The request itself succeeded, so nothing failed visibly, and the absence of a record looked exactly like a request that never happened. The practical effect was that every request authenticated by an API key or an mTLS service account left no audit trail — the privileged, non-human path, which is the one an attacker would most want to use quietly. Surfaced by a test whose fixture failed in CI and not locally, because CI's request ids and principal resolution differed enough for the bad insert to occur there.
+
+**Fix.** src/services/events/subscribers/auditLog.ts — the sentinel is stripped, user_id is left null, and the service account is recorded in metadata
+
+**Test.** `src/tests/security/service-accounts/audit-attribution.test.ts`
+
+**Documentation.** [docs/security/audit.md](./audit.md)
+
+## Medium
+
+### SEC-013 — A used credential was not distinguishable from an unknown one
+
+*Fixed in v2.2.0. Component: `tokens`.*
+
+**Issue.** Replay of a consumed magic link, reset token or OTP returned the same error as presenting a credential that never existed, so the second use of a stolen code was invisible.
+
+**Fix.** src/services/singleUse.ts — replay is detected and reported as its own outcome
+
+**Test.** `src/tests/security/tokens/single-use.test.ts`
+
+**Documentation.** [docs/security/trust-boundaries.md](./trust-boundaries.md)
+
+**Attack classes.** `token-replay`
+
+### SEC-018 — OIDC authorization requests carried no nonce
+
+*Fixed in v2.4.0. Component: `oidc`.*
+
+**Issue.** The authorization request generated no nonce and the ID token response was not checked for one, so a token minted for a different session could be replayed into this one.
+
+**Fix.** src/routes/oauth2.ts — a nonce is generated per request and verified on the response
+
+**Test.** `src/tests/security/oauth/oauth2-hardening.test.ts`
+
+**Documentation.** [docs/MIGRATION-2.4.md](./docs/MIGRATION-2.4.md)
+
+**Attack classes.** `oauth-attacks`
+
+### SEC-021 — An unsigned SAML Issuer element was not validated
+
+*Fixed in v2.5.0. Component: `saml`.*
+
+**Issue.** The Issuer was compared only when it fell inside a signed region. An attacker could place an unsigned Issuer naming a trusted IdP alongside a signed assertion from another IdP. Confirmed to lie outside both signed regions, so it was a real gap in the trust decision rather than a theoretical one.
+
+**Fix.** src/services/saml/validator.ts — the Issuer is validated against the configured entity id in all cases
+
+**Test.** `src/tests/security/saml/saml-adversarial.test.ts`
+
+**Documentation.** [docs/security/enterprise-sso.md](./enterprise-sso.md)
+
+**Attack classes.** `oauth-attacks`
+
+### SEC-022 — RelayState verification threw instead of returning false
+
+*Fixed in v2.5.0. Component: `saml`.*
+
+**Issue.** A RelayState that failed its integrity check raised rather than returning a rejection, turning a routine validation failure into a 500 and obscuring the real cause.
+
+**Fix.** src/services/saml/relayState.ts — verification returns a boolean and never throws
+
+**Test.** `src/tests/security/saml/saml-adversarial.test.ts`
+
+**Documentation.** [docs/security/enterprise-sso.md](./enterprise-sso.md)
+
+### SEC-030 — Webhook signing secrets were stored in plaintext
+
+*Fixed in v2.7.0. Component: `secrets`.*
+
+**Issue.** Webhook secrets were stored as issued, so a database read, a backup or an admin query returned material that lets an attacker forge delivery attempts signed as this installation.
+
+**Fix.** src/services/webhooks.ts — AES-256-GCM at rest, with legacy plaintext still readable
+
+**Test.** `src/tests/security/configuration/secrets-config.test.ts`
+
+**Documentation.** [docs/security/configuration.md](./configuration.md)
+
+**Attack classes.** `secret-disclosure`
+
+### SEC-035 — Credential spraying was unbounded
+
+*Fixed in v2.8.0. Component: `rate-limiting`.*
+
+**Issue.** The login budget was keyed on address and submitted address together, so it stopped repeated guesses at one account and did nothing about an attacker varying the address across a thousand accounts from one host.
+
+**Fix.** src/routes/auth.ts — a second, address-keyed budget bounds spraying independently
+
+**Test.** `src/tests/security/rate-limiting/abuse-prevention.test.ts`
+
+**Documentation.** [docs/security/rate-limiting.md](./rate-limiting.md)
+
+### SEC-036 — A refused request left no record
+
+*Fixed in v2.8.0. Component: `audit`.*
+
+**Issue.** A rate-limit trip produced a 429 and nothing else, so sustained guessing at login or MFA verification was invisible except in aggregate. The requests that most warranted attention were the only ones absent from the log.
+
+**Fix.** src/plugins/rateLimit.ts — rate_limit_triggered records the endpoint, address and which limiter decided
+
+**Test.** `src/tests/security/rate-limiting/abuse-prevention.test.ts`
+
+**Documentation.** [docs/security/rate-limiting.md](./rate-limiting.md)
+
+### SEC-037 — Failed logins were never audited
+
+*Fixed in v2.8.0. Component: `audit`.*
+
+**Issue.** user_login_failed existed in the event vocabulary and was never emitted, on either login route. Password guessing left no record.
+
+**Fix.** src/routes/auth.ts — emitted on both routes, with no user id since the submitted address may match no account
+
+**Test.** `src/tests/security/authentication/login-abuse.test.ts`
+
+**Documentation.** [docs/security/audit.md](./audit.md)
+
+### SEC-038 — A replayed refresh token was indistinguishable from an unknown one
+
+*Fixed in v2.8.0. Component: `tokens`.*
+
+**Issue.** Rotation consumes a refresh token, so a second presentation failed exactly as a token that never existed would. A leaked token used twice was therefore treated as a typo, and the account's other credentials stayed valid.
+
+**Fix.** src/services/refreshTokenState.ts — a spent token is identified and the account's credentials are revoked
+
+**Test.** `src/tests/security/authentication/login-abuse.test.ts`
+
+**Documentation.** [docs/security/audit.md](./audit.md)
+
+**Attack classes.** `token-replay`, `session-persistence`
+
+### SEC-039 — API key creation had no rate limit
+
+*Fixed in v2.8.0. Component: `api-keys`.*
+
+**Issue.** Minting a credential is an authentication event but was unlimited, so a leaked session could enumerate a batch of keys.
+
+**Fix.** src/routes/apiKeys.ts — bounded like any other authentication endpoint
+
+**Test.** `src/tests/security/rate-limiting/abuse-prevention.test.ts`
+
+**Documentation.** [docs/security/rate-limiting.md](./rate-limiting.md)
+
+### SEC-040 — A stale build output kept deleted security tests running
+
+*Fixed in v2.9.0. Component: `testing`.*
+
+**Issue.** `tsc` does not remove output for sources that were renamed or deleted, so a moved suite ran twice under two paths and a deleted suite kept running. Test discovery therefore did not reflect the source tree, and a security test could be removed from the repository while continuing to pass in CI — or the reverse, a suite silently dropped out of the run.
+
+**Fix.** package.json — the build cleans dist before compiling
+
+**Test.** `scripts/verify-release-metadata.mjs`
+
+**Documentation.** [docs/security/registry.md](./registry.md)
+
+### SEC-044 — The SSO endpoint could be resolved through a name the operator did not register
+
+*Fixed in v2.5.0. Component: `saml`.*
+
+**Issue.** The endpoint that initiates SSO was addressable through a host alias that was never in the connection's registered endpoints, so a connection could be initiated against a name outside the configuration an operator reviewed.
+
+**Fix.** src/routes/sso.ts — the request address must be one the connection registered
+
+**Test.** `src/tests/security/saml/sso-endpoint.test.ts`
+
+**Documentation.** [docs/security/enterprise-sso.md](./enterprise-sso.md)
+
+### SEC-045 — The audit log export did not neutralise spreadsheet formula injection
+
+*Fixed in v2.9.0. Component: `audit`.*
+
+**Issue.** The CSV export quoted values containing a delimiter or a quote, but did not neutralise a value beginning with `=`, `+`, `-` or `@`. Several of the exported columns are attacker-supplied — the user agent above all — and a spreadsheet evaluates such a cell as a formula when the file is opened. An audit export is precisely the file an operator opens in a spreadsheet, so that is the expected consumer rather than an edge case. Found by Semgrep's `direct-response-write` rule during the triage for this release; the rule's own finding was a false positive, but the code it pointed at was not.
+
+**Fix.** src/routes/admin/platform.ts — a value with a formula prefix in first position is prefixed with an apostrophe before quoting
+
+**Test.** `src/tests/security/audit-export.test.ts`
+
+**Documentation.** [docs/security/audit.md](./audit.md)
+
+## Low
+
+### SEC-041 — A test fixture path was correct at only one directory depth
+
+*Fixed in v2.9.0. Component: `testing`.*
+
+**Issue.** A suite reached its fixture by counting parent directories, which resolved correctly from `src` and not from the compiled output in `dist`. The suite passed and then failed to load the moment it was moved, which is a poor way to discover that a path is fragile.
+
+**Fix.** src/tests/helpers/paths.ts — paths are anchored on the nearest package.json
+
+**Test.** `src/tests/security/authorization/authorization.test.ts`
+
+**Documentation.** [docs/security/registry.md](./registry.md)